Simple state management with singleton pattern at QUOINE 🗽
This blog post is explaining how I applied Singleton pattern from the Go4 to solve simeple state management problem.
At QUOINE, we use Redux for all the thing with regard to state management. It comes with several costs:
- Boilerplate all over places
- Action, reducer and connected component are three files to maintain regardless of the size of a feature
- The whole React's VDOM tree re-renders on every action dispatch because we do not use any immutability library in combination with Redux
Currently, we need a way to replace static list of fiat currencies on the client-side Javascript application by a dynamic one returned from the API on application start-up. This is something that rarely change overtime, it's a one-off operation. We need a data fetching mechanism to store the list of fiat currency before first render hit the screen. The solution I chose is heavily inspired by blog post from the one and only Kent C Dodds 👨🏻💻 - Application State Management.
The code snippet is as the screenshot below:
The module export two methods for setting and getting a list of fiat currency. After bootstrapping the application, the dynamic list will be fetched over the wire and set value back to fiat currency list. Anywhere inside the application code that needs access to this list, it can just simply use getFiatList method for that purpose.
Conclusion:
With that simple approach, I could replace the static list of data located on the client side by dynamic one returned by the server. The transition is painless thank to the simplicity brought by singleton pattern. This process would have never been easy this way if I had chosen the path to go with Redux. I could be able to avoid create one more reducer, action and countless of connected components just for that piece of dynamic data. One last thing, I would like to point out to the old and valuable from our beloved Dan Abramov - You might not need Redux.
Until next time - cheer 🎉 😊 🎉