React has a feature called Context which advertises a way to store globally accessible values without having to pass them down as props.
What is unclear to me is what advantages this has over storing values on the window. If on my page I have window.current_user = user_details, the user details are now available to all react components. What would the advantages be to moving this in to React's context?
If a variable on window changes, React won't know, so it can't re-render pieces of your app that depend on that data.
With context, any changes to the data will trigger re-renders.
There are arguably other advantages, but in my opinion, the re-render difference makes the two options basically apples and oranges.
On the other hand, Context isn't truly "global," because the Consumer (where you read the data) has to be somewhere beneath the Provider (where the values are written) in the hierarchy. This would make Context unsuitable, for example, in an app where the Settings menu was way down in the component hierarchy, but settings consumers were peppered throughout the app, as there's no way to pass values "up" using context.
So, if the data you're interested in doesn't change often (or at all) after the app's initial render, my opinion is that window could be more suitable than Context. Some folks will argue that this clogs up the window object, or that it violates other (usually sound) design principles, but in my opinion, if you understand the tradeoffs, using window can be a perfectly pragmatic decision.
Related
Currently I have four contexts that wrap all my routes (as shown bellow) so that I don't have lost providers all around my app screens and components. As far as I know, when I modify the value of a context variable, every component that uses it will update too, what can lead to memory problems, but my question is: if my providers, that wrap all routes/screens, even the ones that uses no context variable, may cause the same memory related problems.
<AuthProvider>
<SelectedBranchProvider>
<SelectedEventProvider>
<DrawerFormProvider>
<RightDrawerNavigator />
</DrawerFormProvider>
</SelectedEventProvider>
</SelectedBranchProvider>
</AuthProvider>
The danger with context isn't memory issues, it's unneeded re-renders. The way Context is implemented defeats some of React's diffing, so a change in Context can cause a re-render in any component that uses the same Context, even if the value that changes is unused in the component.
If you have a small app, or only rarely change what's in your context, you'll probably never hit these limitations. Good use cases for context are things that would require many re-renders and rarely change, like user language or app theme.
The docs for Context have a caveats section that goes over this: https://reactjs.org/docs/context.html#caveats
Here's a blog post with a good example of how this can cause re-renders: https://blog.logrocket.com/pitfalls-of-overusing-react-context/
I've recently upgraded a React 15 project to use React 16.9. Specifically, I've completely replaced redux with the new Context API, pure functional components, and hooks. With the Context API, we also gain the ability for nested child consumers to obtain the data without having to pass it using props all the way through. However, I noticed that I don't have any component props anywhere as everything is passed via provider/consumer context.
So my question is does the context API make component props obselete?
I find people abuse redux and context. Btw, redux uses context internally.
To be honest, prop still should be your best friend in most of cases. Only when you want to avoid nested prop passing, you could then explore context where a provider is created as a parent, and then all deep down children can receive it as props.
Prop is still the way when children connect to the provider. The only difference is that these props are stored in a sort of "global" space now.
So in short, context doesn't replace prop, it still uses prop.
You have already answered your question. Context API avoids I quote one from react docs :
Context is primarily used when some data needs to be accessible by many components at different nesting levels. Apply it sparingly because it makes component reuse more difficult
There is no other reason. If I want to reuse component or export it that depends context, user has no idea about it. Use cases like logged User, theme, or sone global state like work flow detail for the whole application etc, makes a good use case.
A have a react application using a single page. I call index.html and use ajax(axio) and update the page. I do not use any routing.
I have some global variables and will use in the whole scope of the application. The variables are primitive type integer for example. Some of the variables may be updated during the app lifecycle and some remain constant. But I should be able to reach them from all react components/javascripts. They may contain business related constants or example decimal format mask, keeping them private in each component will not be useful.
There is no need/reason to store it on the disk (localStorage).
Question is: what is the best way (performance etc) storing the global variable foo in the app?
window.foo = 10 or
window.sessionStorage.foo = 10
AFAIK, window.foo is for a single page and sessionStorage allows using within multiple pages within the same origin. What is best in my case when I use a single page? Are there any other drawbacks of window.foo usage? Security is not important, the vales stored are not sensitive. Most critical is the performance.
You probably want to use context rather than either of those. From that documentation:
Context is designed to share data that can be considered “global” for a tree of React components, such as the current authenticated user, theme, or preferred language.
Definitely don't use global variables. The global namespace is incredibly crowded, and adding to it is generally not best practice. If you did use a global for this, I'd recommend using just one, and having it refer to an object with properties for the various pieces of information you want to share. Note that they'll be window-specific.
One reason to possibly consider using sessionStorage (or perhaps periodically synchronizing your React context to it) is if you want changes in one window to be reflected in another window. Two windows/tabs from the same origin share the same sessionStorage and can get an event (storage) when the other one changes that storage. So if the global information were an app theme (say, light vs. dark), changing it in one tab could also affect the other tab if you respond to the storage event by updating your React context. Note that sessionStorage (and localStorage) only store strings, so the usual thing is to convert to JSON when storing (JSON.stringify) and from JSON when loading (JSON.parse).
What's the difference between require()ing a singleton, and passing it down via React prop or context?
What are the use cases for each?
If you require() (or import) a module, you get the same object in any component.
Use modules for the code your component depends on:
Other components (Button).
Utility functions (getTextColor).
Global data storage (CommentStore).
The upside of importing a module is that it’s extremely easy to do, and you only need to do it once.
The downside of importing a module is that you can’t override what it points to. So, for example, you can’t easily swap out CommentStore or getTextColor modules in testing, or in a “living design guide”. Depending on your use case, this may or may not be a problem.
Passing something as a prop means you can pass a different thing every time.
Use props for inputs to your components that need to be customizable:
Data (comment).
Event callbacks (onClick).
UI properties (color).
The upside of using props is that they’re explicit and customizable. They’re primary mechanism of passing data down in React so when in doubt, use props.
The downside of using props is that sometimes you might end up passing a lot of props through intermediate components that don’t use them, just to get props down to the leafs. Normally this is fine in React because it trades some verbosity for ease of finding bugs. But in some cases it can get frustrating.
Context is an advanced API and should be used very sparingly.
It is likely that it will significantly change in the future.
Context is like implicitly passed props that become “global” for a subtree:
Theming (currentTheme).
Locale (currentLanguage).
Dependency injection (store).
The advantage over props is that you don’t need to pass them manually through every component. The advantage over importing is that you can override it from outside the component, which is handy for testing, server rendering, and for things that change.
The downside of context is that it has severe issues with updates, so don’t rely on its value updating correctly. For example, React Redux can safely pass store down because store itself never changes and has its own subscription mechanism.
In general we don’t suggest using context in your application code directly. It’s fine if some libraries use it because they will be easier to migrate when its API changes.
Finally, I’m not a natural painter, but here’s a doodle to sum it up:
I'm new to ReactJS and I'm trying to figure out how to store and manipulate global state. For example, I'm writing an editor app that has some global state: selected color/background, active tool, current selection, etc.
I'm thinking about having a root interface component to store this information, and I'm ok with explicitly passing the state around using properties. I guess the idiomatic way for a children component to change global state is calling a callback received from the parent - personally I find this a bit annoying.
Instead, I'm firing custom events at the children and setting listeners on the parent. So far it is working really well, but I looked at a lot of sample code and never saw people using this pattern.
Is there any practical consequences I should consider?
Flux is great for manipulating global state because the Stores are globally accessible. Globals are known to be bad, but the way you interact with the Stores is through Actions. Actions make the state predictable and localized. So even though the state storage itself is global, Actions make the state interactions very local. At work we tend to do both reading & writing through Actions, so every state change is an "event" that leads to easily programmable behavior.
I really wouldn't compare Flux to Angular as their principles and flows are entirely different. Suggest you try Reflux.