You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Proposal: Break up monolithic Tokens/index.tsx file into smaller, more maintainable components.
As I began working on my Token sorting task, I noticed that the Tokens screen code structure felt overly flat, which led to some challenges navigating through the logic (~800 lines). The reliance on multiple internal callbacks created lots of complexity, making it difficult to reason through the flow, and unclear where to reliably and maintainably introduce my sorting logic.
In this PR, I’m proposing a refactor of the screen by breaking it down into smaller, more manageable components, with a utility directory to handle non TSX related helpers (like sorting or handling balances). So, instead of relying heavily on internal callbacks, we can just pass props and utilize selectors where needed for each component’s specific function.
While this may be a matter of personal preference, I believe that an over-reliance on internal callbacks can often result in a bit of an anti-pattern. I feel that this refactor will make these components more straightforward, reliable, and easier to maintain. Is there a reason why we wouldn't want to go with this approach instead?
I also realize that we have other tasks in-flight and I don't want to be a blocker, but I feel pretty strongly that this refactor will remove lots of technical debt and set us up really well for the long run.
Note: This isn't quite complete, and you'll notice a few areas where I can do things like tighten up TypeScript types. If you folks are fine with this approach, I can go ahead and polish this.
Related issues
Fixes:
Manual testing steps
Go to tokens page, ensure that all functionality remains unchanged.
I've completed the PR template to the best of my ability
I’ve included tests if applicable
I’ve documented my code using JSDoc format if applicable
I’ve applied the right labels on the PR (see labeling guidelines). Not required for external contributors.
Pre-merge reviewer checklist
I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed).
I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
gambinish
requested review from
tommasini,
NicolasMassart,
sahar-fehri,
salimtb and
bergeron
Description
Proposal: Break up monolithic
Tokens/index.tsxfile into smaller, more maintainable components.As I began working on my Token sorting task, I noticed that the
Tokensscreen code structure felt overly flat, which led to some challenges navigating through the logic (~800 lines). The reliance on multiple internal callbacks created lots of complexity, making it difficult to reason through the flow, and unclear where to reliably and maintainably introduce my sorting logic.In this PR, I’m proposing a refactor of the screen by breaking it down into smaller, more manageable components, with a utility directory to handle non TSX related helpers (like sorting or handling balances). So, instead of relying heavily on internal callbacks, we can just pass props and utilize selectors where needed for each component’s specific function.
While this may be a matter of personal preference, I believe that an over-reliance on internal callbacks can often result in a bit of an anti-pattern. I feel that this refactor will make these components more straightforward, reliable, and easier to maintain. Is there a reason why we wouldn't want to go with this approach instead?
I also realize that we have other tasks in-flight and I don't want to be a blocker, but I feel pretty strongly that this refactor will remove lots of technical debt and set us up really well for the long run.
Note: This isn't quite complete, and you'll notice a few areas where I can do things like tighten up TypeScript types. If you folks are fine with this approach, I can go ahead and polish this.
Related issues
Fixes:
Manual testing steps
Screenshots/Recordings
Screen.Recording.2024-09-26.at.9.31.15.PM.mov
Pre-merge author checklist
Pre-merge reviewer checklist