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
Related
I am currently building a Tetris game on React just to practice hooks (used to develop in class components back in the day, kind of left React for a while and yesterday I decided to use it once again).
The game is working perfectly well, and it behaves as expected on each and every situation, however, there is a constant warning related to using a function within useEffect without it being a dependency.
To clarify - I have a useEffect function that all it does is call an updateFunction and is dependent just on the x and y coordinates of the moving Tetris block. The update function updates the state of the board whenever the position of the shape changes.
I know that React re-creates functions on each and every render, but giving a useCallback to the update function would cause it to be re-created endlessly (as then, the complier would ask me to make it dependent on the board state, thus each time it updates the board, it'll be forced to be re-created once again), and this causes an infinite loop of rendering.
Is it really necessary to put every function within useEffect as a dependency, even if said functions only causes a visual rendering to show the current state of the game?
You can always put whole function inside useEffect and you want get this error and problem
Someone just asked the similar question, and my answer is there, React won't let me use `useEffect` in a completely reasonable way
The answer to your question is that, no you don't have to, if the warning doesn't bother you, and your code is still working, then move on.
Otherwise you can try to find a way to disable this linter, or ask yourself why not to meet all the dependency requirement.
It's best to think of the effect dependencies as "correct" or not, and not try to tailor them to achieve some specific behavior. (The vast majority of the time anyway)
This means that if an effect uses a value that could possibly change, then it's declared as a dependency. Sometimes you app works fine if your dependencies are "incorrect" because elsewhere you can guarantee a value is constant. But this is more about maintaining the application than having it work currently.
Later if you change how one of the dependencies works in a refactoring, then the effect now may need to re-run and doesn't leading to strange and hard to diagnose bugs like stale values where you can't tell where they come from.
If this leads to cumbersome hooks with huge dependency arrays that infinite loop themselves, then it's an indication that logic is messy and needs to be refactored, split into multiple effects, rethink how the data flows through your hooks, etc.
It's hard to advise specifically without seeing your code. But in your case it seems like you could make the "update function" take arguments instead, which means it could then be completely static. Or if you did use useCallback that depends on x,y then it would regenerate when those change, but you probably have a lot of logic to run when those change, so that's probably expected.
Summary:
I would advise you to take the warnings of eslint-plugin-react-hooks seriously, and clean your code until it passes. In the long wrong, in a large and complex application, it really helps keep things clean.
There are very rare exceptions that come up when doing non standard things, but it's worth it to try your best on this before resorting to ignoring those warnings.
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.
While using ReactJS, I have a parent component, which contains two children components:
- Main
- NewReminder
- ExistingReminders
Main passes information to NewReminder as well as ExistingReminders through props. When a NewReminder is created, it must update the list that the user sees of ExistingReminders. This seems like a great use of redux, where the state can be updated from NewReminder, and will update this list, but I don't know if there are alternatives as this might be far too simple to set up an entire redux environment?
Should I go ahead and begin implementing Redux, or do you have any suggestions for alternatives?
It's really quite a broad question, but I'll give it a crack: you should consider taking the advice of the author:
Seriously, it bears repeating.
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.
Redux doesn't have to be complicated (in fact, you could argue it goes out of its way to stay fairly light and simple). Once you've set up the basics a few times it's not intimidating. However, if you can write a simple application without Redux in a way that's clear and maintainable, sounds like a win to me!
When rendering a list, one should add a key prop to each element of the list. This is described in the documentation as a "hint" at which child elements may be stable across different renders. Changing the key's value will cause that element to be unmounted and remounted.
This behavior also currently works for any components, even ones that do not represent list elements, and is recommended by some React developers as a way of forcing any component to remount when necessary. Is this behavior, which goes beyond what is described in the documentation, a stable feature of the API that can be relied upon, or should it be viewed as it an implementation detail that is subject to change at any time?
The key attribute is intended to differentiate similar elements. Setting a new key would indeed force a re-render, but I'm not sure why you would want to take such a brute-force approach. Without knowing more about the specific situation you're encountering, it's hard to give input on whether it's a good or bad idea, but in general, it is a "hacky" implementation that is going to undo many of the benefits react provides behind the scenes in regards to it's usage of the virtual dom.
In general, if you've gotten to a point in your code where you need to force react to re-render when it isn't doing so of it's own volition, it probably means there is a more fundamental problem with your code. This would be a band aid solution to that deeper issue, even if it is a fairly stable and reliable band aid.
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