As the Flux pattern which became the most famous and commonly used pattern in React after it had been brought out
by Facebook Development team, some other patterns such as Provider pattern, Observer pattern and etc,
had been introduced as state management libraries and APIs earns its fame by developers
such as Redux, Context Api, Mobx and etc but all the patterns shares the same common principle:
divide the components as smallest as possible, keep the unidirectional data flow, focus on single source of truth and keep it simple.
Even though it is really taugh to look deep under the hood how each libraries works as Provider or Observer pattern,
understanding basic flows or how it works is comes to important for developers to make better decision on optimizing application, in my opinion;
it makes developers perfectly know when to use optimizing tools or skills such as React.memo
or useCallback
in application
since it is the way of understanding how the flow of the state management libraries or APIs is looks like under the hood.
Therefore for this blog, let me take a brief explanation of patterns and compare those with pros and cons.
depends on single source of truth.
: Observer Pattern is useful when connecting and synchronizing various objects or components depending on one state.
Observer which itself attached to the Subject and keep listen to it until the state has been changed.
Using React Context Api in elegent way
: composing the React Context Provider and useContex Hook in order to make easier and more confortable with re-using them.
Context is useful when sharing data throughout the project or app without passing data as props regardless of the depth among components: it is more likely using data as global variables or it available us to pass down the value or data to component tree without using props or regradless how depth they apart.
Context in React is used to share data which is located in global space in a component tree such as an authenticated user or preferred theme without passing that data as props.
And it is also possible to have multiple providers in one application
But it would not be recommended to have that pattern since
the purpose of using context api is sharing data without using props in multiple components regardless of how much they apart to each others .
However All the consumers that are descendants of Provider will re-render whenever the value prop changes which means all the components who are placed as children of Provder Components, will be re-rendered as value props changes.
i.g) <MyContext.Provider value={someValue}>
This problem or issue can be handled by using pure component or React.memo, in my opinion.
PureComponent and React.memo can't prevent other consumer components to be unintentionally re-render
To overcome this, using useCallback to that value that commonly shared throughout the application.
Use React.memo to the value for the provider value and
Use useCallback to the value that makes unintentional re-rendering.
It might be recommended to use context api for such thing as user authentication, for example, which is necessarily to be accessible throughout entire application as an aspect of Service that application provides.