9 ms·

I love React Hooks

104 points by vijayst 8y ago

denverkarma 8y ago
How is it that React gets celebrated for “solving” problems that React created in the first place? The entire paradigm of React keeps changing as each pervious iteration proves to be “messy” or “over complicated.” createClass? Nah that’s obsolete. Mixins and HOC - oh wait, bad idea, hooks to the rescue! At what point do people start to call BS and say you shouldn’t build around a framework that needs to be reinvented every year or two?
- sophiebits 8y ago
  (I worked on React.) Many people have adopted React and are happy with it, evidently because they believe the problems it creates are minor compared to the problems it fixes. It’s rather reasonable for them to be excited about a new version that keeps (or improves!) the good parts while having fewer tradeoffs.
  - jen729w 8y ago
    React is amazing. I'm teaching myself JS — started October '17 — and I've gone through a few iterations of my little project as I learn more. - Vanilla JS: it works, but holy moly it looks bad and the amount of code I have to write to do even basic stuff really really hurts my brain. (Actually what am I talking about, it never got close to "working" before I moved on to...) - jQuery/Node: ooh, this is better. But still, doing stuff takes ages. - React: OH MY GOD WHAT IS THIS HEAVEN. People will say that "people like me" shouldn't be writing web apps if we don't know what we're doing. To them I say, screw you. These tools enable us to do things that would never have been possible. Thank you from the bottom of my heart for doing whatever it is that you did. :-)
    - dnautics 8y ago
      I was initially resistant to a lot of react, for example, jsx. However as a backend dev (functional) I was very pleased when I could dive into react code and reliably implement features as needed.
  - ilovecaching 8y ago
    Thanks for all your great work sophiebits. React is perhaps the most important milestone in bringing functional concepts to the mainstream to date, and the project has been really well managed. It makes backend people like me actually enjoy writing JavaScript! Excited to see what you do next.
- hesarenu 8y ago
  That is just state management. The basic premise of reactjs has stayed the same.
- hombre_fatal 8y ago
  Without trying new things, you get stuck with, say, UIKit + CoreData which make me miss React every second I'm building an iOS app. All the KVO stuff that make it hard to actually reason about state changes. Of course React, like any library/framework, is going to have its own idiosyncrasies. That isn't the question. The question is if it's still better than alternatives, and people clearly seem to think so. My first React app I ever made years ago still works on the latest React, seems pretty stable as far as the web client ecosystem goes. Client development isn't trivial on any platform, btw. But I think we have it pretty damn good on the web, relatively.
  - pjmlp 8y ago
    We will only have it damn good on the web when it is as easy as doing RAD apps in Delphi, or using Blend to design UI layouts. I see a good possibility with WebComponents, which React seems to be the only framework not going for them.
    - crooked-v 8y ago
      To me, Web Components are bound by the fundamental anti-pattern of having to globally register unique tag names. Didn't people already learn the problems with doing this from Angular 1?
      - pjmlp 8y ago
        Because the best practice is to prefix them anyway, following up on XML namespaces?
        crooked-v 8y ago
        The contrast I mean to emphasize is React, where the tag you use is either an actual var declaration or a string placeholder for a browser (or other environment) built-in.
- emilsedgh 8y ago
  React resolved very big problems. These pattern changes are tiny improvements. Basically they are improving the syntax a bit.
- sutantog 8y ago
  no other framework lets you do so much by learning so little. React has the best learning curve to value ratio
- johnfn 8y ago
  This seems pretty disingenuous to me. React didn’t create the problem of class methods not binding this correctly. That’s purely a javascript problem, which react now provides a way to solve.
  - hombre_fatal 8y ago
    React's original createClass() even tried to solve that problem with autobound methods but they decided it wasn't worth it: https://reactjs.org/blog/2015/01/27/react-v0.13.0-beta-1.html#autobinding https://reactjs.org/blog/2015/01/27/react-v0.13.0-beta-1.htm...
- mpweiher 8y ago
  This is a question that’s been puzzling me for quite a while. For one, react is a fairly competently done, roughly MVC UI framework. The components are views, render() is drawRect. Being in the browser, render() doesn’t draw into a bitmap, but rather returns structured objects. That also means painting optimization is diff-based rather than damage-rect based. Which brings us to what appears to be the biggest difference: traditional MVC GUI toolkits such as Cocoa clearly separate creating a UI from updating the UI with data. For updating the UI from the model (and the model from the UI), you follow MVC, which specifies how the Views map the model to the display and vice versa. The actual views stay the same during that time, the data changes. React combines these two steps into one, conceptually recreating the entire UI at each step like a game. While this solves some issues that have crept into toolkit programming due to a shift towards handling dynamic aspects via changes in the view/widget hierarchy, it is conceptually rather muddled[1]. This conceptual muddle, claiming that the UI is a “pure” function of the state when it is clearly not, seems to the major source of those problems that keep needing to be solved. To me it would seem that looking dispassionately at the problems react solves without the conceptually troublesome baggage might be useful, but that’s just my € 0.02. [1] https://blog.metaobject.com/2018/12/uis-are-not-pure-functions-of-model.html https://blog.metaobject.com/2018/12/uis-are-not-pure-functio...
  - jasim 8y ago
    The linked post is a great comparison of functional and object-oriented approaches to building UIs. Thanks. I think the crux of the issue is here: > "So if we don't make the incorrect assumption that UIs are unstable (pure functions of model), then we don't have to expend additional and fragile effort to re-create that necessary stability." In Cocoa, and generally in desktop UIs, your assumption is true. A UI is a set of "slots" into which dynamic data is displayed. But on the web this is a lot more fluid. You can have visibility toggles across the application, and the UI can vary drastically between one state to another. I think this is the fundamental mismatch between the object-oriented approach to UI and the functional approach to UI. Also, in the "Lists" section, the functional approach would not be to create a persistent Map, which then has to be invalidated as its source data changes. Instead, the mental model in the functional approach is to always re-compute everything; memoization is an optimization that should be transparent.
- deleted 8y ago
  [deleted]
alangpierce 8y ago
Part of the point of solutions #1 and #3 is that they pass in exactly the same function on each render, so it's possible to avoid unnecessary rendering further down by knowing that the props are the same as before. The hooks solution will make a new handleChange closure each time, so it'll be a different function. Is there are way with hooks to pass the same function each time?
- sophiebits 8y ago
  useCallback is designed for this. useMemo also helps solve the problem from another angle that previously wasn’t as accessible. Additional reading: https://reactjs.org/docs/hooks-faq.html#are-hooks-slow-because-of-creating-functions-in-render https://reactjs.org/docs/hooks-faq.html#are-hooks-slow-becau....
