News for hackers. Stuff that matters.
Re:What Are the React Team Principles? by 2Pacalypse- on Wednesday December 25, 2019 @12:44PM (#21879543)
I'd be interested to hear a practical example of these principles applied. For example, how do these principles lead to the creation of hooks API? I'm not trying to say they don't, just genuinely curious.

As someone who has been using React for five years and especially liked it for its simple class API to write components, I was a bit taken aback by the introduction of a new powerful API that is incompatible with the simple class API.

Re:What Are the React Team Principles? by sb8244 on Wednesday December 25, 2019 @01:07PM (#21879680)
I feel that hooks make it easy to go from functional component (simplest way to get started) to stateful component without "rewriting" it to the class. It's easy to do that rewrite, but painful when you have to do it back and forth as you're playing around with component design.

That's represented in one of these principles.

Re:What Are the React Team Principles? by ben_jones on Wednesday December 25, 2019 @03:02PM (#21880156)
I've found several "subtle" benefits from hooks in the way they can influence more idiomatic code structure, for example "code smell" becomes more intense and dictates more actions because when a function is > 100 lines of code it sticks out like a sore thumb. It's also influenced us to put more business logic into redux where (arguably) it belongs.
Re:What Are the React Team Principles? by sb8244 on Wednesday December 25, 2019 @03:20PM (#21880235)
My coworker showed me that hooks are just functions, so you can still pull apart your functional components hooks into a bunch of imported or defined functions.

Of course that doesn't help if you're still pulling in a lot of hooks, since it's 1 line per hook minimum.

Re:What Are the React Team Principles? by acemarke on Wednesday December 25, 2019 @12:56PM (#21879636)
The primary point of hooks was to give function components the same capabilities that classes already had. In that respect, letting classes use hooks would have been superfluous.

At the same time, the React team _could_ have chosen to implement support for hooks in classes, but chose not to, both for simplicity and as a carrot to encourage folks to use function components where possible. Based on the discussions and examples I've seen, capabilities like Concurrent Mode and Fast Refresh work better with function components because there's fewer edge cases to worry about. While classes aren't going away in the foreseeable future, there's valid reasons to try to get the community to adopt function components more.

Re:What Are the React Team Principles? by 2Pacalypse- on Wednesday December 25, 2019 @01:19PM (#21879740)
Well, as far as my understanding of hooks go, and please do correct me if I'm wrong, hooks are not just about giving functional component an option to use state and lifecycle methods. They are also a much more powerful and flexible replacement of mixins and offer an (arguably better) alternative to use certain design patterns, like render props.

I did assume that hooks were not supported in classes because it would be too complex to support that use-case, but the linked article specifically has an "Absorb the Complexity" principle, so it seemed a bit weird to me. Also, I understand the decision to try to motivate the community to use function components more, but is this the trend that we can expect to continue seeing in React? Certain APIs being phased out until they finally become deprecated. I know it has happened a few times already in React, but not on the level of something like a class API.