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.
Related
I'm a beginner in programming and I'm trying to understand when it's a good idea to use "handle functions" in my code and when it's better to keep things simple and just put everything inside the button, for example. Can someone help me understand the differences and when it is appropriate to use each approach?
I would consider this choice to be about readability of code, conventions of the codebase, and personal preference.
If it's more than a few lines, I would separate the function from the button to not bloat the JSX.
Recently I've been seeing a lot of examples in blogs where the methods inside React functional components are given an underscore. I also saw this in class-based components and was told it meant they were private (?).
But functional component internal functions are already private and inaccessible outside of the component, right?
Example:
function MyComponent({ propOne }) {
const _getData() {
/// Why does this have an _underscore on it?
}
return (
<div>a div</div>
)
}
It's a naming convention that the Airbnb React/JSX Style Guide (version 2019.05.24) actually warns against:
Do not use underscore prefix for internal methods of a React
component.
Why? Underscore prefixes are sometimes used as a convention in other languages to denote privacy. But, unlike those languages, there is no native support for privacy in JavaScript, everything is public. Regardless of your intentions, adding underscore prefixes to your properties does not actually make them private, and any property (underscore-prefixed or not) should be treated as being public. See issues #1024, and #490 for a more in-depth discussion.
In short:
The underscore to denote private methods is borrowed from other languages.
It doesn't change the method itself.
It's to show that the method is meant to be private and prevent its use.
It's up to you whether to follow the convention or not. There's no need to. If you follow the style guide cited above, you shouldn't. However, it also depends on the people you work for / with, e. g. if the company uses a style guide with the leading underscore to denote private properties.
Example for this convention in another language - Python. From the Naming Convention:
_single_leading_underscore
This convention is used for declaring private variables, functions, methods and classes.
_functionName doesn't mean private, it is just a best practice.
If are interested in writing custom hooks react document suggest to prefix "use" before hook name ex: useCustomeHook https://reactjs.org/docs/hooks-custom.html
Functional component is a tiny function which accepts only props and return HTML in ReactJs.
Just as Jeanne Dark said, it's just a naming convention. It's up to you of course how to type your code, but I would not recommend using the underscore prefix, as you can see for yourself that the function is private without the underscore.
You can read about JS naming conventions here on W3 schools, or maybe even more trustworthy, googles JavaScript style guide.
The docs # https://github.com/acdlite/recompose/blob/master/docs/API.md#withstate says this regarding withState
You'll likely want to use this state updater along with withHandlers()
to create specific updater functions.
Then it has a separate function withStateHandlers() which seems similar though in a slightly different form.
In terms of practical use and why one would be used instead of the other, how do they differ?
Actually withStateHandlers() hasn't appeared until recently version of recompose. I'd recommend that use withStateHandlers() instead of combining withState() and withHandlers() if you can.
The doc under withState() probably need update.
New to ReactJS. Got this on a "join reactJS event questionary" but was unable to compile it. It seems to be missing a React Component class definition for the Item and List.
Is this shorthand style valid?
Is this shorthand style valid?
yes, it is valid code, List and Items are Stateless functional components
In order to run this code you need use babel with babel-preset-react
Yes, they are stateless functions, aka "pure components". They take their props as their only parameter and return the render results. If you do not need to keep track of any state, they are very lightweight both to understand mentally and in terms of the resources needed by React to manage them.
As to why you were unable to compile it, possibly you do not enable the right ES6/ES2015 features in whichever compiler you're using. You are using among other things super calls, object destructuring (in the parameters) and arrow functions. For help with this, provide the specific error message.
It is a valid javascript es6 code, except that multiple dynamic children (here the list of Items) need to have key prop https://facebook.github.io/react/docs/multiple-components.html#dynamic-children
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