- wereHamster 8y ago
  Perhaps the `setText` function remains always the same. I have not checked though.
ronilan 8y ago
> With React Hooks, I do not need to deal with the messy “this” coding pattern of class components. And there are no three ways to write this code. Yep. Now there are four. I have no specific opinion about React hooks (or about love for that matter), but “languages” with a simpler vocabulary do tend to have an advantage in the long run.
vmware505 8y ago
I actually like classes and using "this". Maybe I just like Object Oriented style. :)
- sophiebits 8y ago
  OO style definitely feels more familiar to many people. You may find Dan’s thread on this subject interesting though — he tries to explain why neither plain classes nor plain functions are the best fit for React: https://twitter.com/dan_abramov/status/1093694465917751298 https://twitter.com/dan_abramov/status/1093694465917751298.
  - hitekker 8y ago
    Truth be told, that twitter thread sounds more like a justification than an explanation.
    - danabramov 8y ago
      Does this sound more like an explanation? https://news.ycombinator.com/item?id=19206401 https://news.ycombinator.com/item?id=19206401 I’m happy to answer specific questions.
      - lugg 8y ago
        Sounds more like a bunch of excuses. Why do I, a framework user, need hooks? What problem do they solve for me? If you can't answer that without talking about what react broke first I don't think we we need whatever you're selling. Added responses there too. I feel like hooks are a solution to shit code that just needs a refactor. This happens a lot in frameworks that try to please everyone all the time. You give people of all experience levels the same feature set. It's no wonder at least half your user base goes out back and shoots themselves in the foot. If you want to fix this problem you need to remove flexibility. Not give them yet another method to hurt themselves. I'd start by splitting component concerns. MVC might be a good candidate. React.fragment components tend to smell like fat models. Pure functions basically views and connect code/prop/state mapping looks a lot like controllers. Fwiw this small UI component thing is originally what the MVC pattern was intended for. The big laravel style classes we have today are a misappropriation of the patterns name onto something that it shouldn't have.
Vanit 8y ago
Hooks seem great for simple usecases but I can't see how you'd not end up with a mess once you have 3+, and since most components inevitably gain complexity, why use hooks to start with?
- jrowley 8y ago
  They allow you to abstract certain kinds of logic in really convenient ways. If you haven’t seen usehooks.com check it out. Here is a compelling example of combining a few hooks together for an elegant solution: https://usehooks.com/useDarkMode/ https://usehooks.com/useDarkMode/
  - Vanit 8y ago
    I think hooks are just not for me because I don't think those examples look elegant.
    - thatswrong0 8y ago
      I think the `useDarkMode` example is awful. Disregard it. And probably disregard this as well since I most likely don't capture what makes hooks so nice from a development perspective: I'm currently rewriting my product's rich text editor in SlateJS and hooks and they're making customizing the editor much easier that was possible with class based components. SlateJS has a concept of plugins that you can pass to the base editor to customize behavior. For example, I can write my own "AutoCapitalize" plugin that will auto-capitalize the first word of each sentence. Or maybe a "Highlighter" plugin that highlights certain key phrases in the text. Some of these plugins need to read data from my store and/or call actions, and some don't. For the ones that do, I can instantiate the plugin with a hook (e.g. useHighlighterPlugin()), which nicely hides the fact that the plugin is hooked up to my data store / actions. Why is this useful? I have about 10 different text editors in the product, and each has a different set of plugins associated with each... I need to be able to mix and match them, reusing some the same plugins over and over. Maybe one editor has a list of plugins: [autoCapitalizePlugin, highlightPlugin, spellcheckPlugin] Another might have: [highlightPlugin, readOnlyPlugin]. Without hooks, to hook up these state and action dependent plugins, I would have to have higher order components wrapping each of these editors, each of these HoCs grabbing the different specific data / actions needed to make these plugins work properly, and passing this data explicitly to construct these plugins via props. Very difficult to reuse code this way. I suppose I could write an HoC for each plugin, but then suddenly I'm wrapping my component in 10 HoCs for 10 plugins. Plus there'd be possibility for props naming collision. It would have been impossible to both have reusability _and_ brevity without hooks. Instead, I can just create the plugins I want declaratively using hooks: const highlighterPlugin = useHighlighterPlugin(); const spellcheckPlugin = useSpellcheckPlugin();
deleted 8y ago
[deleted]
Matthias247 8y ago
Calling classes messy isn’t really a strong argument. classes are one of the valuable tools in a programmers toolbox. Emulating them via a bunch of closures that act on shared state isn’t necessarily better.
- dmitriid 8y ago
  Problem is, they are very messy in JS. They are a bad thin non-fitting abstraction over JS prototypes. People keep trying to fix them: https://github.com/andreypopp/autobind-decorator https://github.com/andreypopp/autobind-decorator
  - exogen 8y ago
    Not only that, but classes are at odds with advanced render scheduling like React is moving towards (concurrency, prioritized rendering, context switching, bailing out of renders, etc.). With a class instance, what happens if you need to bail out of a render and potentially restart it again later? The developer could have done literally anything to their class instance the first time through. They could be inheriting from anything and doing whatever they want to `this`. You can't easily "restart" it from its original state, unless you made a perfect snapshot, which is not easy with class instances – you'd need to perfectly deep clone the prototype chain and such. With functions and hooks on the other hand, there is no class instance or prototype chain to worry about. All state (whether stored via useRef or useState) is controlled by React – the actual object it gets stored on is hidden from the developer. If React wants to ditch the "instance" it was updating on the previous attempt and reuse the one it started with, it can do that without worry. It's the same reason "time travel" features are easier with more functional approaches. Adhering to functional programming ideas pays off in the long run.
- danabramov 8y ago
  Note we don’t agree classes are “messy”. That has nothing to do with motivation for Hooks. Longer comment: https://news.ycombinator.com/item?id=19206401 https://news.ycombinator.com/item?id=19206401
