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!
Related
I was learning Redux and came across the three principles of it:
single source of truth,
state is read-only,
changes are made with pure functions.
I understood the idea behind the first principle but still find myself in confusion with the other two.
Concerning state is read-only, I got that we can update state only via actions and is it true that the reason for using actions to update state is predictability which ensures that there is no unexpected and sudden changes and thanks to actions it is clear when and how state is changed(action is kinda like protection of state being changed unexpectedly)? Right?
Lastly, about changes are made with pure functions yeah I understood that it also gives predictability but cannot get the actual and clear reason behind that. \
Thus I really need your kind help
I'm using GraphQL + Relay in my app and find myself wrapping almost every component with createFragmentContainer, including those very low in the DOM hierarchy (usually functional components).
Is that the right way to use fragments? I'm wondering what are the guidelines for when to wrap components in fragment containers? Seems redundant to wrap a component when it only needs one field and I can pass that data from the parent via props.
I'm using Relay but I think the concepts are similar to Apollo as well.
This is the answer from my co-worker Jan Kassens who works on the Relay team:
If splitting out components makes sense to you, you should go for it. I find smaller modules generally help making code more understandable.
Now, a Button component probably doesn't have to have a fragment attached to it, but if it's a "Like Page" button with a mutation and maybe label specific to the page, I think it makes total sense to make that it's own fragment container.
As with so many things in engineering, there's probably trade offs in splitting out too much, but we've spent a lot of thought on making fragment containers as lightweight and efficient as we can so you shouldn't think too hard about introducing overhead.
Yes, it is. Instead of querying all the data on root component and pass to others as props, you should create fragment containers and each of this component query its own data. And due to relay data masking, these data from fragments can only be seen inside the component that required it.
Maybe this is a good reading: https://medium.com/entria/relay-apollo-anti-pattern-d9f4dea47738
And this on Data Masking: https://facebook.github.io/relay/docs/en/thinking-in-relay.html
Hope it helps :)
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
Most of the Flux documentation I've found is lacking in the discussion of Components vs. Containers.
I know that it's considered best practice to have containers as the sole elements responsible for listening to the stores. This absolutely makes sense because;
It limits the number of components listening to the stores.
Child components have a single place (their props) to receive data from.
But some explanations imply that Containers should also be responsible for all calls to the ActionCreator. And on that point, I'm not really seeing the advantages.
Convince me I'm wrong?
Disclaimer: My only experience with Flux comes from Redux, which isn't quite the same pattern - that said, I believe the concept is the same either way.
Effectively, the reasoning behind having the container call the action creators is the same as the reasoning for passing data through the props instead of just having every component listening to the store - it means that your presentational components don't need to know anything about the world around them.
Take the (completely original and not overdone in the slightest) example of a Todo list app. You could hard-code that clicking a TodoItem fires a CompleteTodo action - but then if I want to display a read-only version of the item elsewhere in my app, I'd have to make another version of the component that doesn't call that action creator. If you pass a callback that calls the action creator in as an optional prop instead, the item no longer has to manage what happens when it's clicked - it just has to tell the parent when it happens, then the parent is free to do what it wants with that information, or even ignore it entirely.
It's not a perfect example, but hopefully it illustrates the reason why some people recommend doing it that way!
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