This document give me tinglings. Something about how the hooks just click with me and I can see how the web changes with WebAssembly and multiple compile targets (native, desktop, etc.), this will make our lives easier.
Introducing Hooks
31–40 of 310 posts
Re: Introducing Hooks
#32Earlier quoted context omitted.
It's a huge difference, and yet also the same thing. It's the same concepts of props, state, context, and lifecycle behavior as before. It's just that now you can do it in function components, not just class components, and the APIs let you handle things without having to have additional levels of wrapper components and without the complexity of class-related gotchas.
Can someone give me an example where hooks replace a wrapper? All the examples I see can be replaced with a single class, albeit a couple more lines of code.
Context is a great example. Right now, each `` instance shows up as another level of wrapping in the devtools, _and_ requires indentation/hierarchy in the render methods. With `const someValue = useContext(MyContext)`, there's no actual component being used, so both the component hierarchy and the render code itself is flatter.
Re: Introducing Hooks
#33This is pretty interesting but it's not immediately obvious whether it's an improvement over the current system.
Looks like one of those things you have to use for a couple of days before coming to a conclusion.
Re: Introducing Hooks
#34I went from skeptical to sold in five minutes. This API is absolutely beautiful. I have quite a few components in each of my projects that do nothing other than call lifecylcle methods (they render `props.children`). Composing them is sometimes easy, and sometimes awkward. Especially when trying to read a value back from a child component.
With the hooks API, that child component can be rewritten as a simple hook, making it much easily composable.
Thing is, hooks are very simple, and some of them (except `useContext()`) are expressable with react's current API. I'm surprised that none of us thought of them earlier.
Re: Introducing Hooks
#35React is starting to turn from a novel, but essentially simple idea into a clusterfuck mess.
I feel like Redux was a clusterfuck mess and this is the cleanup. Excuse the language. Edit: Expanding on this and why (I think) this solution is cleaner: * In redux you ended up with pointless constant piles of strings that are the named actions. Totally useless in a JS world where a function that IS an action can take up that mantle. * While reducers are a good way to make state consistent, using redux for state ma…
I'll point out that Ryan's demo _did_ show using string constants with `useReducer()`.
Also, our new `redux-starter-kit` library auto-generates action types and action creators for you, _and_ modifies the action creators so they can be used for the `case someAction` comparisons: https://github.com/reduxjs/redux-starter-kit .
Re: Introducing Hooks
#36I know I may be in the minority here, but I can't say that I'm a fan of this feature. I can't envision a scenario where this would be my preferred solution to any of the problems that they detail. Templates should remain stateless, as they are far easier to reason about that way. My gut reaction is that this is a giant step backward.
Re: Introducing Hooks
#37Earlier quoted context omitted.
I feel like Redux was a clusterfuck mess and this is the cleanup. Excuse the language. Edit: Expanding on this and why (I think) this solution is cleaner: * In redux you ended up with pointless constant piles of strings that are the named actions. Totally useless in a JS world where a function that IS an action can take up that mantle. * While reducers are a good way to make state consistent, using redux for state ma…
I'll point out that Ryan's demo _did_ show using string constants with `useReducer()`. Also, our new `redux-starter-kit` library auto-generates action types and action creators for you, _and_ modifies the action creators so they can be used for the `case someAction` comparisons: https://github.com/reduxjs/redux-starter-kit .
What is the downside to changing the example here:
https://reactjs.org/docs/hooks-reference.html#usereducer
To something without strings and hard-coding the actual "reduction code" to something like
export const increment = (state) => ({count: state.count + 1});
And give modern JS languages like typescript import the increment function and use it directly?
Why are we so attached to these action type strings?
Re: Introducing Hooks
#38React is starting to turn from a novel, but essentially simple idea into a clusterfuck mess.
I feel like Redux was a clusterfuck mess and this is the cleanup. Excuse the language. Edit: Expanding on this and why (I think) this solution is cleaner: * In redux you ended up with pointless constant piles of strings that are the named actions. Totally useless in a JS world where a function that IS an action can take up that mantle. * While reducers are a good way to make state consistent, using redux for state ma…
People use Redux way too often and think of features like time travel as nice-to-haves, when in reality they're the main reason why you'd want to use Redux in the first place.
Using Redux just to simply set and get data on every page is an overkill.
For the majority of applications making API calls directly from the component and storing data in the comp state is the way to go.
This is coming from someone who used redux excessively in the past.
Re: Introducing Hooks
#39How the hell do you test the damn things?
Re: Introducing Hooks
#40I went from skeptical to sold in five minutes. This API is absolutely beautiful. I have quite a few components in each of my projects that do nothing other than call lifecylcle methods (they render `props.children`). Composing them is sometimes easy, and sometimes awkward. Especially when trying to read a value back from a child component. With the hooks API, that child component can be rewritten as a simple hook, ma…
Agreed. Having used React since the beginning and having taught it, this seems to me its natural evolution. I also thought the API was beautiful. I also think it will be easier to teach, but I'm less certain about that.
While I think its a great API, I totally understand some of the hesitance expressed by others. Its more churn, etc., it seems to allow for more spaghetti code for intermediate devs perhaps. But, I don't mind the churn, to me, while its been a nuisance, it also often appears like an evolutionary process.