lioeters 8y ago
After reading numerous articles (starting with the docs), I'm still not convinced, and will not be using React Hooks any time soon. Some of the things I do not love: - Magic, in the unfavorable sense: if hooks were implemented in an indepedent library, just hearing that they "must be called in the same order every time" and "cannot be used inside conditional statements" should make anyone wary. - Scope creep: if anything, I wish React focused on reducing its size and API surface. - Entanglement: related to the point above, the goals of hooks would have been better served with a separate, tiny library that doesn't need to know anything about React, and usable anywhere else, with plain functions that can be tested or reused independently. Well, the topic deserves a deeper criticism than "it feels wrong", so I hope someone can write a worthy article called "Why I Do Not Love React Hooks", with an example of a better, alternative solution. I hesitate to bring up a cliché, but it's starting to feel like React is the new jQuery. I'm already trying to anticipate what comes after React, in which case I want my code to depend on the smallest possible API surface area. But then again, maybe it's my wishful thinking that we would move towards "universal components" (using dependency injection to pass in React or other view renderers like Web Components). Since much of the JS ecosystem seems to be going "all in" on React, perhaps I should surrender to its current. As long as I continue to use React, it looks like there's no escape from its hooks.. EDIT: I should add that the above is just my opinion at the moment, and I'm open to changing my mind. Who knows, I may unwillingly start using them (since everyone else seems to be), and come to love hooks after all.
- xrd 8y ago
  1. Isn't React sort-of magic to begin with? 2. Don't hooks remove the need for redux, etc.? Meaning, don't hooks radically reduce the amount of libraries you need to know about? 3. I prefer to use pure React and not have to choose between Redux, Flux, Mobx etc. And, then do I need to use redux-thunk, etc? I actually really like the progression towards hooks. I think the articles from the core team (like Dan Abramov) have been well written, explaining not just the how but the why, and it feels like hooks serve to make things simpler and more readable. Yes, you have to throw away a lot of things you spent time learning, but I'm not sad to see anything go away that hooks now handles.
  - 8y ago
_hardwaregeek 8y ago
While I do like the idea of more functional components, I don't think hooks are the answer. The reason I like more functional components is because I want to keep components small, stateless and dumb. Hooks encourage people to write more functional components, but I'm not sure that they'll encourage people to write functional components properly. Instead they'll just transfer the anti-patterns they're writing in class components to anti-patterns in functional components. For instance, I could see people writing large functional components with big globs of state and side effects. The real issue which I want to see solved is getting people to remove business logic from React. I see components loaded to the gills with data fetching and overly complicated async rendering schemes. Personally I try to keep my React components extremely dumb. Instead I try to keep most of the business logic on the server side when possible, and in Redux otherwise. But even that's not great. Redux is fundamentally a data store, not a business logic library. Trying to do complicated logic with selectors/actions is a nightmare. I suppose that's why front end frameworks like Angular and Ember are popular. React ultimately is a view library and yet it provides no good option for the business logic.
- underwater 8y ago
  Fighting advancements because they could be misused is a battle you cannot win. If your team is going to misuse features because they simply exist then you need to address the root cause — your team — not the library.
- Swizec 8y ago
  > The real issue which I want to see solved is getting people to remove business logic from React. I see components loaded to the gills with data fetching and overly complicated async rendering schemes. Personally I try to keep my React components extremely dumb. Hooks are great for this. You extract all business logic into custom hooks and your components are left as dumb renderers calling other functions to get values. It’s great.
kristiandupont 8y ago
Contrary to some commenters here, I think React is just about the best thing that has happened to UI programming in recent memory. Everything I tried before it (jQuery, Backbone, Knockout, Angular, Meteor (with Handlebars)) felt like it fell short or, in the case of the databinding-oriented ones, like a broken abstraction. I get a similar feeling when looking at Vue though I have no experience so I might be wrong. I too am a bit skeptical about hooks making what looks like pure functions act like stateful ones. I am not using hooks yet but besides from Dan Abramovs excellent articles about their rationale, I think I will look at them like a new paradigm, only using a syntax that we know from something else. In fact, I wouldn't be surprised if I some time in the future will be using React to write state machines for something that doesn't have anything to do with UI, where "rendering" composes state related to something else entirely. I could see hooks being a game changer here.
- baddox 8y ago
  > I too am a bit skeptical about hooks making what looks like pure functions act like stateful ones. What’s wrong with that? Any conceivable application needs to actually have state that changes over time. That’s true of all software written in a purely functional style.
  - Silhouette 8y ago
    That’s true of all software written in a purely functional style. By definition, any software that is purely functional does not have explicit mutable state. In practice, it is often useful to have parts of a system written in a pure functional style but other parts that do use mutable state, either explicitly or via some mechanism that simulates it in a functional context.
- shubhamjain 8y ago
  One reason I love Vue over React is how beginner friendly it is. You can't make a "Hello World" app in React without getting bombarded with concepts and terms—states, props, JSX, stateful components. Just look that the "Getting Started" example of Vue [1] and compare it React's [2]. You don't need anything more than a notepad to get the first example running. Progressing down Vue, you realize how they have tried to prioritize convenience. For example, using "v-on:keyup.enter" you can map an action to "Enter" key without writing code for handling that key. I liked the React's approach but it seems its focus is on purity of abstractions than convenience. Don't even get me started on Redux which is epitome of needless complexity—containers, reducers, event emitters? Was all that really needed? Note: I have no idea how Vue fares when code base is huge, but my intial impression makes me feel it's far better choice than React. [1]: https://vuejs.org/v2/guide/#Declarative-Rendering https://vuejs.org/v2/guide/#Declarative-Rendering [2]: https://reactjs.org/tutorial/tutorial.html https://reactjs.org/tutorial/tutorial.html
