141–150 of 310 posts
I’d say the useState hook should receive a name parameter first and not depend on the call order. That way one can do branching, loops etc. This way it feels like too much magic.
My gut reaction is that Hooks isn't the greatest addition to React. One thing I've always pitched about React is the clean and extremely explicit API (with `dangerouslySetInnerHTML` being my favourite example). The hooks API is taking the dangerous road down to implicitness and magic which can only ever mean bad things in my book. It's really not clear to me how calling the setter for these individual pieces of state…
> 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…
I completely agree.
When I started using React a couple of years ago, the only thing that made sense were the classes.
The bad aspect about React and JSX is that in general there are way too many JS acrobatics which alienates everyone from the codebase who isn't a JS ninja.
Earlier quoted context omitted.
This is where I'm falling on it. What started as initial excitement over a lens-like addition started to feel more like black magic once I realized that it relies _a lot_ on implicit ordering just to preserve a seemingly simple usage pattern. While it may _look_ nice to be able to just call `useEffect` and have it infer the rest, it just ends up masking the flow of a hidden parameter into that component, and convolut…
Component lifecycle methods are easy to grasp conceptually. At different stages of rendering the component, React will call one of these methods. Easy. With `useEffect`, I have no idea what is actually happening here, and I've tried re-reading it a few times.
As for `useEffect`: think about the kind of logic you'd put in `componentDidMount`, `componentDidUpdate`, and `componentWillUnmount`. In CDM, we set up side effects, in CDU, we update those side effects if needed (based on the props, state, and context) and in CWU, we clean up those side effects. If we squint a little, though, we're really only doing two actual operations in those three steps:
didMount: perform side effect A based on props/state/context didUpdate: clean up side effect A, then perform side effect B based on props/state/context didUpdate (again): clean up side effect B, then perform side effect C based on props/state/context willUnmount: clean up side effect C
So the idea here is:
const [name, setName] = useState("world");
function modifyTitle() {
document.title = "Hello, " + name + "!";
return restoreTitle;
}
function restoreTitle() {
document.title = "Untitled";
}
useEffect(modifyTitle);
So we basically have the same sequence of calls as this is mounted/updated/unmounted:
perform side effect A cleanup side effect A, then perform side effect B cleanup side effect B, then perform side effect C cleanup side effect C
The only difference is we never told React _when_ to perform these steps, just _that it should_ perform them at the appropriate time.
My gut reaction is that Hooks isn't the greatest addition to React. One thing I've always pitched about React is the clean and extremely explicit API (with `dangerouslySetInnerHTML` being my favourite example). The hooks API is taking the dangerous road down to implicitness and magic which can only ever mean bad things in my book. It's really not clear to me how calling the setter for these individual pieces of state…
I agree that the `useState()` aspect _looks_ a bit magical, but it's ultimately doing the same thing that `setState()` does in the end. React already knows what component this is, and you're telling it to queue up a re-render for that component.
Also interestingly, it seems that `useState()` is actually a wrapper around `useReducer()`, and not vice-versa :)
> 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…
React is intended to be a view-only library but in practice people shove all their business logic in there, mostly because React makes it incredibly hard to do anything else. Because of this, innovations in React are going in the wrong direction. This Hooks feature is meant to solve a portion of this, but it's going in the wrong direction. A better bigger-picture innovation would be to have a React-alike that is actu…
This is really interesting. I'm a big fan of any abstractions that reduce the amount of code I have to write. Just a personal preference. Other programmers like to avoid "magic", but I love it. `useEffect` feels much cleaner than the component lifecycle methods, and I could add some abstractions on top of those. e.g. a higher-order function that adds/removes a window event listener, and you can just pass the event an…
I'm currently looking at revamping our WIP React-Redux v6 branches to use hooks internally. Looks really promising so far, but I'll have to keep playing with it and see how it turns out.
Our goal at the moment is to publish React-Redux v6 that is basically API-compatible with v5, and then open things up to discussion about potential alternative API approaches for a future v7.
Am I getting this right: it’s an implicit global stack for the render loop? Sounds like a combination of the worst design features of OpenGL and Forth, to be honest... OTOH, React has been pretty good about taking discredited design ideas — like Adobe Flex’s style of mixing XML declarations into ECMAScript code — and injecting them with new vigor. So maybe this one too is better than the initial impression.
Personally, I loved Flex’s mxml/actionscript combo. Its main (fatal) flaw was targeting the flash player. At the time, moving to html/js felt like a big step backwards on developer experience.
This is interesting. I'll have to spend some time mulling over this before the benefits sink in. It seems like a much more confusing and less composable API than recompose, which is how I add state, lifecycle, and other React class features to functional components. I've been completely avoiding React classes for a while now and using stateless components with recompose for over a year now, and I find it to be a wond…
The author of recompose just end of life'd it today in favor of Hooks. Read his comment on the top of the recompose readme.