61–70 of 98 posts
I like hooks but here are some uncertainties that bother me. I am quiet new to React and hooks, but I am a senior dev, so I am wondering if any of this confuses others. * I sometimes have to use an empty dependency array inside useEffect to run something only when component first loads. The linter yells at me, but it makes sense. I once read an article which told to put things in functions and wrap those functions in…
I like hooks but here are some uncertainties that bother me. I am quiet new to React and hooks, but I am a senior dev, so I am wondering if any of this confuses others. * I sometimes have to use an empty dependency array inside useEffect to run something only when component first loads. The linter yells at me, but it makes sense. I once read an article which told to put things in functions and wrap those functions in…
Earlier quoted context omitted.
I get what you're saying but disagree. Hooks are essential and make life much easier for the react developer, especially when using something like `react-redux` or `react-router`. Prop-drilling or HoC might seem like a better design until you actually have to work in a system that leverages them and realize it's an indirection nightmare.
I would go a step further and say that React Components should not manage their state internally. (this.state was a mistake to add to the project) You can create every single UI in the world using pure functional components. They are easier to understand since they act like every other function, and they are simpler to test. Keep your state externally and just grab what you need on each subcomponent with the `connect…
I like hooks but here are some uncertainties that bother me. I am quiet new to React and hooks, but I am a senior dev, so I am wondering if any of this confuses others. * I sometimes have to use an empty dependency array inside useEffect to run something only when component first loads. The linter yells at me, but it makes sense. I once read an article which told to put things in functions and wrap those functions in…
Earlier quoted context omitted.
I would go a step further and say that React Components should not manage their state internally. (this.state was a mistake to add to the project) You can create every single UI in the world using pure functional components. They are easier to understand since they act like every other function, and they are simpler to test. Keep your state externally and just grab what you need on each subcomponent with the `connect…
not sure i understand you correctly, but keeping all state external just clutters up the store i feel. if the state is not used anywhere else and you also don't need to change it externally i would not move state out of the component. also if your state is always outside of your component they will only be reusable if you hook up the store in all your projects the same way
For example, you can have a date picker that just accepts variables to display the current state and parent component that reads data from the store and passes it into the date picker component.
This method is also great for debugging, since you can just replay the state transitions over again if there is an application error. If the component holds the state, then it can be cumbersome to reproduce the error.
Earlier quoted context omitted.
For one thing you may not use the ref attribute on function components because they don’t have instances. That means the component can't have a .focus() method for example. For simple components hooks may be fine. For more complex ones I prefer classes.
Maybe I misunderstood, but isn't this what `React.forwardRef` is for?
I like hooks but here are some uncertainties that bother me. I am quiet new to React and hooks, but I am a senior dev, so I am wondering if any of this confuses others. * I sometimes have to use an empty dependency array inside useEffect to run something only when component first loads. The linter yells at me, but it makes sense. I once read an article which told to put things in functions and wrap those functions in…
I would ignore whoever told you not to use an empty array for the dependency argument. Change your linter rules. It's fine.
Earlier quoted context omitted.
I would go a step further and say that React Components should not manage their state internally. (this.state was a mistake to add to the project) You can create every single UI in the world using pure functional components. They are easier to understand since they act like every other function, and they are simpler to test. Keep your state externally and just grab what you need on each subcomponent with the `connect…
Redux is global state. Adding all local state to a global store will result in a complete mess for any non-trivial app.
Most of the time it mirrors the structure of a file system which is the exact way (almost) every program is written.
As with most software projects, keeping organized is like 80% of the battle.
I like hooks but here are some uncertainties that bother me. I am quiet new to React and hooks, but I am a senior dev, so I am wondering if any of this confuses others. * I sometimes have to use an empty dependency array inside useEffect to run something only when component first loads. The linter yells at me, but it makes sense. I once read an article which told to put things in functions and wrap those functions in…
class Foo extends React.Component {
componentDidMount() {
fetchFoo(this.props.id)
.then(foo => this.setState({foo}))
}
render() { ... }
}
const Foo = ({id}) => {
const [foo, setFoo] = React.useState(null)
React.useEfect(() => {
fetchFoo(id).then(setFoo)
, []) // Linter complains, and it should!
return ...
}
The first one just feels like a premature optimization. Yes calling setCount forces a rerender of that component, but unless there's lots of subcomponents inside that component, I wouldn't bother. Chances are later you'll need that state in the view, and if you have "unexpected side effects" from rerendering then that is the problem. The other tips are fine; effects should have a single responsibility and links and b…