Bahamut 8y ago
Devs beware, hooks are not quite there yet it turns out. You get warnings in jest about needing to use act from react-test-renderer if you use async code to trigger state updates - the solution being recommended currently is mock every promise with a synchronous version, which then litters your app code with conditionals in many places for whether to use the mock or real promises. At that point, you're much better off using Angular for writing decent component/unit tests, where you don't have to fight with any async DOM or JS api in order to write working tests, or pollute app code with test specific branching logic since that is all handled at a single injection point via the IoC container. If you have promises, you're forced to bleed a isMounted type of flag into the cleanup function scope in order to guard against promises attempting to trigger state changes after the promise is complete with its async function (i.e. data fetching). These are two frustratingly painful dev ergnomoics situations that are unsolved with hooks. Otherwise, I am happy with them, but these are major pain points I have encountered with them so far, and given FB doesn't use promises in their internal apps for the most part, I don't see them likely to put in much work solving these problems unfortunately. Disclaimer: I would love to put in some effort to solve these pain points with design discussions & code, but unfortunately I cannot put in that work without going through approval processes with 5+ people.
- danabramov 8y ago
  >given FB doesn't use promises in their internal apps for the most part, I don't see them likely to put in much work solving these problems unfortunately. This is inaccurate. The first problem has an issue tracking it (https://github.com/facebook/react/issues/14769 https://github.com/facebook/react/issues/14769) and even a pull request (https://github.com/facebook/react/pull/14853 https://github.com/facebook/react/pull/14853). It’s barely been two weeks since the first release and we’ve been focusing on fixing actual bugs as soon as possible. As I hope you can understand, warnings in tests are a bit less critical and can wait behind production bugs. But we’ll get back to fixing the warnings as soon as possible — maybe even this week. As for isMounted-like flag. This has nothing to do with Hooks. Classes need exactly the same thing. If you forget it, you’ll likely have both the same kind of warning, and possible race conditions from requests arriving out of order. In longer term we’ll offer a much simpler data fetching integration (read about Suspense) which doesn’t involve effects or lifecycles at all. I think you’ll like it.
littlecranky67 8y ago
Hooks are a big deal if you use TypeScript with React. Explicitly typing the state is gone (it will be inferred by what you pass as initial value to useState()). So is weird Partial<TState> typings when setting the initial class state in the constructor or via this.setState(). And if you ever had to deal with correctly typing HOCs or render props you had to dig very deep into conditional/mapped types in TS. With hooks this is basically gone.
- machiaweliczny 8y ago
  With classes you also don't have type state when using 'state = { ... }'. I think hooks might be nice for data fetching when it comes to TS as it will super easy to get typing. I'm still not convinced by hooks though.
  - littlecranky67 8y ago
    Yes you do, you have to give the type of the state in the 'extends' clause: 'class MyComponent extends React.Component<TProps, TState> { ... }'. If you omit TState, an empty object {} is assumed for state. And you have to specify the type when updating the state via .setState(), because setState() auto-patches/merges the state. So its fine to pass a Partial<TState> to setState. With Hooks, the auto-patching goes away, so your call to setMyCustomState() always requires an argument of type TState. There are similar issues if you use the 'static defaultProps = { ... }' on a class - you have to manually specify the type of defaultProps - often it is Partial<TProps>
_robbywashere 8y ago
Call me crazy... but how neat would it be if browsers had native JSX and React support - and even some optimizations for it/them?
_pdp_ 8y ago
As a developer of a extremely large code-base written in Rect (https://launchpad.secapps.com https://launchpad.secapps.com for reference of the kind of apps we are talking about), I am not convinced that "Hooks" solves anything in particular that it is not already solved through decorators. We use decorators quite extensively, from assigning styles in a way that does not force the component to re-render due to props changes, to controlling the props themselves with onChange events and so on. In my professional opinion, which is based on years spending time with react, the typical gotchas in this framework are down to experience. Experienced react, and more importantly js, developers will write better, more performant code. This is applicable across the board regardless of the framework/language. Hooks will not particularly remove this need nor will make you a better programmer. While hooks look functionally ok what worries me is that they will be subject to a number of problems. For example, complex hooks/components might be subject to memory leaks. With hooks, we are defining closures inside the functional component which will be subject to having access to proceeding scopes. This is an anti-pattern that we removed from our code-base by using classes. The second problem is that your component will needlessly re-render in those cases where the component is not entirely functional. This may not seem like a problem in the simple examples seen thus far, but it will be with more complex components as I've seen in my experience. React is one of the best frameworks we have seen around so I am happy that we keep pushing the boundaries but what worries is me is that the React team seems to declare that they are moving towards components written with hooks (not removing classes) which in my opinion is not based on solid evidence that will amount to anything useful in particular. Again, as far as I am concerned, hooks does not contribute to anything that we are not solving in much better way and I doubt they will ever be used at all as far as our code-based is concerned.
- kilburn 8y ago
  While I don't disagree with you generally, this part > The second problem is that your component will needlessly re-render in those cases where the component is not entirely functional. is addressed by the react developers in the FAQ [1]. The answer wasn't obvious to me, so I made a toy example in CodeSandbox [2]. There are 3 counters that can be updated using 3 corresponding buttons. Each counter uses a different approach: 1. The "handler" counter uses "useState" + "inner function in the parent's body". The corresponding button rerenders every time the parent rerenders (i.e.: the problem you are highlighting) 2. The "callback" counter uses "useState" + "useCallback" to memoize over the counter's value. The button rerenders only when it is clicked (and hence the counter it controls is updated). 3. The "reducer" counter uses a react context to inject a "dispatch" function that calls an out-of-parent reducer. The button never rerenders. The docs are clearly pushing the reader towards this solution (albeit it is contrived for very simple examples such as this one, I can see the benefits surpassing the boilerplate overhead of reducers in more complex situations). [1] https://reactjs.org/docs/hooks-faq.html#are-hooks-slow-because-of-creating-functions-in-render https://reactjs.org/docs/hooks-faq.html#are-hooks-slow-becau... [2] https://codesandbox.io/s/r584lz2pom https://codesandbox.io/s/r584lz2pom
Azeralthefallen 8y ago
Honestly i struggle when people argue that 'this' and class components are complicated, and that hooks remove that complexity. Yet then i see people composing together dozens of various hooks and HoC's to achieve the same balance is beyond confusing. Recently i was assigned a PR for a component (a login form) i wrote about a two years ago which was a whole 300 lines. The person who wrote the PR also took the time to make it "functional", which has now resulted in it being split into almost a dozen different files. I don't find this cleaner or easier to understand at all. Current team i am on uses MobX, and Typescript for our app and frankly it is painfully simple, and yet people keep arguing that we should drop mobx, and switch to hooks and i don't see any benefit.
- d357r0y3r 8y ago
  mobx-react-lite (supported by the main mobx team) uses hooks under the hood, but extends mobx-react behavior to SFCs. I don't think it creates any additional boilerplate and it aligns with the direction React is going.
  - Azeralthefallen 8y ago
    Unfortunately to me examples like this looks like you are trying to fit a square peg into a round hole and are twisting something to fit reacts new functional direction.: https://github.com/mobxjs/mobx-react-lite#useobservabletinitialvalue-t-t https://github.com/mobxjs/mobx-react-lite#useobservabletinit...
- underwater 8y ago
  Are you using Storybook or a similar system? I've got a lot of value in defining my application in decoupled components when I can verify the implementation of each part in isolation.
  - Azeralthefallen 8y ago
    We write tests to verify if things are working correctly using Cypress + Mocha. We have simple unit tests for validating basic functionality and extensive integration tests. We typically have a set of tests per feature. The problem i have noticed is that people say "well it works in isolation", but on integration with other components it doesn't work properly. Unfortunately this is a huge problem i find, and frankly the idea of numerous shared hooks and ensuring they are side affect free is very painful.
fastbmk 8y ago
TL;DR People who wish that progress would stop on jQuery & Rails - won't like React Hooks either.
coldtea 8y ago
>This coding pattern also requires more babel transforms. Not a big problem but something that developers should be aware of. This sounds like a totally BS reason in the context where it is said.
deleted 8y ago
[deleted]
tekkk 8y ago
So can someone explain what the author means by the problem of #3: >However, there are times when we need to pass an extra parameter. In those cases, we cannot use bind because we cannot use bind with arrow functions. But you can pass the extra argument to the arrow function directly: `onChange={handleChange('name')}`. And use it as: handleChange = (field) => (e) => { this.setState({ [field]: e.target.value }); } Sure it still has the problems of arrow functions I think the arguments against it were worded poorly.

104 points by vijayst 8y ago

How is it that React gets celebrated for “solving” problems that React created in the first place? The entire paradigm of React keeps changing as each pervious iteration proves to be “messy” or “over complicated.” createClass? Nah that’s obsolete. Mixins and HOC - oh wait, bad idea, hooks to the rescue! At what point do people start to call BS and say you shouldn’t build around a framework that needs to be reinvented every year or two?

sophiebits 8y ago
(I worked on React.) Many people have adopted React and are happy with it, evidently because they believe the problems it creates are minor compared to the problems it fixes. It’s rather reasonable for them to be excited about a new version that keeps (or improves!) the good parts while having fewer tradeoffs.
- jen729w 8y ago
  React is amazing. I'm teaching myself JS — started October '17 — and I've gone through a few iterations of my little project as I learn more. - Vanilla JS: it works, but holy moly it looks bad and the amount of code I have to write to do even basic stuff really really hurts my brain. (Actually what am I talking about, it never got close to "working" before I moved on to...) - jQuery/Node: ooh, this is better. But still, doing stuff takes ages. - React: OH MY GOD WHAT IS THIS HEAVEN. People will say that "people like me" shouldn't be writing web apps if we don't know what we're doing. To them I say, screw you. These tools enable us to do things that would never have been possible. Thank you from the bottom of my heart for doing whatever it is that you did. :-)
  - dnautics 8y ago
    I was initially resistant to a lot of react, for example, jsx. However as a backend dev (functional) I was very pleased when I could dive into react code and reliably implement features as needed.
- ilovecaching 8y ago
  Thanks for all your great work sophiebits. React is perhaps the most important milestone in bringing functional concepts to the mainstream to date, and the project has been really well managed. It makes backend people like me actually enjoy writing JavaScript! Excited to see what you do next.
hesarenu 8y ago
That is just state management. The basic premise of reactjs has stayed the same.
hombre_fatal 8y ago
Without trying new things, you get stuck with, say, UIKit + CoreData which make me miss React every second I'm building an iOS app. All the KVO stuff that make it hard to actually reason about state changes. Of course React, like any library/framework, is going to have its own idiosyncrasies. That isn't the question. The question is if it's still better than alternatives, and people clearly seem to think so. My first React app I ever made years ago still works on the latest React, seems pretty stable as far as the web client ecosystem goes. Client development isn't trivial on any platform, btw. But I think we have it pretty damn good on the web, relatively.
- pjmlp 8y ago
  We will only have it damn good on the web when it is as easy as doing RAD apps in Delphi, or using Blend to design UI layouts. I see a good possibility with WebComponents, which React seems to be the only framework not going for them.
  - crooked-v 8y ago
    To me, Web Components are bound by the fundamental anti-pattern of having to globally register unique tag names. Didn't people already learn the problems with doing this from Angular 1?
    - pjmlp 8y ago
      Because the best practice is to prefix them anyway, following up on XML namespaces?
      - crooked-v 8y ago
        The contrast I mean to emphasize is React, where the tag you use is either an actual var declaration or a string placeholder for a browser (or other environment) built-in.
emilsedgh 8y ago
React resolved very big problems. These pattern changes are tiny improvements. Basically they are improving the syntax a bit.
sutantog 8y ago
no other framework lets you do so much by learning so little. React has the best learning curve to value ratio
johnfn 8y ago
This seems pretty disingenuous to me. React didn’t create the problem of class methods not binding this correctly. That’s purely a javascript problem, which react now provides a way to solve.
- hombre_fatal 8y ago
  React's original createClass() even tried to solve that problem with autobound methods but they decided it wasn't worth it: https://reactjs.org/blog/2015/01/27/react-v0.13.0-beta-1.html#autobinding https://reactjs.org/blog/2015/01/27/react-v0.13.0-beta-1.htm...
mpweiher 8y ago
This is a question that’s been puzzling me for quite a while. For one, react is a fairly competently done, roughly MVC UI framework. The components are views, render() is drawRect. Being in the browser, render() doesn’t draw into a bitmap, but rather returns structured objects. That also means painting optimization is diff-based rather than damage-rect based. Which brings us to what appears to be the biggest difference: traditional MVC GUI toolkits such as Cocoa clearly separate creating a UI from updating the UI with data. For updating the UI from the model (and the model from the UI), you follow MVC, which specifies how the Views map the model to the display and vice versa. The actual views stay the same during that time, the data changes. React combines these two steps into one, conceptually recreating the entire UI at each step like a game. While this solves some issues that have crept into toolkit programming due to a shift towards handling dynamic aspects via changes in the view/widget hierarchy, it is conceptually rather muddled[1]. This conceptual muddle, claiming that the UI is a “pure” function of the state when it is clearly not, seems to the major source of those problems that keep needing to be solved. To me it would seem that looking dispassionately at the problems react solves without the conceptually troublesome baggage might be useful, but that’s just my € 0.02. [1] https://blog.metaobject.com/2018/12/uis-are-not-pure-functions-of-model.html https://blog.metaobject.com/2018/12/uis-are-not-pure-functio...
- jasim 8y ago
  The linked post is a great comparison of functional and object-oriented approaches to building UIs. Thanks. I think the crux of the issue is here: > "So if we don't make the incorrect assumption that UIs are unstable (pure functions of model), then we don't have to expend additional and fragile effort to re-create that necessary stability." In Cocoa, and generally in desktop UIs, your assumption is true. A UI is a set of "slots" into which dynamic data is displayed. But on the web this is a lot more fluid. You can have visibility toggles across the application, and the UI can vary drastically between one state to another. I think this is the fundamental mismatch between the object-oriented approach to UI and the functional approach to UI. Also, in the "Lists" section, the functional approach would not be to create a persistent Map, which then has to be invalidated as its source data changes. Instead, the mental model in the functional approach is to always re-compute everything; memoization is an optimization that should be transparent.
deleted 8y ago
[deleted]

alangpierce 8y ago

Part of the point of solutions #1 and #3 is that they pass in exactly the same function on each render, so it's possible to avoid unnecessary rendering further down by knowing that the props are the same as before. The hooks solution will make a new handleChange closure each time, so it'll be a different function. Is there are way with hooks to pass the same function each time?

sophiebits 8y ago
useCallback is designed for this. useMemo also helps solve the problem from another angle that previously wasn’t as accessible. Additional reading: https://reactjs.org/docs/hooks-faq.html#are-hooks-slow-because-of-creating-functions-in-render https://reactjs.org/docs/hooks-faq.html#are-hooks-slow-becau....
wereHamster 8y ago
Perhaps the `setText` function remains always the same. I have not checked though.

ronilan 8y ago

> With React Hooks, I do not need to deal with the messy “this” coding pattern of class components. And there are no three ways to write this code. Yep. Now there are four. I have no specific opinion about React hooks (or about love for that matter), but “languages” with a simpler vocabulary do tend to have an advantage in the long run.

vmware505 8y ago

I actually like classes and using "this". Maybe I just like Object Oriented style. :)

