These past few days, i've been playing around with different animation libraries for React, in an effort to find a solution for transitioning between views (not routes), where a view would be a component wrapping other components and so on.
so far i tried:
react-transtition-group
react-animations
react-spring
Still need to experiment with react-motion's Transition...
...and there are a lot more out there, but all these, do what i need, except for one thing... while each state of the transition/style is applied, the child component(s) always update, triggering a re-render (which makes sense by the way), unless the child's shouldComponentUpdate() returns false, or is wrapped inside a PureComponent, both of which are not a solution, since you might (surely) want to do "things" with your component after the transition ends.
All the examples out there, serve their purpose, but they all use either functional components, or simple strings, for demo purposes, none of which one should care if are re-rendered or not, but a simple modification that would log every time the component is rendered, will show that they render multiple times during the transition.
Oddly enough, nobody seems to care, or is unaware. I have found very few questions or issues regarding this matter, though it's very much real, and the libs are very poorly documented on this.
Please share your solutions for avoiding this issue.
My workaround is to wrap the transitioned children/views inside a simple PureComponent, to prevent them from re-rendering, still it doesn't seem right.
Related
I am right now implementing some kind of notification bubble for users of my webpage.
This bubble usually receives a set amount of time which it is 'alive', as in displayed, until it fades out.
When researching on how to do this fading out, I was usually just trying to figure out how to "remove" a component completely. However, it turns out that this is not the preferred way. The actual solution is to simply manipulate its state so it doesn't render anymore.
At this point I was seriously scratching my head. As I am usually working with languages like C++ or C# I immediately thought what the implications might be, but I didn't find anything.
What does actually happen to components which are in a 'lifeless' state? I mean, they still have to exist, right? Isn't this just polluting memory like crazy?
Thanks in advance!
You'll probably want to use React's Lifecycle Methods to unmount the notification bubble after a set amount of time.
It will be better optimized than having it in a "lifeless state" and only rendering on state or props update.
Edit: This doesn't answer the OP's question and is better served as a comment, I'll be leaving it up until they receive a more appropriate answer
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 have a component (table) that contains many lines with data editing in them, with masks in the form of contenteditable, it is possible to select all fields and change all the lines at the same time.
On desktop it works pretty fast, but on iPhone 6 I have unreal lagging, with Safari hanging for 20 seconds for each action.
I completed the recommendations to improve performance from React: prevent reconciliation, pure components, etc ...
Are there ways to improve performance? Is it necessary for me to ponder a functionality change on a mobile device, in favor of performance?
You should override shouldComponentUpdate component life cycle method for every row of the table. Ideally for every cell in every row.
If you have a table and it gets a different props. What happens is that every nested component gets re-rendered. PureComponents might help but writing shouldComponentUpdate is the only way to really control when something gets re-rendered.
Also for really large data list there is a react-virtualized. Check it out. Its pretty cool.
It would be nice if you could post source code though.
Adding to above answer, you should use react-perf module to exactly validate if any change actually made a performance gain.
https://github.com/crysislinux/chrome-react-perf
use this extension to exactly see how many times, each component on your page actually rendered, when you did your problematic/slow user interaction
try reducing no. of renders of each component. Also reduce the no. of components rendering on each such interaction.
try minimising time taken by each component. You can sort by time and focus on the most expensive components. Avoid rendering components higher in heirarchy, first. To find the exact reason behind a component's rendering use following method.
Put componentWillUpdate lifecycle hook, temporarily, and diff previous and next props/states. With this you would get the exact prop culprit behind a rendering. Unneccessary prop change might be in following scenarios:
When prop is just a function which is changing because of 'bind' usage or arrow-function usage, which changes the function reference everytime, and with that, causing new renders, everytime.
There might be a prop being initialised with new Object() or {} notation, which is considered new object everytime and hence new rendering. This can be avoided by a const READ_ONLY_OBJECT = {} and using READ_ONLY_OBJECT everytime a variable needs initialization.
You might be unnecessarily mutating object-type props and doing diffs in componentWillRecieveProps.
There can be more reasons to where we dont want a render but it happens because of the ways react works. Just see that props dont change unnecessarily. Also, dont put unnecssary componentWillRecieveProps/shouldCompoentUpdate checks as it can impact performance negatively. Also when using these, use these as higher in heirarchy as possible.
Some techniques to use
try to avoid using react lifecycle hooks which run on each render.
try reducing any scripts runing on every render.
use componentWillReieveProps, but only if you gain, else point 1 can reduce gains also. Also, using this often can lead to non-maintainable code. Always validate the gains with react-perf tools, before making changes related to optimizations.
use throttling in chrome-dev-tools to create slow device enviroments, use javascript profiling to see which javascript methods took most time.
Try using redux with react, to manage state. Redux also has componentWillReieveProps thing implemented for connected components. So, using redux will help.
When using redux use an appropriate batching stategy. You can also use batch middleware in redux.
Also, similarly, in react try to do events in batched manner so as to reduce amount of time spent in react's renderings and diffing algorithms. Try clubing setStates in react or actions in redux to reduce react scripting time.
Always use appropriate throttling/debouncing techniques while implementing input controls, to get immediate response. You can also use uncontrolled components to have immediate response, if your business logic allows. Idea is to not to run any javascript when user is typing or interacting with your page in any way, else he would notice the jank in devices particularly bad in computing power.
Your action handlers should not be lengthy. If lengthy, try to do them in chunks, asynchronously, with redux-actions or with just promises.
There is more to this list, but the problem is, react as a framewaork is pretty easy to get to work, initially, but sooner or later, any medium sized react app will run into these performance problems, as react's diffing and rendering logic incurs a lot of performance penalties in bad devices, as soon as app grows in size, only option is to get react-performance tools, also, into the build process, asap. This will let you validate and measure your improvements.
I'm fairly new to react, and really enjoying it. In creating components, is there a good rule of thumb (or simple generalization) to consider when deciding if a component should manage it's own state or not.
As example (only as example), an input that gets different classes added based on state, like 'hover', or 'not empty'...
Would it be better to create a component that manages those states internally or just handle that wherever I'm rendering an input?
I know this question may be 'primarily opinion based', but I'm hoping to get a general feel for how to think about it.
Thanks in advance,
-Ted
This is a constant internal battle that you'll just decide on down the line and you're right that it's primarily opinion based (meaning no answer will be correct). However, I can share my own experience and the process I take to decide on how to split the logic of my components.
I think of these things:
How will having/not having that piece of logic affect unit tests? If the component would need too much setup to be tested, then I move some logic into it and away from a parent Container component.
How often will I reuse the component? If it's many many times, then I look at the types of Container components that would render it and, again, if it seems like too much boilerplate is needed, then move the logic.
Does the value change through its own behavior or based on outside queues? In your example of the hover, the behavior changes due to its own behavior so it feels like the className (a prop of itself) is reacting to the component itself.
Most importantly, do you benefit from removing the logic and placing it in the Container? If you think that other component could benefit from knowing the hover state of your input field, then you may want to put the logic in the container. Otherwise you're abstracting away too much.
Application state management libraries such as Redux will often suggest to use their libraries as little as possible and instead rely on internal state of the component. I mention this because as you figure out where to put your logic, you have to think that about the end goal, which is usually to create a web application, with multiple components working together. Abstract too little and you end up creating non-reusable components. Abstract too much and you have tons of boilerplate and configuration lying around that could be trimmed by using internal state.
Zeke has some absolutely great points. I'd just like to add my own guideline, which is:
If the behavior of the component is the same, no matter where it's used, and is not tied to the behavior of the app/environment at large, then state should be internal
otherwise, manage state elsewhere and pass in props