121–130 of 139 posts
They're not perfect. To each their own opinion. But they are what ES6 did for me to the language landscape.
The TypeScript boilerplate that hooks eliminate for a react redux app is just insane. I don't think I can ever go back. For the slight bit of magic that make hooks work, you end up with such a concise function that describes the important parts and not the boilerplate. They're not perfect. To each their own opinion. But they are what ES6 did for me to the language landscape.
I just wrote a tutorial that shows how to use Redux Starter Kit, TypeScript, thunks, and React-Redux hooks together. Should hopefully be a big help, for the reasons you described:
https://redux-starter-kit.js.org/tutorials/advanced-tutorial
Earlier quoted context omitted.
I don't understand the hate against class based components. React class-based components are dead simple to understand.
It's not classes themselves, it's the lifecycle methods, the constructor, this, state, and it all interacts. Hooks let you do more or less the same thing, but IMHO with a simpler and clearer API. You have more control too. Look at the parameters to useState to see what I mean.
The class API lifecycle methods are kind of a mess, and useEffect() seems like a more convenient abstraction. But I could imagine replacing the lifecycle methods with hooks that are added at object construction and get similar benefits. I wonder if the problem is not so much classes, but just the API that happened to evolve.
Earlier quoted context omitted.
Yeah, React seems to have been designed under the assumption that DOM operations are the only thing front-end code can do that takes non-zero time. Like, here's the first line of their document describing how to use to improve performance using things like PureComponent: ( https://reactjs.org/docs/optimizing-performance.html ) > Internally, React uses several clever techniques to minimize the number of costly DOM ope…
Could you elaborate? Rendering perf is pretty much the least of my concerns, even on my apps which support IE10. Most "perf" problems I find are related to fetching and appropriately caching data.
I hoisted the state of an input box up a few layers because other parts of my app are affected by the current typed content. Since I'd been careless passing closures in as props to expensive components, they were getting re-rendered on every keystroke. It was noticeably sluggish.
Earlier quoted context omitted.
Could you elaborate? Rendering perf is pretty much the least of my concerns, even on my apps which support IE10. Most "perf" problems I find are related to fetching and appropriately caching data.
Not the parent, but here's one that I hit recently: I hoisted the state of an input box up a few layers because other parts of my app are affected by the current typed content. Since I'd been careless passing closures in as props to expensive components, they were getting re-rendered on every keystroke. It was noticeably sluggish.
`const { data, loading } = useFetch("/query", {page});`
is not only shorter than the corresponding slew of lifecycle method implementations that would be required in a class component, it's also much more direct and readable. Trying to recover the intent of code by reading the implementation of various imperative methods is painful and error-prone, whereas it's hard to imagine how the above could any more effectively communicate the intent - every single token is meaningful.
Earlier quoted context omitted.
(note this is not directed at redux, react-redux, or the wonderful redux-starter-kit library. I'm also a huge, huge fan of how createSlice combines action constants, action creators, and reducer handlers, all in one.) Those react-redux hooks just exemplify the issues I have with hooks. Yeah, potentially less code, but with more (and in some instances, completely unheard of) gotchas, more that the developer has to do…
FWIW, the "stale props/zombie child" issues described in the React-Redux hooks docs [0] really have nothing to do with the hooks themselves. It's a combination of: - The long-standing problem of trying to synchronize an external synchronous state container with React's async rendering cycle - That our existing solution for this problem requires overriding values in context for connected components - The fact that con…
I've encountered the issue before, but never knew the name. After bumping into it a couple of times I just changed up how I use react-redux.
Earlier quoted context omitted.
That seems a bit unfair. There are some weird edge cases with useEffect, no question. I don’t think they’re bad enough to want to go back to using classes... but I think the OPs post was a bit more specific than you’re giving them credit for, and they stuff like useAsyncEffect exists because it is a common pain point. For example, this useRef / useEffect combo mystifies me even now: https://stackblitz.com/edit/react-…
> For example, this useRef / useEffect combo mystifies me even now: https://stackblitz.com/edit/react-ts-zhvuha On this particular point, the reasoning is that refs are meant for values that don't need to trigger a rerender[1] -- an escape hatch, rather than something you reach for by default. In that sandbox, you can accomplish what you mean to accomplish by using state rather than a ref. [1] https://github.com/face…
It’s harder to just use state for example, when you need a ref to a canvas to get the 2d context.
Earlier quoted context omitted.
Not the parent, but here's one that I hit recently: I hoisted the state of an input box up a few layers because other parts of my app are affected by the current typed content. Since I'd been careless passing closures in as props to expensive components, they were getting re-rendered on every keystroke. It was noticeably sluggish.
Just out of curiosity, is that in production mode, or just in development?
Earlier quoted context omitted.
> You can't create abstractions where a hook calls another hook. Not sure if I understand you correctly, but isn't this the purpose of custom hooks? You should be able to freely call hooks within other hooks.
You absolutely can create abstractions where a hook calls another hook. It is perhaps the single most useful change hooks have given me. Of course you need to follow the same rules in the hook (always call every hook it calls, in the same order, so you don't mess up the order above).