sophiebits 8y ago
OO style definitely feels more familiar to many people. You may find Dan’s thread on this subject interesting though — he tries to explain why neither plain classes nor plain functions are the best fit for React: https://twitter.com/dan_abramov/status/1093694465917751298 https://twitter.com/dan_abramov/status/1093694465917751298.
- hitekker 8y ago
  Truth be told, that twitter thread sounds more like a justification than an explanation.
  - danabramov 8y ago
    Does this sound more like an explanation? https://news.ycombinator.com/item?id=19206401 https://news.ycombinator.com/item?id=19206401 I’m happy to answer specific questions.
    - lugg 8y ago
      Sounds more like a bunch of excuses. Why do I, a framework user, need hooks? What problem do they solve for me? If you can't answer that without talking about what react broke first I don't think we we need whatever you're selling. Added responses there too. I feel like hooks are a solution to shit code that just needs a refactor. This happens a lot in frameworks that try to please everyone all the time. You give people of all experience levels the same feature set. It's no wonder at least half your user base goes out back and shoots themselves in the foot. If you want to fix this problem you need to remove flexibility. Not give them yet another method to hurt themselves. I'd start by splitting component concerns. MVC might be a good candidate. React.fragment components tend to smell like fat models. Pure functions basically views and connect code/prop/state mapping looks a lot like controllers. Fwiw this small UI component thing is originally what the MVC pattern was intended for. The big laravel style classes we have today are a misappropriation of the patterns name onto something that it shouldn't have.

