I read articles criticizing React for setState being weird when instead the people criticizing it did not understand it properly.
I really like React modularity, and the more I learn it the more I find it intuitive.
Nevertheless, I ran into multiple situations in which I would have liked the states to be cross-component. What I mean is, changing a state in a component could affect another component. It is my understanding that there is no React built in solution to this problem. Of course there are ways around it but there is no fixed protocol.
My question is, why is that? what is the advantage of not providing a simple way to handle such a common scenario? Or if there is and I don't know about it, please enlighten me!
There are at least 4 out-of-the-box ways to share state between closely related (and unrelated) components: props, callbacks, refs, the ctx variable.
I simply think it's built to be as small as possible with the complete intention that if you need an app state manager for a complex project (where unrelated components need to communicate) that you will include one, and they will not force you into any one approach.
If you did want something with more substantial scaffolding to start a project, which many people do, you could refer to react-boilerplate or similar.
But having React itself limited to the minimal, I have the freedom to choose (or not) the best tool for each project without having to override one-size-fits-all defaults.
Related
I want to migrate a big application from React Context API to Redux. The thing is, since is such a big task, I want to do it slowly and meanwhile be able to work on other things of the app (without adding things to the context).
Is it a good idea to migrate piece by piece and have both Redux and Context in the same app until I migrated everything? Or is it best to freeze the code and migrate it separately, and then work on new things?
I know it might depend on more variables but I want to get a general idea...
Only you would know the specifics of your app, but in general I don't think there's an issue with doing it piece by piece as you describe (migrating only some slices of state to redux to begin with.) You may find it turns out to be less of a headache to just do it all in one go though, but technically there's no reason you couldn't do this.
Obviously depends on how well you code base is currently structured.
We are about to do the same - i think our approach will be to add more tests to the context side, add redux concurrently with as flat state as possible then do one big move, the addition of redux with context could cause race conditions and other unknowns. Really big and scary change when the day comes to make the change, but hoping that we will have enough tests in place to manage. Wish we started with redux in the first place.
From what I have been researching, ReactJS is the new craze in the world of front-end development. I can find few articles that are able to provide a bias free look on ReactJS. There is only praise for it, but should it be used everywhere? I know an html.erb file with javascript can accomplish what ReactJS can do. Everything has its place. Where does ReactJS and React Native fit in? Specifically when should they be used? I know JavaScript can handle a lot, but of those things it probably shouldn't handle, or there is a better solution.
I would greatly appreciate guidance on these questions.
React has many cool features and is one of the best libraries for using for building UI apps
it utilizes something called the virtual dom to enhance performance in applications
it has a really intuitive pattern with storing state in local components which can be passed down to children components as props.
it integrates well with state management frameworks like Redux (there is a helper package called react-redux which makes the integration seamless) but it also has it's own context API which can be used for wider ranging state
it recently introduced the concept of hooks. these replaced lifecycle methods which were popular in previous versions and are now a cool way to "hook" into components and utilise functionality whilst the component mounts and unmount
of course, like with everything, there are alternatives. you can just use plain old vanilla which has it's own benefits or you can choose a popular alternative such as Vue.js.
There is no hard and fast rule specifically when it should be used. the ball is in your court
I've been searching for a while about React's hooks now, and one question became persistent in my head. Will hooks overthrown redux? This is a fairly old discussion so first a little bit of context :
State Management with React Hooks — No Redux or Context API
What do Hooks mean for popular APIs like Redux connect() and React Router?
redux-react-hook
A lot of people (React's team included) seens to think that redux and similars will just going to adapt to the new API, turning the HOC's approach obsolete, but my question is:
With custom hooks, use reducer, and a well thought logic why do I need Redux at all? I mean, isn't just more performatic to dispatch your actions to a single reducer? I've found a lot of material about it, but none of those seems to have a definitive answer (maybe because there aren't one?), so I would like to know what do you think about Redux's future?
It's really hard to say at this time. The redux team is actively updating the product to include some nice features. However, one of the creators of redux (https://github.com/acdlite) seems to be on a path to destroy his old applications in favour of new features in react.
That being said, Redux is a tested and known library that a lot of people are comfortable with. I do not believe it a bad idea to start a new project with redux Today, tomorrow, or in a year. Tech does not die overnight. if it serves a purpose it's going to live on.
However, I do think context and hooks are a great alternative to redux, but the community simply does not know how to use it yet.
Nope, definitely not.
I addressed this in my Reactathon 2019 talk on "The State of Redux".
Summarizing: hooks mostly offer ways to do the same kinds of things you could already do, like local component state and avoiding prop-drilling via context. If that's all you were using Redux for, then you probably didn't need Redux in the first place. But, hooks have their limitations, and there's lots of additional use cases for choosing Redux.
Also, note that we are currently working on designing a public useRedux()-type hooks API for React-Redux.
More than a year has passed since this question was posted.
I want to add that in my opinion Redux has lost some relevance...
2 players in my opinion have stolen a big share of Redux's position in the React market:
People have learned how to combine useReducer with useContext to
implement a much simpler solution and without third party
dependencies. With the advantage that the React team is behind it;
which means we will get constant improvements tightly integrated
with the React framework.
MobX has been growing it's user base. Mainly because it provides an observer pattern which requires much less boiler plate code than Redux. (This could be debated).
So even though Redux remains widely used for React projects I foresee this will be gradually reduced overtime... - no pun intended... well may be a little bit ;) -
Specially for green field development!
Background
I've been building an application using React Native & Redux to make an assessment over whether to use it for an upcoming project over Swift and going fully native.
I genuinely believe that Dan Abramov's techniques with Redux are a case of solid engineering. Not updating the state and having the view as a function of the state is great, and I'm very much on board with the idea. Where I'm coming somewhat unstuck is with throwing animations into the mix.
Scenario
More complicated animations require state management, for example, fading out a view, replacing the text and fading it back in. I'd only want to update the text halfway through the animation, and this is easy enough to do using local state and leveraging the Animated framework.
Say the text to be displayed is driven by the state, it'd be updated the moment the state is changed via an appropriate action & reducer combo, but for the sake of presentation I need it between these two animations.
An example of this would be selecting a record from a list, where there's an on-screen label showing the name of the selected record. Ideally you'd want to update the global store straight away, but perform a nice transition on the label itself.
My Thoughts
To my mind it makes some amount of sense to use 'local state' inside of components to deal with animations, and the main Redux store for more overall data or architecture state. The problem is this breaks the idea of the view being a function of the global state and I'm not sure that sits right with me.
On the other hand, managing animation sequences etc. by writing heaps of actions, reducers and cluttering up the store also doesn't feel clean.
The Question
I know React Native is in it's infancy, and not everybody is using Redux, but is there a generally accepted way of managing animations in this kind of scenario?
I've been developing React for only 9ish months, and so I'm probably a n00b compared to the likes of you Matt, and I can say without much hesitation that redux is awesome, but that it shouldn't replace internal component state in all circumstances. Especially for things like animations. You asked this yourself, but I ask again: why would this need to be in a global state? Redux is there to allow components across an application to get updated state when things happen throughout your application. That does not mean, however, that there should never be any state anywhere in your application except for in a Redux store.
A man much smarter than me said
If you feel pressured to do things “the Redux way”, it may be a sign that you or your teammates are taking it too seriously. It’s just one of the tools in your toolbox, an experiment gone wild.
Local state is fine....
The tradeoff that Redux offers is to add indirection to decouple “what
happened” from “how things change”. Is it always a good thing to do?
No. It’s a tradeoff.
What is this I'm quoting? What kind of blasphemous React developer could possibly say that Redux shouldn't be used for all things React??
I'll tell you who. The creator of Redux.
https://medium.com/#dan_abramov/you-might-not-need-redux-be46360cf367#.flb8fzjr8
TLDR Use Redux where it is useful and where it makes sense. It's awesome for what it's suppose to do.
But don't try to fit that round peg into a square hole.
I hope this is useful.
I'm in a project and my task is to build drop-down lists that lets user say his location without free text. I came to a point where I think that Flux is a really good way to built it, but I do not want to use React because of the dependencies issues. I would like to know if it is possible to build a flux app without React? And if it make sense?
Thank you!
Yes, you can use Flux without React since it really is just a data-flow architecture. Pretty much everything will be exactly the same -- except you won't be using React components. You would add a changeListener to the store, passing it a callback function to use when it processes an action.
I'm surprised, though, that you're concerned about using React due to dependency issues. What issues are those?