... if using vanilla React
Last updated
Was this helpful?
Last updated
Was this helpful?
If you use Vanilla react, you are likely to have dealt with state with one or both of two main vanilla approaches.
This pattern makes sense to use when what you have to deal with is small and self contained.
The problem with this is that it doesn't scale well, if your original component uses this approach and over time it grows, you are likely to find yourself passing way too many callbacks, and to also pass them too deep in your component hierarchy.
A solution to this would be to put your state in Redux, but then you would have to deal with all the boilerplate, and you will loose the fact that this state was encapsulated in the component.
We would recommend having a look at this demo to see how to manage local state with ConanJs
You might be doing React Hooks and using the React Context API as the container of your state.
Basically, you can conceptually use the same approach, and yet again, make no compromises, you can still decide to use this for some state, but then, for some other state, to scope it globally because it is more sensible.
With Conan State we made an effort to avoid developers making compromises.
Usually you would pick a pattern/framework or two to manage your state, and this would constraint you to a certain scope, or to a way of updating/observing your state.
This demos will provide you with real world scenarios to use ConanJs
If this was not enough, we have some more features included.
With ConanJs, you don't have to compromise, Conan State is designed to let you choose where to , and makes updating the state through its out even simpler than if you were to do it with setState + callback props.
This is a very powerful pattern of which we are very fond. That is why ConanJs lets you work and it has its own built-in out of the box.
With ConanJs, you pick, how to , how to , how to , and .