Vanit 8y ago

Hooks seem great for simple usecases but I can't see how you'd not end up with a mess once you have 3+, and since most components inevitably gain complexity, why use hooks to start with?

jrowley 8y ago
They allow you to abstract certain kinds of logic in really convenient ways. If you haven’t seen usehooks.com check it out. Here is a compelling example of combining a few hooks together for an elegant solution: https://usehooks.com/useDarkMode/ https://usehooks.com/useDarkMode/
- Vanit 8y ago
  I think hooks are just not for me because I don't think those examples look elegant.
  - thatswrong0 8y ago
    I think the `useDarkMode` example is awful. Disregard it. And probably disregard this as well since I most likely don't capture what makes hooks so nice from a development perspective: I'm currently rewriting my product's rich text editor in SlateJS and hooks and they're making customizing the editor much easier that was possible with class based components. SlateJS has a concept of plugins that you can pass to the base editor to customize behavior. For example, I can write my own "AutoCapitalize" plugin that will auto-capitalize the first word of each sentence. Or maybe a "Highlighter" plugin that highlights certain key phrases in the text. Some of these plugins need to read data from my store and/or call actions, and some don't. For the ones that do, I can instantiate the plugin with a hook (e.g. useHighlighterPlugin()), which nicely hides the fact that the plugin is hooked up to my data store / actions. Why is this useful? I have about 10 different text editors in the product, and each has a different set of plugins associated with each... I need to be able to mix and match them, reusing some the same plugins over and over. Maybe one editor has a list of plugins: [autoCapitalizePlugin, highlightPlugin, spellcheckPlugin] Another might have: [highlightPlugin, readOnlyPlugin]. Without hooks, to hook up these state and action dependent plugins, I would have to have higher order components wrapping each of these editors, each of these HoCs grabbing the different specific data / actions needed to make these plugins work properly, and passing this data explicitly to construct these plugins via props. Very difficult to reuse code this way. I suppose I could write an HoC for each plugin, but then suddenly I'm wrapping my component in 10 HoCs for 10 plugins. Plus there'd be possibility for props naming collision. It would have been impossible to both have reusability _and_ brevity without hooks. Instead, I can just create the plugins I want declaratively using hooks: const highlighterPlugin = useHighlighterPlugin(); const spellcheckPlugin = useSpellcheckPlugin();

deleted 8y ago

[deleted]

Matthias247 8y ago

Calling classes messy isn’t really a strong argument. classes are one of the valuable tools in a programmers toolbox. Emulating them via a bunch of closures that act on shared state isn’t necessarily better.

dmitriid 8y ago
Problem is, they are very messy in JS. They are a bad thin non-fitting abstraction over JS prototypes. People keep trying to fix them: https://github.com/andreypopp/autobind-decorator https://github.com/andreypopp/autobind-decorator
- exogen 8y ago
  Not only that, but classes are at odds with advanced render scheduling like React is moving towards (concurrency, prioritized rendering, context switching, bailing out of renders, etc.). With a class instance, what happens if you need to bail out of a render and potentially restart it again later? The developer could have done literally anything to their class instance the first time through. They could be inheriting from anything and doing whatever they want to `this`. You can't easily "restart" it from its original state, unless you made a perfect snapshot, which is not easy with class instances – you'd need to perfectly deep clone the prototype chain and such. With functions and hooks on the other hand, there is no class instance or prototype chain to worry about. All state (whether stored via useRef or useState) is controlled by React – the actual object it gets stored on is hidden from the developer. If React wants to ditch the "instance" it was updating on the previous attempt and reuse the one it started with, it can do that without worry. It's the same reason "time travel" features are easier with more functional approaches. Adhering to functional programming ideas pays off in the long run.
danabramov 8y ago
Note we don’t agree classes are “messy”. That has nothing to do with motivation for Hooks. Longer comment: https://news.ycombinator.com/item?id=19206401 https://news.ycombinator.com/item?id=19206401

lioeters 8y ago

After reading numerous articles (starting with the docs), I'm still not convinced, and will not be using React Hooks any time soon. Some of the things I do not love: - Magic, in the unfavorable sense: if hooks were implemented in an indepedent library, just hearing that they "must be called in the same order every time" and "cannot be used inside conditional statements" should make anyone wary. - Scope creep: if anything, I wish React focused on reducing its size and API surface. - Entanglement: related to the point above, the goals of hooks would have been better served with a separate, tiny library that doesn't need to know anything about React, and usable anywhere else, with plain functions that can be tested or reused independently. Well, the topic deserves a deeper criticism than "it feels wrong", so I hope someone can write a worthy article called "Why I Do Not Love React Hooks", with an example of a better, alternative solution. I hesitate to bring up a cliché, but it's starting to feel like React is the new jQuery. I'm already trying to anticipate what comes after React, in which case I want my code to depend on the smallest possible API surface area. But then again, maybe it's my wishful thinking that we would move towards "universal components" (using dependency injection to pass in React or other view renderers like Web Components). Since much of the JS ecosystem seems to be going "all in" on React, perhaps I should surrender to its current. As long as I continue to use React, it looks like there's no escape from its hooks.. EDIT: I should add that the above is just my opinion at the moment, and I'm open to changing my mind. Who knows, I may unwillingly start using them (since everyone else seems to be), and come to love hooks after all.

