I'm currently build my first real app in React and decided to use Redux along the way.
After implementing Redux, it seems like a difficult way to just set a component state to a plain application global javascript object? I've read that Redux does some performance stuff, but if we were to use a plain javascript object and enforcing immutable state change together with forceUpdate() whats the point of Redux? Besides cool timeline dev stuff? What am I missing? :)
Thanks in advance :)
If you truly understood Redux, then I think that’s mission accomplished.
Redux simply adds a simple flow to managing a global JS object - global state. You can surely do it without Redux. After all it’s very small library.
So you’re not missing anything, I don’t think. Redux is just a really useful workflow that you can implement on your own. But given it’s simplicity and excellent architecture, it may be worth going with a proven solution.
Related
I'd like to know what are the methods or process (related to recomputations during each render) that I should avoid in order to improve the performance of my code. I'm not asking about good coding practices like avoid spaghetti code, but specifically functions or process.
Thank you in advance!
The question is way too broad. But I can provide a couple of hints from experience.
Consider using a library like Reselect (https://github.com/reduxjs/reselect) to avoid recomputations during each render. This concept is similar to computed properties in other UI frameworks.
Do not abuse PureComponent class and shouldComponentUpdate lifecycle method, if you are still using class based components. useMemo is a similar hook for functional components. They should be used to solve a specific performance problem however they can lead to subtle bugs if used without thinking it through. A lot of times renders in virtual DOM are not that expensive.
Use React Developer Tools extension to determine if there is actually a performance problem.
I've been looking into React.js. I was wondering if/when React.js relies on immutability for making decisions. I kinda get why it helps developers (elaboration in the context of React will be appreciated) but how does it help React itself?
How does it come into play for things like Virtual-DOM, shouldComponentUpdate, etc?
In my case, immutability is heavily used when I combine React with Redux. By using Redux, we create a data store which contained app state and will be shared across components. Redux encourage us to use pure function, which means there will be no mutation inside of it. For more explanation https://redux.js.org/faq/immutable-data#what-are-the-benefits-of-immutability
I have found a serious flaw I think in ReactJS. Although I admit this flaw perhaps might be a flaw in my understanding :) I am trying to build a simple Todo application (using TodoMVC), and when you try to use something like Redux for state managment, you run into very, very hairy issues when trying to process nested JSON, i.e. a database response that typically would include a parent node ("projects"> and then child nodes "todos") related to the parent.
Redux seems to want you to "normalize" the data from the response so it's immuatable. Not to upset anyone, but this seems like the most ridiculous thing in the universe. So, we build a SPA app to process json responses from our data....and then...oh wait, we have to build an ORM on the client to munge all that data into a different format to process it.
If this is the state (sorry no pun intended), of React, Redux and the like, Javascript frameworks should be abandoned. I built something in Rails in like 20 minutes. Of course it's not a SPA, but it was simple to create this MVC structure... not only does it seem extremely difficult, hairy and overly complicated in React, when Redux is added, it gets into the area of absurdity. Perhaps that is why we only see very very simple tutorials with all these tools.... building huge apps with them isn't possible.
So basically, in just trying to code a simple few lines of this example above with react and redux, I was lead to this:
https://redux.js.org/recipes/structuring-reducers/normalizing-state-shape
Can someone prove me wrong? PLEASE. Just a simple codepen showing me you can have a parent "project" component, which you can add "todos" to as children and the ability to make MULTIPLE parent components, with MULTIPLE children without going down the rabbit hole above.
This is a serious flaw in my opinion if this is true. A showstopper.
Your question and understanding are wrong in a few ways.
For context, I'm a Redux maintainer, and I wrote the Redux "Normalizing State Shape" docs page you linked to.
First, you don't need to use Redux if you're using React. In fact, we recommend that most beginners should focus on learning React first, and only try learning Redux once they're comfortable with React.
Second, Redux is independent of React, although they're commonly used together. You can use Redux by itself, or with any UI framework (React, Angular, Vue, Ember, jQuery, vanilla JS, etc).
Third, normalizing is a recommended pattern, but it's not required. Per the docs page you linked, normalizing data has several benefits, but it's fine to keep your data nested if that works better for your application.
Fourth, there's many large complex apps that are written with React and Redux, not just todo examples. See the Apps and Examples list in my Redux addons catalog.
Both the React docs and Redux docs have links to many CodePen / CodeSandbox examples that demonstrate how to use them - see the Main Concepts and Tutorial pages in the React docs, and the Examples page in the Redux docs.
Also, the TodoMVC.com site has several React todo list examples you can look at.
I'd suggest that you take the time to go through the tutorials in the React docs. You may be interested in my suggested resources for learning React and learning Redux, as well as the articles and resources listed in my React/Redux links list.
I'm working with React-Redux and just wanted a bit of clarification as it is a mental blocker for me.
Using the Redux libraries allows us to have a different architecture to manage state - ok.
But using this comes with a variety of helper functions and in the process of looking at online material I have found there are a number of ways of writing your code.
In terms of state management, Facebook's react docs includes stuff like componentWillMount, componentDidMount, getState, etc. Then there's connect(), Redux thunks, etc.
Is it correct that these should still be used when writing Redux-React? Does it defeat the point in Redux? I'm a little confused at where the line is drawn between the two in terms of how to actually write code?
As always, thank you for the advice
Check this official Redux tutorial section: http://redux.js.org/docs/basics/UsageWithReact.html
That will help you to understand how to use them in pair. Even better, check whole tutorial.
Flux is a unidirectional data flow originated in the React team, it hold many benefits (Undo/Redo, Easy to test, one State to the app, and more) and it would be nice to combine it with AngularJs.
Victor Savkin wrote a blog post on how to implement it using AngularJs, but he broke a basic concept of Flux by changing the store instead of re-creating a new instance of it. Another thing that bothers me is that Angular is using ng-model and data binding, using Flux means that we should not use these anymore...
Thinking about all these issues, sounds like Angular and Flux paradigmas are colliding.
Anyone ever really creating a working Angular in Flux that works (As expected)?
With the Flux folk recommending Redux instead, whether the latter and Angular can work together is perhaps a better question. On that, they certainly can be and I recently wrote a blog post http://simonh1000.github.io/2015/10/angular2-one-way-data-binding/. I'm not sure how efficient it is as Redux complement React whereas it substitutes for some of Angular's model handling.