React Redux has long been the go-to for global state management in React applications, renowned for its structured approach and robustness in handling complex state logic.
However, in this blog post, we’ll delve into the reasons why we opted not to use Redux for our Front-End Code Base project and instead chose React’s useContext.
We’ll explore the critical distinctions between React’s useContext and Redux, explaining how this choice aligns with our goals of simplicity, flexibility, and streamlined development.
| REDUX Redux is a popular state management tool well-suited for providing state to an application at a global level. It makes it straightforward for developers to trace a request for data from the initial dispatch through the saga for the API call, back into the reducer to update the state, and finally into the component to update any data or display values dependent on that state. This structured approach makes Redux an excellent tool for large applications or those developed by large teams. Implementing global state management with Redux involves wrapping the entire application in a provider store and organizing the lifecycle logic into a set of files and folders. Typically, there’s an index file that exports everything to the application, with each reducer having its own file and associated saga file. |
CONTEXT Context, on the other hand, is not technically a state management tool but rather a dependency injection tool that allows React to access data within a given hierarchy in the application. Unlike Redux, Context does not provide a lifecycle framework. There is no action > reducer > saga > reducer > component setup for developers to follow. Additionally, any component pulling data from a Context will trigger a re-render whenever that Context changes. However, when used with ES6, functional component design, and proper memorization techniques, Context can provide an effective alternative to Redux for medium and even large applications. |
The Kinetic Platform is a DXP (digital experience platform) that enables a decoupled user experience and provides web developers with a framework for rapid development without worrying about databases, integrations, workflows, and more. Together, the front-end code and the Kinetic Platform work seamlessly to create a robust user experience.
We create sample apps, such as Queue, Service Portal, Calendar, and more, to share with the community as a starting place for their development. These apps offer optional configurations and examples that can be used to speed up development and facilitate customization.
The Front-End Code Base Project
The Front-End Code Base project refactors Kinetic Data’s previous Starter bundle. The Front-End Code Base serves as the foundation for our starters, allowing clients and partners to use them in conjunction with the Kinetic Platform. The goal of our refactor project is to simplify the codebase, making it accessible for developers of any level to set up their front-end code and begin building applications.
The core concepts are simplicity, agnosticism, and a sectioning architecture strategy to allow for customizability. The new Front-End Code Base serves as a foundation on which to build unlimited services while keeping them functionally separate from each other and the Base. Each service is primarily self-contained with its own hierarchy, routing, and context.
Context, similar to a Redux provider, creates a wrapper that allows its data to flow down to any child components. By creating a Global Context wrapper that envelops the entire application, we enable any stored data to be accessible anywhere in the app.
Each additional service will have its own Context wrapper, managing service-specific state. This approach aligns with a minimal global state philosophy, where data is stored in context only when absolutely necessary.
In function-based component applications, it’s customary to make data calls directly within the component and use the data once it’s returned. This keeps the global state lean, adding only data that would otherwise require the same data call to be used simultaneously at multiple locations in the hierarchy, such as user profile information, authentication data, and notification data. A single query inside the global context component retrieves that data, stores it in state, and allows it to be used anywhere in the application.
Solving Context Challenges
Our development philosophy addresses the two challenges associated with Context. The first challenge, lacking a built-in global state management strategy, is resolved by maintaining a uniform development style and adhering to best practices for the Base.
For instance, data queries are made in the component where the data will be used or close enough to pass the data as props without excessive prop drilling. This approach eliminates the need for a state management framework by controlling state at the component level and updating Contexts as required.
The second challenge, automatic re-rendering of components using Context data, is mitigated through the useMemo and useCallback hooks. These hooks are used both within the app components and the Context component itself to control re-render calculations. They significantly reduce the performance impact of additional renders, making the trade-off worthwhile.
Flexible and Lean Front-End Code Base
The Front-End Code Base project serves as a starting point for our partners and clients. Context provides a simple, built-in way to manage both global and compartmentalized state while keeping the codebase lean and easily readable.
Additionally, if partners or clients prefer working with Redux or another state management library, Context can be easily removed and replaced with the desired solution. This flexibility ensures that developers can use the tools and methodologies that best fit their needs while benefiting from a streamlined and efficient codebase.
Cassy Lueneburg