xrd 8y ago
1. Isn't React sort-of magic to begin with? 2. Don't hooks remove the need for redux, etc.? Meaning, don't hooks radically reduce the amount of libraries you need to know about? 3. I prefer to use pure React and not have to choose between Redux, Flux, Mobx etc. And, then do I need to use redux-thunk, etc? I actually really like the progression towards hooks. I think the articles from the core team (like Dan Abramov) have been well written, explaining not just the how but the why, and it feels like hooks serve to make things simpler and more readable. Yes, you have to throw away a lot of things you spent time learning, but I'm not sad to see anything go away that hooks now handles.
- 8y ago

_hardwaregeek 8y ago

While I do like the idea of more functional components, I don't think hooks are the answer. The reason I like more functional components is because I want to keep components small, stateless and dumb. Hooks encourage people to write more functional components, but I'm not sure that they'll encourage people to write functional components properly. Instead they'll just transfer the anti-patterns they're writing in class components to anti-patterns in functional components. For instance, I could see people writing large functional components with big globs of state and side effects. The real issue which I want to see solved is getting people to remove business logic from React. I see components loaded to the gills with data fetching and overly complicated async rendering schemes. Personally I try to keep my React components extremely dumb. Instead I try to keep most of the business logic on the server side when possible, and in Redux otherwise. But even that's not great. Redux is fundamentally a data store, not a business logic library. Trying to do complicated logic with selectors/actions is a nightmare. I suppose that's why front end frameworks like Angular and Ember are popular. React ultimately is a view library and yet it provides no good option for the business logic.

underwater 8y ago
Fighting advancements because they could be misused is a battle you cannot win. If your team is going to misuse features because they simply exist then you need to address the root cause — your team — not the library.
Swizec 8y ago
> The real issue which I want to see solved is getting people to remove business logic from React. I see components loaded to the gills with data fetching and overly complicated async rendering schemes. Personally I try to keep my React components extremely dumb. Hooks are great for this. You extract all business logic into custom hooks and your components are left as dumb renderers calling other functions to get values. It’s great.

kristiandupont 8y ago

Contrary to some commenters here, I think React is just about the best thing that has happened to UI programming in recent memory. Everything I tried before it (jQuery, Backbone, Knockout, Angular, Meteor (with Handlebars)) felt like it fell short or, in the case of the databinding-oriented ones, like a broken abstraction. I get a similar feeling when looking at Vue though I have no experience so I might be wrong. I too am a bit skeptical about hooks making what looks like pure functions act like stateful ones. I am not using hooks yet but besides from Dan Abramovs excellent articles about their rationale, I think I will look at them like a new paradigm, only using a syntax that we know from something else. In fact, I wouldn't be surprised if I some time in the future will be using React to write state machines for something that doesn't have anything to do with UI, where "rendering" composes state related to something else entirely. I could see hooks being a game changer here.

baddox 8y ago
> I too am a bit skeptical about hooks making what looks like pure functions act like stateful ones. What’s wrong with that? Any conceivable application needs to actually have state that changes over time. That’s true of all software written in a purely functional style.
- Silhouette 8y ago
  That’s true of all software written in a purely functional style. By definition, any software that is purely functional does not have explicit mutable state. In practice, it is often useful to have parts of a system written in a pure functional style but other parts that do use mutable state, either explicitly or via some mechanism that simulates it in a functional context.
shubhamjain 8y ago
One reason I love Vue over React is how beginner friendly it is. You can't make a "Hello World" app in React without getting bombarded with concepts and terms—states, props, JSX, stateful components. Just look that the "Getting Started" example of Vue [1] and compare it React's [2]. You don't need anything more than a notepad to get the first example running. Progressing down Vue, you realize how they have tried to prioritize convenience. For example, using "v-on:keyup.enter" you can map an action to "Enter" key without writing code for handling that key. I liked the React's approach but it seems its focus is on purity of abstractions than convenience. Don't even get me started on Redux which is epitome of needless complexity—containers, reducers, event emitters? Was all that really needed? Note: I have no idea how Vue fares when code base is huge, but my intial impression makes me feel it's far better choice than React. [1]: https://vuejs.org/v2/guide/#Declarative-Rendering https://vuejs.org/v2/guide/#Declarative-Rendering [2]: https://reactjs.org/tutorial/tutorial.html https://reactjs.org/tutorial/tutorial.html

Bahamut 8y ago

Devs beware, hooks are not quite there yet it turns out. You get warnings in jest about needing to use act from react-test-renderer if you use async code to trigger state updates - the solution being recommended currently is mock every promise with a synchronous version, which then litters your app code with conditionals in many places for whether to use the mock or real promises. At that point, you're much better off using Angular for writing decent component/unit tests, where you don't have to fight with any async DOM or JS api in order to write working tests, or pollute app code with test specific branching logic since that is all handled at a single injection point via the IoC container. If you have promises, you're forced to bleed a isMounted type of flag into the cleanup function scope in order to guard against promises attempting to trigger state changes after the promise is complete with its async function (i.e. data fetching). These are two frustratingly painful dev ergnomoics situations that are unsolved with hooks. Otherwise, I am happy with them, but these are major pain points I have encountered with them so far, and given FB doesn't use promises in their internal apps for the most part, I don't see them likely to put in much work solving these problems unfortunately. Disclaimer: I would love to put in some effort to solve these pain points with design discussions & code, but unfortunately I cannot put in that work without going through approval processes with 5+ people.

