I am pretty new to react/react-native and want to develope my first app. During programming I saw that there are two diffrent ways to declare a component. As I understood I always have to use class-components, if I want to access state variables. But according to the react documentations it is also possible to access state variables via useState inside functional-components and now I do not rly know what to use as best practice.
Is there some sort of rule set or coding patterns on when to use class- and when functional-components?
Thank you very much in advance!
Related
I'm trying to figure out what is the purpose of introducing something called custom hooks when its just a function. If I take the following example https://medium.com/from-the-scratch/react-custom-hooks-a-simple-intuition-if-you-still-cant-hit-it-off-8d27fa4ba10, if I don't use the use prefix for the hook, it all still works fine. With the introduction of this terminology called custom hooks I'm not sure whats the purpose of it, or should I just go on using standard functions.
What is the main advantage I get when using the use prefix for a custom hook or function apart from some simple linting features?
What is the main advantage I get when using the use prefix for a
custom hook or function apart from some simple linting features?
Reasons are stated in docs:
Do I have to name my custom Hooks starting with “use”? Please do. This
convention is very important. Without it, we wouldn’t be able to
automatically check for violations of rules of Hooks because we
couldn’t tell if a certain function contains calls to Hooks inside of
it.
In very basic words: You can reuse stateful logic between components, witch is not possible with regular functions. I would suggest that you read the documentation, because ReactJS has a pretty good one :)
Stay safe
Nothing. There is no difference between them. useFoo function is just a function. In source code, it was not dealt with specially. It is just little bit complicated, but no difference between regular functions.
use prefix is just a term, or just culture, whether you obey it is entrusted to you. Of course, obeying the culture bring us good result. But this and that have no connection. Custom hooks are just functions.
I'm trying to use Axios with TypeScript in a React component. The following suggested answer in a different thread seems to provide some pretty good guidance:
https://github.com/axios/axios/issues/1510#issuecomment-385939438
However, something about the suggested approach doesn't appear to be translating well for my component implementation. After fiddling around with this implementation, it seems that I'm still unclear on how state should be initialized in the constructor for this scenario, and possibly within the request().then() handler as well. Here's my current code:
https://github.com/git-it-2020/random/blob/master/axios-react-typescript
The code is fairly simple but doesn't currently compile. Can you provide some guidance on what I'm missing here?
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!
There are many answers regarding react component communication, but seems none of them resolved my problem. Here is my problem's detail. Please help! Thanks in advance.
I'm building a flexible form. The UI is generated by nesting components.
The form data structure could also be nested json objects.
i.e form can have some inputs and sections, sections can have some inputs or sections, and go on.
sections is just UI layout components, doesn't care about data or state.
But input (could be text input, checkbox etc anything to capture data)
The problem I'm facing is any input's validation could depends on any other inputs' value.
i.e inputA has validation expression like formData.inputB >formData.inputA + formData.inputC
But they could also have no dependency at all if you don't give a validation expression.
If I pass the whole formData down the component tree, every time I type in one input, the whole form will rerender.
I have considered redux, but real not sure how redux can help such case. I'm still relative new to react and redux, so I could be wrong.
So what could be a viable solution?
Its a common issue when you're modularizing form elements. I have the same problem.
Redux is by far the most controlled solution. All of the components can listen and update the same object simultaneously. But you can also attach functions as props from the parent that you bind to the parent. The function would fetch the state of the parent and update the state like a makeshift store. If you're a good developer, this is possible but neither are simple to do. Good time to learn :)
There are various solutions to your problem, but in general it shouldn't even be a problem, because rendering (even of large forms) should be quite effective with React.
The core tool for adjusting performance in React is the shouldComponentUpdate method of your component classes. If you're smart about what you pass to the individual form fields and then implement shouldComponentUpdate properly on them, you should be able to update only when needed. In your particular example, you don't need to pass the full object everywhere.
You can just pass value, onChange and isInvalid to each field and calculate the validity at the root (where you have access to the full state). Then the shouldComponentUpdate of your fields can decide just based on those props. (Obviously this is a simplistic example, but as a principle it's sound.)
Sure, Redux is another possible solution. If you keep the state in Redux store and only connect each of your fields to the portion of the state it needs, you should be all set. It brings quite a change in architecture though, so you should choose Redux only if you really want it for your app as a whole.
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