Evolution of global/shared state management in RM/GE packages #560
Closed
shavinac
started this conversation in
Show and tell
Replies: 2 comments
-
Thank you so much for documenting this @shavinac — super useful! |
Beta Was this translation helpful? Give feedback.
0 replies
-
Closing as stale |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
This is a brief writeup of how the global/shared state management patterns in the
round-manager
package have evolved and changed over time. Also providing some suggestions and other examples to consider when it comes time to revisit/refactor these areas of the code.Initial Implementation: ReduxToolKit (RTK) Query
In late May / June 2022, the Round Manager team discussed different options for data fetching in
round-manager
app. Initial Discord discussion on react-query vs. reduxDecision: Use Redux since grant-hub is already using it. RTK Query is a data fetching and caching tool that aims to abstract away and minimize the Redux boilerplate code to write. RTK Query was used in the initial PR for the service
Redux-RTK discussion revisited in Discord in July 2022
Implementations of the Program, Round, GrantApplication, IPFS RTK Query API configs
While RTK Query was quick to get set up and implemented for
round-manager
, it was difficult to deal with when we wanted to add unit tests for our React components. Because RTK Query abstracts away most of the Redux wiring, it was not possible to write satisfactory unit tests without either:These conditions also made it difficult to use test-driven development (TDD) where the test is written before implementation -- it would require relying on RTK Query internal logic (leading to fragile tests), or relying on a lot of test data mocking out external APIs, which would have been difficult to change/customize per test.
Exploring Alternatives: React Context
In August 2022, the Round Manager team had a Tech Retro to revisit RTK Query usage in
round-manager
- benefits/drawbacks, which requirementsround-manager
needed, and offering alternatives to discuss/explore. Since the external API interactions were mostly independent of one another (Program
data/updates didn't really affectGrantApplication
data/updates, for example), and there was no pressing need for data caching, there were simpler options that would have satisfied the current requirements for theround-manager
app.One of the action items from that Tech Retro was to spike out an alternative approach with React Context. (issue / final PR)
Decision: We then decided that we wanted to continue the refactor and start moving away from RTK Query.
Decision: Instead of doing all the refactoring in one big push, we chose to migrate each API one at a time when a feature story required that API - then the team would continue to deliver value to users as the codebase was gradually refactored.
Issue tracking the RTK -> React Context migration
PR removing the now-unused RTK Query API configs
Can we make it even simpler?
The initial implementation with React Context used
useReducer
with a Redux-esque dispatch/action data flow to manage state updates. However, since most of the state updates are quite simple, they can be managed using plain ReactuseState
withstate
/setState
functions.Simplifying BulkUpdateGrantApplicationContext by removing
useReducer
and instead usingsetState
directlyAnother example - simplifying Create Round context to remove
useReducer
and just useuseState
Custom useBallot hook in grants-explorer - defines helper functions
handleAddProjectToShortlist
andhandleRemoveProjectFromShortlist
that implement add/remove logic using<state>
/<setState>
, and exposing those helper functions to consumersTo be continued
Can we make it even simpler and remove React Context entirely? Some actions like "create program", "create round", might be implemented as plain APIs, and/or custom hooks with local progress state 🤔 💭
Beta Was this translation helpful? Give feedback.
All reactions