I'm putting together an app with react-native-navigation.
I need to have some global state available but I can't figure out how to implement it. Usually I'd have a stateful top-level component and pass methods that call this.setState to lower components as props—but the two Navigation methods provided by react-native-navigation, startTabBasedApp and startSingleScreenApp, cause any parent component to dismount. Dismounted components can't have state changed according to the error logs, so I'm at a loss.
What am I missing? How can I share state between my components (screens) with this solution?
Consider using Redux. There is an example here- https://github.com/wix/react-native-navigation/tree/v1.1.81/old-example-redux
It is unmaintained but the principle should be the same. My app works fine with it even on version 1.1.81.
Related
I am new to React Native, I am trying to change the state of an arithmetic function in a class component located in one screen and then share it globally in order to use it in different screens and possibly change it, what are some of the ways in which I can do this?
You can either lift the state up or use context API
also maybe you should consider using React Hooks
maybe this thread is similar to your issue
also, these articles could help with the context 1, 2
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.
I'm working on a React + Redux project with a couple of other developers and we can't agree on what the best practice is regarding where to pass in the state and the actions.
My approach is to have a 'container' or 'provider' component, which is the parent component, all required states and actions are mapped to state and passed down into child components, creating a single source of truth. However the down side to that is, you have to remember to pass actions and values down through each child component, which can be tricky to follow.
Another developers approach is to use the mapStateToProps on each component where it is needed, at any point in the stack. So if a child component three or four levels down requires a certain state, he would use mapStateToProps on that component. He would also import action creators directly using the import keyword, instead of calling them as props. I don't like this approach because you're potentially injecting states multiple times and you can't switch out your state or actions quickly in one place.
I can see both approaches have their merits and fallbacks, so I just wondered if there was a definite best practice as to where and when to inject state/actions into a stack of React components.
I worked on a relatively large Redux codebase and the approach we chose and which I like was your second approach using mapStateToProps on containers component which dispatch actions and delegate rendering to dumb components.
You want to be able to reuse them in many places without having to pass down a state. Your top redux state is still the source of truth but mapStateToProps will allow you to access only the part of the state which you need within this container.
Redux documentation is amazingly well done, check it out, it recommends container components implementing mapStateToProps http://redux.js.org/docs/basics/UsageWithReact.html
It's up to you how many components you connect to Redux, but generally speaking having more connected components is better for performance. For more information, see the Redux FAQ on connecting multiple components, as well as my blog post Practical Redux, Part 6: Connected Lists, Forms, and Performance.
I have a question about how to structure a React/Redux app.
As far as I understand, it's not recommended practice to reference containers inside a component. However when nesting components withing a Redux app, the top level container is bound with a connect() and mapStateToProps etc, but it seems strange to pass in all props down the line to -only- components.
When structuring an app with a nested component for example like:
Dialog > Form > Tab > Input Section > Input control
the input control could have a prop isVisible, where it seems strange to me that I would have to pass the prop all the way down the tree.
So my question is mainly, is this indeed what is recommended and how is this handled? Is this for example simplified by setting props to something like:
{
inputProps: { visible: false }
}
?
Or, can I reference a container inside my component, so I can have a separate connect() for only the props actually relevant?
One of the main points of Redux is to allow individual components to connect to the store and extract the data they need. Also, don't overthink the whole "container/component" distinction in terms of separating things in the codebase.
See the Redux FAQ entry at https://redux.js.org/faq/react-redux#should-i-only-connect-my-top-component-or-can-i-connect-multiple-components-in-my-tree for more info on connecting multiple components, and Dan Abramov's tweet at https://twitter.com/dan_abramov/status/802569801906475008 for thoughts on "container vs presentational" structuring.
If you find yourself passing down many properties, maybe they should be containers.
Just take redux-form as an example. It could perfectly be all about components, but they decided to use redux as well.
Im using Vue and Vuex in my application and I have some components. By the time passing I know I will probably have a few more which is gonna be a lot. So I have a problem with sharing the app state within all the components. So I'd like to know which way should I follow? Either passing the state to all the components no matter child or parent, or passing the state to a parent one that will be used in some of its child components and then passing the state to them as a property (however, I do need to import the mutations methods because props are not reactive)?
UPDATE:
Keep in mind though that if a component is going to be displayed or hidden and the conditional statement v-if is attached to the component custom tag, each time the entire component is going to be rendered again! But not if statement was only on some child tags in the component.
Thanks in advance.
What you are asking is a false dilemma. From the official documentation:
By providing the store option to the root instance, the store will be injected into all child components of the root and will be available on them as this.$store.
(emphasis mine)
Which means that sharing the store between components no matter how deep in the component tree is handled for you automatically by vue and vuex.
It's quite opinion based question, but I would say it is much better way to use Vuex since the beginning if you know that your app can be developed into large scale.
Passing states from parent to child all the way etc is not good way, so it is better to use Vuex now and you will save a lot of time changing your app in the future when you would have no other way than vuex.