danabramov 8y ago
>given FB doesn't use promises in their internal apps for the most part, I don't see them likely to put in much work solving these problems unfortunately. This is inaccurate. The first problem has an issue tracking it (https://github.com/facebook/react/issues/14769 https://github.com/facebook/react/issues/14769) and even a pull request (https://github.com/facebook/react/pull/14853 https://github.com/facebook/react/pull/14853). It’s barely been two weeks since the first release and we’ve been focusing on fixing actual bugs as soon as possible. As I hope you can understand, warnings in tests are a bit less critical and can wait behind production bugs. But we’ll get back to fixing the warnings as soon as possible — maybe even this week. As for isMounted-like flag. This has nothing to do with Hooks. Classes need exactly the same thing. If you forget it, you’ll likely have both the same kind of warning, and possible race conditions from requests arriving out of order. In longer term we’ll offer a much simpler data fetching integration (read about Suspense) which doesn’t involve effects or lifecycles at all. I think you’ll like it.

littlecranky67 8y ago

Hooks are a big deal if you use TypeScript with React. Explicitly typing the state is gone (it will be inferred by what you pass as initial value to useState()). So is weird Partial<TState> typings when setting the initial class state in the constructor or via this.setState(). And if you ever had to deal with correctly typing HOCs or render props you had to dig very deep into conditional/mapped types in TS. With hooks this is basically gone.

machiaweliczny 8y ago
With classes you also don't have type state when using 'state = { ... }'. I think hooks might be nice for data fetching when it comes to TS as it will super easy to get typing. I'm still not convinced by hooks though.
- littlecranky67 8y ago
  Yes you do, you have to give the type of the state in the 'extends' clause: 'class MyComponent extends React.Component<TProps, TState> { ... }'. If you omit TState, an empty object {} is assumed for state. And you have to specify the type when updating the state via .setState(), because setState() auto-patches/merges the state. So its fine to pass a Partial<TState> to setState. With Hooks, the auto-patching goes away, so your call to setMyCustomState() always requires an argument of type TState. There are similar issues if you use the 'static defaultProps = { ... }' on a class - you have to manually specify the type of defaultProps - often it is Partial<TProps>

_robbywashere 8y ago

Call me crazy... but how neat would it be if browsers had native JSX and React support - and even some optimizations for it/them?

_pdp_ 8y ago

As a developer of a extremely large code-base written in Rect (https://launchpad.secapps.com https://launchpad.secapps.com for reference of the kind of apps we are talking about), I am not convinced that "Hooks" solves anything in particular that it is not already solved through decorators. We use decorators quite extensively, from assigning styles in a way that does not force the component to re-render due to props changes, to controlling the props themselves with onChange events and so on. In my professional opinion, which is based on years spending time with react, the typical gotchas in this framework are down to experience. Experienced react, and more importantly js, developers will write better, more performant code. This is applicable across the board regardless of the framework/language. Hooks will not particularly remove this need nor will make you a better programmer. While hooks look functionally ok what worries me is that they will be subject to a number of problems. For example, complex hooks/components might be subject to memory leaks. With hooks, we are defining closures inside the functional component which will be subject to having access to proceeding scopes. This is an anti-pattern that we removed from our code-base by using classes. The second problem is that your component will needlessly re-render in those cases where the component is not entirely functional. This may not seem like a problem in the simple examples seen thus far, but it will be with more complex components as I've seen in my experience. React is one of the best frameworks we have seen around so I am happy that we keep pushing the boundaries but what worries is me is that the React team seems to declare that they are moving towards components written with hooks (not removing classes) which in my opinion is not based on solid evidence that will amount to anything useful in particular. Again, as far as I am concerned, hooks does not contribute to anything that we are not solving in much better way and I doubt they will ever be used at all as far as our code-based is concerned.

kilburn 8y ago
While I don't disagree with you generally, this part > The second problem is that your component will needlessly re-render in those cases where the component is not entirely functional. is addressed by the react developers in the FAQ [1]. The answer wasn't obvious to me, so I made a toy example in CodeSandbox [2]. There are 3 counters that can be updated using 3 corresponding buttons. Each counter uses a different approach: 1. The "handler" counter uses "useState" + "inner function in the parent's body". The corresponding button rerenders every time the parent rerenders (i.e.: the problem you are highlighting) 2. The "callback" counter uses "useState" + "useCallback" to memoize over the counter's value. The button rerenders only when it is clicked (and hence the counter it controls is updated). 3. The "reducer" counter uses a react context to inject a "dispatch" function that calls an out-of-parent reducer. The button never rerenders. The docs are clearly pushing the reader towards this solution (albeit it is contrived for very simple examples such as this one, I can see the benefits surpassing the boilerplate overhead of reducers in more complex situations). [1] https://reactjs.org/docs/hooks-faq.html#are-hooks-slow-because-of-creating-functions-in-render https://reactjs.org/docs/hooks-faq.html#are-hooks-slow-becau... [2] https://codesandbox.io/s/r584lz2pom https://codesandbox.io/s/r584lz2pom

Azeralthefallen 8y ago

Honestly i struggle when people argue that 'this' and class components are complicated, and that hooks remove that complexity. Yet then i see people composing together dozens of various hooks and HoC's to achieve the same balance is beyond confusing. Recently i was assigned a PR for a component (a login form) i wrote about a two years ago which was a whole 300 lines. The person who wrote the PR also took the time to make it "functional", which has now resulted in it being split into almost a dozen different files. I don't find this cleaner or easier to understand at all. Current team i am on uses MobX, and Typescript for our app and frankly it is painfully simple, and yet people keep arguing that we should drop mobx, and switch to hooks and i don't see any benefit.

d357r0y3r 8y ago
mobx-react-lite (supported by the main mobx team) uses hooks under the hood, but extends mobx-react behavior to SFCs. I don't think it creates any additional boilerplate and it aligns with the direction React is going.
- Azeralthefallen 8y ago
  Unfortunately to me examples like this looks like you are trying to fit a square peg into a round hole and are twisting something to fit reacts new functional direction.: https://github.com/mobxjs/mobx-react-lite#useobservabletinitialvalue-t-t https://github.com/mobxjs/mobx-react-lite#useobservabletinit...
underwater 8y ago
Are you using Storybook or a similar system? I've got a lot of value in defining my application in decoupled components when I can verify the implementation of each part in isolation.
- Azeralthefallen 8y ago
  We write tests to verify if things are working correctly using Cypress + Mocha. We have simple unit tests for validating basic functionality and extensive integration tests. We typically have a set of tests per feature. The problem i have noticed is that people say "well it works in isolation", but on integration with other components it doesn't work properly. Unfortunately this is a huge problem i find, and frankly the idea of numerous shared hooks and ensuring they are side affect free is very painful.

fastbmk 8y ago

TL;DR People who wish that progress would stop on jQuery & Rails - won't like React Hooks either.

coldtea 8y ago

>This coding pattern also requires more babel transforms. Not a big problem but something that developers should be aware of. This sounds like a totally BS reason in the context where it is said.

deleted 8y ago

[deleted]

tekkk 8y ago

So can someone explain what the author means by the problem of #3: >However, there are times when we need to pass an extra parameter. In those cases, we cannot use bind because we cannot use bind with arrow functions. But you can pass the extra argument to the arrow function directly: `onChange={handleChange('name')}`. And use it as: handleChange = (field) => (e) => { this.setState({ [field]: e.target.value }); } Sure it still has the problems of arrow functions I think the arguments against it were worded poorly.