so I'm using react and I'm taking the approach of using Immutable data in my project with facebook's immutable.js library.
I know that React is way faster than every other library because it updates only the neccesarry DOM, I knew that it does a reconciliation process before updating and that in the process it creates Virtual DOM and compares them, but I never really knew how it knows what to update.
So I did some research and its true, the reconciling algorithm of react is really awesome and saves time, but then something hit me, where does the shouldComponentUpdate method enters?
So react invokes the shouldComponentUpdate for each component and if it returns true, the react does the reconciling process which includes creating virtual doms and comparing them.
So why shouldn't we implement the SCU method for every component? Well react also gives you an answer that includes comparing mutable object and that the equality in this cases should be a deep one, and that would take too long, so you might as well not implement it.
And here is the part where I ask my question, if my entire data on my project is in fact immutable, why shouldn't I implements the SCU with a simple shallow equality on all of my components? This way we spare the reconcile process and our app will be much faster.
As far as I know, if you have SCU method and if it returns true, React creates virtual DOM and compares it with existing DOM. If they are equal, nothing happens, however, still that costs for creating virtual DOM. On the other hand, if SCU method returns false, it skips the component and subcomponents and stays same (virtual DOM is not created).
Implementing SCU component like the sample code below is the most efficient way if all props are gathered under values key as Immutable and there is no state in the component,
shouldComponentUpdate(nextProps) {
return !Immutable.is(this.props.values, nextProps.values)
}
Related
I would say that I have good experience with a lot of OOP languages. Most with Java. I've made full stack development with Spring boot and now i'm trying to learn React.
My point with all this is that maybe I'm to used to OOP languages so there are some "design philosophies" that I cannot understand.
I've started with this tutorial video:
https://www.youtube.com/watch?v=Ke90Tje7VS0
It's pretty great and clear but I have an issue in one part in particular:
1:47:55 Removing the Local State
To summarize the video, he makes an component called Counters that contains N componentes called Counter. This component Counter is just one number and a button that every time is pressed the value should increments by 1.
Originally, this value was stored as an state in the Counter component. This makes sense thinking in a OOP way. But then, in that chapter from the video he suggested to remove that state and mantain that value in the parent component, Counters.
And every time the button "INCREASE" is pressed, what is doing is calling Increment in the parent component. The value is stored in Counters. Not Counter.
Now, my question: Why not keep the VALUE state in the Counter component, and everytime is increased, inform the parent component that this happened?
How is this design philophy called? Any tutorial/book/video that explain this better for the people that comes from a OOP background?
Sorry is this is a dumb question. Thanks!
The goal of this is to have a "single source of truth". In other words, if this piece of state is only kept in one place, then it's impossible to have a conflict between different versions, because different versions don't exist. And this in turn means you don't have to devote any effort or code to trying to keep states in sync with eachother.
Now in principle you might think of having the child component be that single source of truth. But the way react is designed, props always flow from the top of the component tree to the bottom. A parent component passes props to a child component, not vice versa, so react makes it very convenient for the state to exist in the parent component and then be passed to a child.
As you mentioned, the child could notify the parent of changes, which would be done through a function prop. But in order for the parent to rerender and use this new data, it will then need to set state on itself (setState causes render). And now the state is being kept in two places, which is the thing we were trying to avoid.
The design philosophy is known as smart vs dumb components and it becomes more useful when dealing with larger state management libraries like Redux. The goal is to separate your logical components, those that deal with manipulating the state, interacting with other libraries like Redux etc. From view components. That way your view gets to be a pure function, reacting only to the parameters passed explicitly to it. This makes them extremely easy to test. And you only have to test that your smart components are passing the correct values to the view only components. Decoupling in this way makes testing smoother and prevents a variety of bugs that could otherwise be difficult to track down.
I completed my application in react native but after building its slow. Then I started to research to improve the performance of the application. I found this documentation on the official website of the react native and I am sure this will help me but I am unable to get it into my head. Please can anyone tell in easy words what the following documentation is saying:
If you are using immutable data structures, this would be as simple as a reference equality check.
Similarly, you can implement shouldComponentUpdate and indicate the
exact conditions under which you would like the component to
re-render. If you write pure components (where the return value of the
render function is entirely dependent on props and state), you can
leverage PureComponent to do this for you. Once again, immutable data
structures are useful to keep this fast -- if you have to do a deep
comparison of a large list of objects, it may be that re-rendering
your entire component would be quicker, and it would certainly require
less code.
I will be glade. Thanks !!!
If you're using a static object, you can render your component as a PureComponent like it says above. Then, you can pass it props or set the state with the words you want displayed.
When you do that, the FlatList will re-render only the portions of the data that it needs to, depending on what changed. What the last part of it is saying is that a PureComponent does shallow comparisons - if something in an array changes, but the array itself doesn't change, then your FlatList won't update. However, with an immutable object, you can always declare it as a PureComponent and it should be faster.
We have a case where we need to re-mount a third party component to trigger stuff that happens in the mounting process. Not to confuse with update/rerender that we'd prefer, but we have restricted control over the component.
However, we've been searching around and found that quite many suggest using the key prop and change the value once the component should re-mount. We've tested it out and it seems to work as expected but the thing is that there is no official documentation of this approach at https://reactjs.org, and I have never seen it before. Only together with lists/iterations but not on single elements.
What do you think?
You can find an indirect answer to your question in React docs.
Keys should be stable, predictable, and unique. Unstable keys (like those produced by Math.random()) will cause many component instances and DOM nodes to be unnecessarily recreated, which can cause performance degradation and lost state in child components.
So the re-mount behavior is intended. IMHO as part of the reconciliation algorithm, it is also stable.
Using keys only makes sense in lists (arrays) inside JSX. Otherwise this shouldn't have any effect and if it does I wouldn't want to rely on this behaviour in production as I don't think it's intended
https://reactjs.org/docs/lists-and-keys.html#keys
Could you tell us what the third-party library that you are using is? Perhaps there is a better workaround for your problem!
I'm working on a part of a React app in which a high-level component creates and passes certain props down through a few layers of components that don't use them to a final component that does.
When validating props with propTypes, is there a good reason to list these props to be checked at every level, going down through the layers? Or is it acceptable to check them only in the final component that uses them?
It seems to me that the former method is redundant; the latter seems to make more sense to me, but I'm curious if there is a reason why I ought to do the former. I haven't seen any discussion on it, which could mean it's an unimportant question, but I'd be interested to know.
I agree with you about if you use props only for dril down for children in the tree, it can be done only once at the leaf components, where you realy use this data. I recently find out that one more place is important for props validation: the components which fetch data from out of app scope, such as backend, because sometimes the structure of the data changes or the data types, then it will be dificult to find which part is broken without props validation.
I read about React being very fast. Recently, I wrote an app to test react against angular. Unfortunately I found react performing slower than angular.
http://shojib.github.io/ngJS/#/speedtest/react/1
Here is the source code for react. I'm very new to react. I am sure I'm doing something wrong with my react code here. I find it unusually slow.
https://jsbin.com/viviva/edit?js,output
See if any react experts can find the bottlenecks.
Update 1:
Removed the usage of context.
Better usage of setState.
Better usage of shouldComponentUpdate.
I still can't make it faster than angular or even close to it.
https://jsbin.com/viviva/96/edit?js,output
Update 2:
I made a big mistake by creating 2d arrays in the cell component. So I moved them to a mixin. Now I believe that react is faster than angular in DOM manipulations.
https://jsbin.com/nacebog/edit?html,js,output
Update 3:
My mistake again. I did it wrong which made it faster. After analysis, it was rendering incorrectly. If anyone can help me understand, if this could be any faster. I know react is not good at dealing large arrays. In this scenario, it's dealing with four 3d arrays. https://jsbin.com/viviva/100/edit?html,css,js
React's performance is exaggerated. It's fast enough for most real use cases. Rendering large lists is its main weakness.
Also this always returns true (unless the update is triggered by setState). You need to shallow compare the props.
shouldComponentUpdate: function(nextProps, nextState) {
return this.props !== nextProps;
}
And you should be using props in the places you're using context.
This is a very contrived example in my opinion.
As stated above, you are using context incorrectly.
There is no need for a mixin: the number of columns and rows can and should be passed down as props. create2DArray, getRandomNumber should be declared at the top of your script as simple global functions.
You are setting the state incorrectly. You should never change the state like this this.state.some = 'whatever', you have to use setState
this.setState({ some: 'whatever' });
You're using context incorrectly, the documentation states:
In particular, think twice before using it to "save typing" and using
it instead of passing explicit props.
It's mostly beneficial for passing context objects like currently logged in user or perhaps a redux store. Your app is using context when it should be using props.
You'll need to ensure that shouldComponentUpdate is a meaningful predicate. See https://facebook.github.io/react/docs/advanced-performance.html
If you correct those two things it'll be a better measure of React's performance compared to Angular. At the moment you've got a well tuned Ferrari running against a model T Ford (held together with chewing gum).