21–30 of 310 posts
Earlier quoted context omitted.
Care to write a substantial contributing comment, or do you intend to keep this random complaint about the simplification of a common pattern in React as shallow as possible? Edit: No really, I'd like to hear why you think this would make React a "clusterfuck mess" rather than... simpler.
I actually agree, this is a mess. This is wildly more complex and confusing than the current state of affairs.
"You might be curious how React knows which component useState corresponds to since we’re not passing anything like this back to React. We’ll answer this question and many others in the FAQ section." While I appreciate the functional usage of state, this type of magical behavior worries me a bit. Wasn't more straightforward semantics possible (even if the syntax wasn't similarly straightforward)?
If it turns out to be a bad idea (hypothetically speaking, I haven't read the article yet so I don't know), will it be backed out?
Wouldn't it make more sense for it to be versioned as an experimental fork/branch instead?
Is it just a syntactical difference or is there something more fundamental that I'm missing here?
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.
React is starting to turn from a novel, but essentially simple idea into a clusterfuck mess.
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 management when you actually don't have 17 different producers and 1 consumer it's major overkill. Most of the time you actually have 1 or 2 event (and value changing) producers and MANY consumers on the screen at one time.
* When you DO need a reducer, instead of making that the norm, this new hook library does provide a useReducer function that works exactly like that- and guess what? NO STRING CONSTANTS YAY.
I think the only downside I can think of is TTDebugging might be complicated to create under this dome, but was the same issue for stateful classes. That being said, it might be more possible now that the control is placed in a single feature area.
As someone who struggled hard with some aspects of learning react, i felt this to be the absolute opposite. Watching people to combine and spread logic over dozens of functional components, and drag in other external libraries like recompose to do stuff like lifecycle hooks, and using HoC's, just to avoid classes makes my head hurt.
> Only call Hooks at the top level. Don’t call Hooks inside loops, conditions, or nested functions.
I really don't like this, and to me this feels really finicky, and unfortunately the explanation doesn't make me feel warm and fuzzy ether. While it is great they are adding a linter plugin for it, i feel like this is going to be really easy to shoot yourself in the foot, and feels like it is relying on behind the scenes magic too much.
"You might be curious how React knows which component useState corresponds to since we’re not passing anything like this back to React. We’ll answer this question and many others in the FAQ section." While I appreciate the functional usage of state, this type of magical behavior worries me a bit. Wasn't more straightforward semantics possible (even if the syntax wasn't similarly straightforward)?
In the keynote, Dan talked about how this works. It depends on the order that useState is called, which makes conditional branches a no-no (there's a linter for it).
Edit: And yes, slight concern of course, it's the got some rough semantic equivalents to a thread-local in Java, albeit in Java the danger exists downstream, this danger is only exhibited during initialization it seems.
> In our observation, classes are the biggest barrier to learning React. As someone who struggled hard with some aspects of learning react, i felt this to be the absolute opposite. Watching people to combine and spread logic over dozens of functional components, and drag in other external libraries like recompose to do stuff like lifecycle hooks, and using HoC's, just to avoid classes makes my head hurt. > Only call…
This is marketed as a proposal and a RFC, but it's already in React v16.7.0-alpha. If it turns out to be a bad idea (hypothetically speaking, I haven't read the article yet so I don't know), will it be backed out? Wouldn't it make more sense for it to be versioned as an experimental fork/branch instead?
We could use a separate branch but in practice we prefer to use feature flags for development; we find it easier to manage. Once we reach a definitive conclusion on whether to include it, we’ll remove the feature flag.