6 ms·

To me it's all about intent. By using a function instead of a class, you are basically saying "future reader, this component is nothing more than a simple mappi

• quietbritishjim 8y ago
  I absolutely agree with you. This makes me very skeptical about the proposed feature in React, called "hooks", which is linked to in the article. It lets you add state to your functional components, and it looks like you end up bundling all your code into one function rather than having a separate constructor to initialise the state (to me, separating out that function is a good thing). I would be interested in the motivation for that. Link: https://reactjs.org/docs/hooks-intro.html https://reactjs.org/docs/hooks-intro.html
  • danabramov 8y ago
    >to me, separating out that function is a good thing To us, too, and that's exactly the point of Hooks. They let you extract logic into functions in a way that wasn't possible before. I suggest to read more than a single page -- in particular, extracting custom Hooks is largely the point of the proposal. https://reactjs.org/docs/hooks-custom.html https://reactjs.org/docs/hooks-custom.html I also wrote about this here: https://medium.com/@dan_abramov/making-sense-of-react-hooks-fdbde8803889 https://medium.com/@dan_abramov/making-sense-of-react-hooks-...
    • prossercj 8y ago
      That post has changed my opinion about hooks. I find this gist especially compelling: https://gist.github.com/gaearon/cb5add26336003ed8c0004c4ba820eae https://gist.github.com/gaearon/cb5add26336003ed8c0004c4ba82... Without hooks, that example would require adding a method (or two) to the component class. With custom hooks, that code can go into a separate module. Component bloat has been a problem for us, and if hooks can enable components to focus solely on render logic, I'd say that's an improvement.
      • brlewis 8y ago
        Can't you achieve the same result by leaving only view logic in the component, and having the data-related logic, including the fact that data has changed in a way that may require redraw, handled in a separate object? Here's how I'd do it in Mithril/TSX: class WidthStore { width: stream.Stream<number>; constructor() { this.width = stream(window.innerWidth); window.addEventListener('resize', () => { this.width(window.innerWidth); m.redraw(); }); } } const widthStore: WidthStore = new WidthStore(); class MyResponsiveComponent { view(vnode) { return <p>Window width is {widthStore.width()}</p>; } }
    • cloverich 8y ago
      It reminds me quite a bit of mixins.
  • wongarsu 8y ago
    >I would be interested in the motivation for that The article you link to actually explains that quite well. Basically there are three motivations for hooks: 1. Keep code that belongs to one functionality in one place. For example setup and teardown would be in the same hook, but when writing a class they are scattered among the many things happening in the event methods in the class 2. Allow new ways to compose functionality. You can use the same hook in different functions. You could achieve the same effect before, but this makes it more convinient 3. Produce code that works better with Prepack [1], to make ahead-of-time compiled react runtimes more efficient. It might be some time until this becomes a rolled out advertised feature, but hooks are a good step on the way there 1: https://prepack.io/ https://prepack.io/
  • pault 8y ago
    The problem is class based components have to be written very carefully to remain testable, and the average developer is not that careful. It's basically a foot cannon, and the worst react spaghetti I've seen has always been a result of huge classes that manage way too much state. I believe that making it a convention for developers to break up their components into small, pure functions will raise the quality of most react applications. Recompose has made this possible for a while, but most react devs aren't familiar with it, and baking it into the framework should make that approach less exotic. Of course, you will still be able to write huge functions that manage too much state, but I think classes encourage this more than functions.
  • sametmax 8y ago
    I have this doubt as well. Hooks will allow people to use "class like" features and behavior, but with none of the conventions forced by syntax, plus some pitfalls. To me it seems a good way to ensure most devs (espacially unexperienced casual ones, which are legions in JS by nature of the market) will dump their logic wherever it works with as little structure as it allows. It's a technical debt catalyser, and will make sure nobody feels at home in someone else's code. The community will pay the price in a year. It's also yet another way to do the same thing, and JS has already a lot of those. React as well. Documentations, tutorials and examples will suffer from it. But again, it's very common in JS land where learning anything requires gathering scattered puzzle pieces then assembling them, hoping they are from the same set this time. It allows me to bill more, so I'm not complaining, but it's not fair to newcommers. Note that I can see some nice things about hooks. I just strongly think they don't outweight the cost by an order of magnitude. FB idea of ergonomics and user friendliness, in API and UI, has always been to force their way into things, until it blocks, back down, and fix things when possible or use a workaround. Having been training people in web tech for years, the consequences of such policy show in the classroom. But, hey, more money for me :) Plus when I dev, I have the experience to avoid the pain, mostly knowing when not to do or use things. But I can tell than many of my younger colleagues don't, and a few of my not so young ones too. Still, I wish they gave a bit more though to this aspects of their products: their are brillant technicians, so it's not that they can't, it's just a matter of culture.
    • victor106 8y ago
      I agree with this thinking. One of the key reasons for choosing a framework/library is to enforce (reasonable) constraints. These constraints help in making sure that the framework takes a longer term view of things than just making it easy in the short term.
    • ergothus 8y ago
      > will dump their logic wherever it works with as little structure as it allows. It's a technical debt catalyser, and will make sure nobody feels at home in someone else's code. The community will pay the price in a year. I don't want to downplay your concerns, but I will say that this is already a problem. Part of the goal with hooks (and I can't say if it achieves that) is to encourage the separation of a lot of state-interaction OUT of the components. Today it is much too easy (arguably it is easiest) to write a component that is basically untestable - basically a mini-application in itself, which is the opposite of good React design. I'm hopeful that Hooks will help, and I think the original demonstration focused too much on state and not enough on other interactions external to the component, which is where the real pain today exists. I've not played with the alpha at all to have a feel for how realistic my hopes are.
  • crooked-v 8y ago
    To me, hooks feel like just reinventing mixins, except they have weirder edge case when they break.
  • sunwukung 8y ago
    I think this in turn is a symptom of conflating rendering with state management in the first place. The line between React and vanilla code is blurring more every day - which is a bit greedy for something that's purely meant to be a rendering solution. I would personally advocate to push React as far away from my app code as possible, and instead implement a specialised container class that hooks into React's internals (Controller? Model?) purely to handle localised state changes.
• deleted 8y ago
  [deleted]
• mikewhy 8y ago
  How do hooks fit in with that definition?
• pier25 8y ago
  I agree with you, but now with hooks that's not the case anymore. It seems the React team intends to completely move away form using classes.