Skip to content

Conversation

@yeager-eren
Copy link
Collaborator

@yeager-eren yeager-eren commented Oct 13, 2025

Summary

Hub has a dynamic interface through its actions concept, but the the legacy only have a limited and fixed limit.

In this PR, we can have access to hub provider to run any actions. Legacy will goes through an error. so this method only works on hub wallets.

You can see the usage on #1276

Part of #1096

Fixes RF-2294

How did you test this change?

No need to test.

Checklist:

  • I have performed a self-review of my code
  • I have commented my code, particularly in hard-to-understand areas
  • I have made corresponding changes to the documentation
  • I have added tests that prove my fix is effective or that my feature works
  • Implemented a user interface (UI) change, referencing our Figma design to ensure pixel-perfect precision.

Copy link
Contributor

@arlert-armin arlert-armin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Before this PR, every new hub wallet action was defined in both the hub adapter and legacy provider, and selected via useProviders, prioritizing the hub implementation.

Now you're using an action directly from hubProvider for XRPL wallets, which makes sense since there's no legacy implementation. However, this introduces inconsistency with how other actions are handled.

Your approach will be valid once all wallets are migrated to hub, but for now, let's stick with the existing pattern to maintain consistency. Please consider adding a TODO above swapQueueContext to clean up legacy actions after full migration.

@yeager-eren
Copy link
Collaborator Author

Before this PR, every new hub wallet action was defined in both the hub adapter and legacy provider, and selected via useProviders, prioritizing the hub implementation.

Now you're using an action directly from hubProvider for XRPL wallets, which makes sense since there's no legacy implementation. However, this introduces inconsistency with how other actions are handled.

Your approach will be valid once all wallets are migrated to hub, but for now, let's stick with the existing pattern to maintain consistency. Please consider adding a TODO above swapQueueContext to clean up legacy actions after full migration.

As we've talked, the goal here is to be able to directly call an action for a specific namespaces. my use case is for ripple blockchain and there is no legacy wallets for that blockchain. so it never throw an error.

Another point is on the usage side, when you are using hubProvider it's obvious you don't have it on legacy and you should you will use it on hub wallets.

Copy link
Contributor

@arlert-armin arlert-armin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Copy link
Contributor

@RyukTheCoder RyukTheCoder left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@RyukTheCoder RyukTheCoder force-pushed the feat/rf-2294-add-hubProvider-method branch from 7741440 to 3192e81 Compare October 30, 2025 22:56
@yeager-eren yeager-eren merged commit 5b97ed5 into next Nov 1, 2025
6 checks passed
@yeager-eren yeager-eren deleted the feat/rf-2294-add-hubProvider-method branch November 1, 2025 09:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants