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
I’ve noticed a few major problems with the implementation of state in this project. The main source of state is stored in a “global” (if we ignore the require cache) module here. The problem with this approach is React doesn’t own this object so it’s unable to respond to changes made to it. This leads to inconsistencies in the view layer and the underlying state model.
My proposed solution is to migrate this state object into the React realm either by using a store pattern (using context) or multiple useState hooks directly in a persistently mounted top-level component.
Before this work can commence, we need to address another design problem I’ve identified in the ModalHelper module here. This module needs to move away from modifying DOM elements directly - this is the job of React and can be done more effectively this way. The visibility of the modal and particular sections would become useState variables within the component(s). See #56 for more detail.
Acceptance Criteria
Changes to state are immediately reflected in the UI.
State is no longer global. This will technically mean new instances of the wallet selector are encapsulated. However, the idea of multiple wallet selectors needs to be addressed in another ticket - this should not be possible(?).
References to local storage values should be removed from state. Currently values such as isSignedIn and signedInwalletId are only evaluated when the module is first imported (when NearWalletSelector is imported). Logic that relies on this will be susceptible to out-of-date values which ultimately cause bugs in the long run.
The text was updated successfully, but these errors were encountered:
This task has been moved to blocked as we need to solve some of the bigger architectural problems in the project. Once we have all 3 wallets working, we can look to solve the state issues.
Description
I’ve noticed a few major problems with the implementation of state in this project. The main source of state is stored in a “global” (if we ignore the require cache) module here. The problem with this approach is React doesn’t own this object so it’s unable to respond to changes made to it. This leads to inconsistencies in the view layer and the underlying state model.
My proposed solution is to migrate this state object into the React realm either by using a store pattern (using context) or multiple
useState
hooks directly in a persistently mounted top-level component.Before this work can commence, we need to address another design problem I’ve identified in the ModalHelper module here. This module needs to move away from modifying DOM elements directly - this is the job of React and can be done more effectively this way. The visibility of the modal and particular sections would become
useState
variables within the component(s). See #56 for more detail.Acceptance Criteria
isSignedIn
andsignedInwalletId
are only evaluated when the module is first imported (when NearWalletSelector is imported). Logic that relies on this will be susceptible to out-of-date values which ultimately cause bugs in the long run.The text was updated successfully, but these errors were encountered: