State Management in modern UI frameworks πΊπΈ
In this post, I would like to write about my experience with respect to state management in modern UI engineering development. Stay tuned and read on guys π
I have been learning and developing web application for nearly a decade now. The fantastic thing about the web is that it is now owned by any giant companies out there like Apple (iPhone) or Google (Android). Instead, it is completely open and shared across the globe π - this is also the main reason why I decided to go with the web development back then π
There have been many trends up and down when it comes to state management in UI application. The web once was really simple, even the best minds behind AngularJS decided to just let developers to store things in simple objects so-called scopes. Back in 2013-2014, React was created by Facebook and later they decided to open-source their state management architecture mechanism so-called Flux. A year later, Dan Abramov decided to team up Andrew Clark to create Redux which happened to be the most popular implementation of Flux architecture until today. It claimed itself as predictable, global state management system. I once maintained a huge application where we have several hundreds Redux reducers. It resulted in a massive boilerplate and big bundle sizes shipped to our users' devices.
React was designed to be just the view UI library which doesn't come with any batteries included such as state management, animation or routings. Fun fact, Redux was created upon experimental features back then of React and appeared to be super popular nowadays so-called Context. Few years later, React core team decided to mark React Context as official support. A lot of members in React community found Redux involve too much boilerplate at scale and rather complex. They started opting in React's context directly for achieving similar things with fewer code. It's tempting of course to most users. Unfortunately, Good API design is the one that is optimized for change. React's context use case is rare for application code, it is mainly useful for component library. At Axon, we once made that mistake by choosing to use React Context for managing our application state. It results in massive burden in maintainability and breaking encapsulation everywhere as we could not reuse it in another places because everything was baked deeply into React's context at the top level of the application - please feel free to read more about it here. Long story short, please double check other options mentioned below before going for that direction π
In recent years, we have seen a huge wave of moving away from global state management right in our browsers started by this phenomenal video from Tanner Linsey. The below are some of the benefits of breaking up with your global state management library:
- Less boilerplate code compared to other options like Redux
- Easy code splitting by nature
- Most of applications' state are server states, let's not put those into global state of client to avoid out-of-sync
- Simple client state can be achieved easily by using what provided out of the box by your favourite frameworks - ref / reactive in Vue, createSignal in Solid, store in Svelte, useSignal in Qwik or Valtio library if you are stuck in React world π
- Double check your state management library, you might think it's only meant for server state while it's also really capable of handling client state as well such as React-apollo's reactive variables
- If you have a really complex client state, please consider using state machine and state charts mechanism like Xstate. Trust me, it will make your life much happier and result in maintainable codebase. In case you are interested in another post of mine related to XState, I did optimize Axon's media player back then and it's battle-tested for years now π
Last by never be the least is the latest trend, move everything back to the server like PHP back in the day, never write another API, you might not need react-query and edge rendering. Personally, I am so amazed by how the web community has evolved overtime and feel extremely fortunate to be part of the whole journey started since 2010. MiΕ‘ko Hevery promised he will not make another web framework again! It might mean that we have reach the maturity stage of our web development, UI engineers won't have to see much changes in the upcoming years anymore yet rather stabilization. The way we build our web application will be server-centric and performance-focused thanks to content being served as close to our end-users as possible. JavaScript is the most expensive asset in the web world. HTML is actually the web language, not JavaScript as many people think. Web developer is not the same as JavaScript developer. The ultimate goal is to build beautiful, performant and accessible web application which involves ways more than just JavaScript itself as a tool only. web.dev is a great resource to learn more about that indeed π
There you have it guys, my personal experience on seeing how state management of the modern web application started early in my career and where it is nowadays. Hopefully, by reading up to this point, it's meaningful to you as much as it does to me. Together, let's ship less JavaScript and paying more attention to building great products for our users. Peace out and until next time π