0. Flux Pattern
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.
About desingn pattern with React
1. Observer Pattern: redux
1.1. about Observer Pattern
-
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.
1.2. pros
- low dependencies among components which mean all components should not always be on the same tree level in order to be synchronized with state or data.
unidirectional data flow: makes us easy to track down the flow of data.
1.3. cons
- memory leak: to avoid un-used observer, it is required to detach the components which will not be used with Subject.
2. Provdier Pattern: famously known for context api data flow
2.1. about Observer Pattern
- highly useful for React Context which makes components to have global state.
- this is highly useful for updating the child components by the changes on the object from parents components which are highly reusable throughout the numerous componets.
- the most primitive point of Provider Pattern is that it makes us to avoid "Prop Drilling".
2.2. How it works simply:
- Provider will set up some values into the Context Object at the highest tree level of Components.
- Consumer which also called as Child Component will get a data directly from the context than receives it props from Parent Component.
2.3. Pros:
- get free from "Props Drilling": lower the dependency between parents and child components
unidirectional data flow: one single source of truth == flux pattern
2.4. Cons:
- invisibility among the connections between Context and Consumer: hard to identify which component is parent and where data is coming from.
- have componets to use global values: general cohesiveness will be higher
(dont get it perfectly but according to the Official Doc from React says that less Context used is preferred)
3. basic and core concepts to follow regradless of the pattern type
3.1. divide the components as smallest as possible
3.2. keep the unidirectional data flow
3.3. focus on single source of truth
3.4. keep it simple
4. dive into context pattern / provider pattern in React in shallow depth:
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.
Issues
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
Conclusion
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.
