Dan Abramov

You might be interested in learning the reason hooks were invented [0]. I also use hooks in Flutter via a separate package and its creator made a great GitHub issue talking about exactly why class components cannot replicate the hook model [1], simply due to the limitations of how classes work. The code is in Dart but it's simple enough to grasp if you know JS and class concepts in general like overrides and mixins. [0] https://medium.com/@dan_abramov/making-sense-of-react-hooks-fdbde88038… [1] https://github.com/flutter/flutter/issues/51752

You might want to read my "Tao of Redux" posts and Dan's "You Might Not Need Redux" post, which explain why Redux was designed the way it is: - https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao-of-redux… - https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao-of-redux… - https://medium.com/@dan_abramov/you-might-not-need-redux-be46360cf367 Ultimately, it's about putting a deliberate separation between "what happened" in the UI and "how the state is updated", writing as much of your state update logic as pure functions, and being able to use that indirection to enable tracing state updates over time via the DevTools. Also note that our official Redux Toolkit package is now the standard recommended way to write Redux logic, and it simplifies most of the Redux code you'll write: https://redux.js.org/tutorials/fundamentals/part-8-modern-redux

Hi Dustin. No, those function/method calls are equivalent. My central point is that it is not reasonable to expect the consumer of a value to recover from a failure mode that was generated at the producer. Rather, it is better to handle failover and retries at the producer. Of course, once a (valid) value has left your system, any downstream errors are the purvue of the subsystem, but you may want to provide a signalling pathway back to the producer if it can be resolved upstream. This naturally results in writing thinner consuming functions and "fatter producers" or "smarter callers."[^1] https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0

I perhaps foolishly go ahead and teach React and Redux to my students. The first thing I show them, however, is this article by Dan Abramov, who you perhaps know from his conference videos or his amazing work fielding React bug reports. You might not need Redux: https://medium.com/@dan_abramov/you-might-not-need-redux-be46360cf367 The little example he provides is remarkably powerful and a great intro to thinking like a Redux programmer.

The (excellent) article is "You Might Not Need Redux" and is a great read whether you're considering Redux, already using it, or never will. https://medium.com/@dan_abramov/you-might-not-need-redux-be46360cf367

I'm not sure what your complaint is about computed properties. You should either store the computed data in the reducer, compute it on the fly in render, or use componentWillReceiveProps and/or setState. Your problem isn't needing to make React behave like Vue, you need to let React behave like React. The second point I was trying to make is you don't have to do it that way in React. React is a perfectly functional framework without Redux or the "container" model. That style became popular because you're enforcing that the majority of your components are dumb [1] which is a pretty useful thing for a large project. But again, these aren't problems with React and if it's giving you this much heartburn it's worth bringing up with your team because it sounds like something's going wrong. 1. https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0

I agree. Dan Abramov the creator of Redux has a whole article devoted to this topic: https://medium.com/@dan_abramov/you-might-not-need-redux-be46360cf367 A lot of the work I'm doing right now is in a reasonably complex react native app with multiple screens. In that context its worth the added boiler plate. I wouldn't use it for a one or two screen app with little shared state.

You can check out polymer-redux (https://github.com/tur-nr/polymer-redux). It's makes it easy to integrate the redux store inside your components. Basically you will split up your components in two types: 1.) container components that are redux aware and subscribes to slices of your state graph and pure presentational components that are unaware of redux and are management by the container components. This is similar to what is suggested in React/Redux. This way you can re-use your presentational components elsewhere. Check also this guide: https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0…

So for people who think they need Redux, first read "You Might Not Need Redux" [0] by Dan Abramov himself, creator of Redux. Then also I would recommend MobX [1] over Redux, it's easier to get started and in my opinion easier and better in general. [0] https://medium.com/@dan_abramov/you-might-not-need-redux-be46360cf367#… [1] https://github.com/mobxjs/mobx

Bravo to the React team for the work during the last few months! It's truly amazing, specially for the new users. Among other things: 1) Create-React-App[1]: Lets everyone starts a React app with Babel/Webpack (JSX, classes and import/export) without any knowledge about Babel/Webpack. 2) The new Contributing docs (Codebase Overview, Implementation Notes (discussed here) and Design Principles) offer a starting point to figure out how React works. 3) A revamp of the current documentation is going to be released soon[2] 4) "You might not need Redux"[3] --- [1] https://github.com/facebookincubator/create-react-app [2] https://github.com/facebook/react/pulls?q=is%3Apr+is%3Aopen+label%3A%2… [3] https://medium.com/@dan_abramov/you-might-not-need-redux-be46360cf367#…

I follow Dan Abramov's recommendations: https://medium.com/@dan_abramov/lint-like-it-s-2015-6987d44c5b48

And if you like Dan's talk, check out his blog post My Inspiration to get some more background on the topic. https://medium.com/@dan_abramov/my-inspiration-ce454ab65f33 BTW vjeux, great job at React Europe!

I haven't seen that usage for higher-order components before. This is the pattern I've been following: function decorate (Component) { let HigherOrderComponent = React.createClass({ render () { return <Component {...this.props} /> } }) return HigherOrderComponent } as explained here: https://medium.com/@dan_abramov/mixins-are-dead-long-live-higher-order…

Great post. A quite similar pattern is common in ES6 React: https://medium.com/@dan_abramov/mixins-are-dead-long-live-higher-order…

I've recently started to integrate a linter to all of my tool chains, and I don't want to live without one. So it's great to see such wide-spread support. My tool of choice though is eslint and its react plugin [1]. Which seems to have some additional features like enforcing some best practises. It's probably also worth posting this guide [2] from awesome Dan Abramov of how to setup linting for Sublime Text 3 and/or webpack. [1] https://github.com/yannickcr/eslint-plugin-react [2] https://medium.com/@dan_abramov/lint-like-it-s-2015-6987d44c5b48

Just a reminder: the best part of React isn't about its diffing algorithm or the virtual DOM. Plenty of articles have been written on this (e.g. https://medium.com/@dan_abramov/youre-missing-the-point-of-react-a20e3… The diffing algorithm is a smart way of circumventing the fact that the DOM is so slow; there's nothing to be proud of working with such thing. Ideally your platform isn't so. Web devs will keep reimplementing parts of React elsewhere; but at least, be inspired by some other parts of React please.

> it was explicitly pushed and advertised as such I'm sure React fans who misunderstood the virtual DOM (which was explicitly advertised because it was the most popular part of React[1] vs the other parts that people were more critical of) may have said this, but I never saw the project itself advertising itself as faster than vanilla JS, only that it could be faster than competing frameworks, _especially_ ones that rebuilt the DOM unnecessarily. > I dunno, I used Redux for a few years Redux is a different library than React. State management across an app is a problem even for non-React applications, it's not like React _uniquely requires_ work to address state management. I don't see why your dissatisfaction with Redux has anything to do with React making a very specific and buggy part of building web apps easier to manage in return for a performance cost and following its API. [1]: See mention near the end of https://medium.com/@dan_abramov/youre-missing-the-point-of-react-a20e3…

That perception of the DOM/VDOM situation is and always was false. React was always slower at runtime than a carefully-engineered system designed for performance. As Dan Abramov said a couple of years later <https://medium.com/@dan_abramov/youre-missing-the-point-of-react-a20e3… people were missing the point of React: it was never about VDOM; rather, that was a cost that at the time they reckoned had to be paid in order to write reliable code in an immediate mode style, because if you tried doing that without DOM reconciliation the result would be atrociously bad. VDOM came about because the alternative (the consistently faster alternative, I may add) entailed things like explicit DOM mutation that was far too easy to make mistakes with, and reactive data flow was generally even buggier. It was a carefully-chosen trade-off: shedding some performance, for greater robustness and ease of use. “DOM is slow, VDOM is fast” was a straw man comparison that entered the public perception but which the React team mostly stayed well clear of: almost no serious systems have ever used the DOM directly in the immediate mode style, because it has obvious and serious problems in both performance and transient UI state like scroll and caret positions and element focus (… and transient state things are problems for all immediate mode interfaces, not just DOM ones: escape hatches are fundamentally required). Was VDOM worth the cost at the time, compared with the other options then…

tl;dr: use TypeScript, but don't worry so much about hooks. --- I recently switched my JS + PureComponent mobile app to TypeScript and FC Hooks. I felt motivated to do so because: - You cannot use hooks in PureComponent render(). The two modalities do not play nice together. - Many of the libraries I use like react-spring and react-navigation have fully embraced hooks, sometimes without an HOC equivalent. So I felt forced to also embrace hooks or write complicated wrappers to facilitate them, for example new component lifecycle methods (e.g. componentDidFocus). Some things I noticed... 1. TypeScript is amazing. Combined with Intellisense it has given me coding superpowers. I can write code faster and with dramatically more confidence. 2. You can incrementally shift your JS app to use TypeScript. You can even write type declarations for your JS code without rewriting it in TS. Most of your favorite libraries already have such type definitions (see DefinitelyTyped). 3. Hooks require a significantly different mental model than PureComponent. It feels horribly wasteful at first but apparently relies heavily on JS interpreter optimizations and memoization to achieve superior FMP performance[1]. My app feels noticeably snappier now, but it took a good bit of tuning to correct issues introduced during the port. 4. It IS indeed possible to write a functional wrapper that provides otherwise unavailable hook support for your Component or PureComponent. The tricky part is that…

> As for the "boilerplate" line... everyone throws around this word, and everyone means something different. Could you clarify what specific things you're thinking of when you say that? As stated before I haven't done a big JS project for about a year now. In the last project I did we used redux in a create-react-app. At the time the best practice was creating presentational and container components[1]. The biggest boilerplate was: - Whenever we added a react component (presentational) we would need to create a container component to wrap it in, this would always result in ~20 or basically the same lines (in our project we did things pretty verbose, so we didn't have a HoC or whatever people use). - "immutable update logic", reducing deeply nested objects is a pain an error prone (using es6 spread or Object.assign), I've heard about some libraries that can help with this, but we didn't use anything at the time). > FWIW, we have a new package called `redux-starter-kit` I am most definitely going to use this for an upcoming project! [1] https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0

> In order to be able to tell if you need Redux or not for a project, you need to know Redux Not according to the creator of Redux. His advice is "Instead learn to think in React. Come back to Redux if you find a real need for it, or if you want to try something new. But approach it with caution, just like you do with any highly opinionated tool." https://medium.com/@dan_abramov/you-might-not-need-redux-be46360cf367 > too many developers overestimate their intelligence and write awful code because they didn't take the time to learn well the tools No argument there. You do have to go through the entire official tutorial, and I would also recommend the article "Thinking in React", that Dan Abramov referenced above. https://reactjs.org/docs/thinking-in-react.html I'm not claiming your experience with awful code isn't real, I'm sure it is. But is it because React is difficult to learn? When I learned React I was already good at JavaScript. And I had already learned Angular. Angular took me over a month to start to feel comfortable, and I still felt like I was stumbling around in the dark. The Angular API is very big. With React I was writing code, and code that I still use, within days. And I felt comfortable that I mostly knew what I was doing. When my code got a little more complex, I took a few hours to read about and learn about Higher Order Components. And when I needed routing I taught myself React Router in one day, and began answering questions about it on…

The "You Might Not Need Redux" blog post by the author of Redux addresses your points almost directly: https://medium.com/@dan_abramov/you-might-not-need-redux-be46360cf367 The TL;DR is Redux tries to place a set of constraints on how and when you're allowed to share state between components and how and when you're allowed mutate that shared state, much like how React and it's virtual DOM abstraction places constraints on how and when you're allowed to manipulate the DOM. These constraints allows the library to make certain assumptions about state and state changes that enables it to perform global performance optimizations across the entire codebase (namely performing only shallow equality checks on all state-mapped props when determining whether or not to rerender, because it can assume all state changes will result in a reference change) that would otherwise have to be performed for each component on a case by case basis, and micro-optimized by each individual developer by hand. These constraints also allows tooling authors to make these same assumptions, which is what enables the best-in-class tooling that Redux developers have access to, like time traveling debugging and state change replays. These tools would simply not be possible to build in a generalizable way if your codebase didn't allow them to make the same assumptions (and adhere to the corresponding constraints when it comes to state sharing and state mutations) as it could for a Redux codebase. The post…

Redux is just one piece of the puzzle. Let me try to explain the problem it solves. Let's say if you are building a complex SPA with lot of UI components in the view and state changes impacts several parts of the view. You can build this view in several ways: * Plain javascript with jquery - We can surely achieve it but the code quickly becomes a soup of callbacks and events handlers. After a while the code becomes unmanageable. This is pretty much the approach you're suggesting with getters/setters. * AngularJS's dirty checking is one solution. It works and the code scales in large teams but perf suffers in complex views due to costly digests. It doesn't provide a way to conditionally exclude a sub-view from the digest cycle. This will become the main bottleneck (for perf) as the application grows. * React and Angular 2/4 - React (shouldcomponentupdate) and Angular 2/4 (onpush change detection) leverages immutability very well to cut down re-render cycles. This is where Redux shines with its immutable way of changing state. It's uni-directional flow is another great benefit to keep the entire flow predictable and maintainable. I am not saying all these things are needed for every SPA app out there. But these optimizations are needed for complex and performance sensitive applications. Check this out - https://medium.com/@dan_abramov/you-might-not-need-redux-be46360cf367 Also, I know keeping application state as a single state tree is nothing new. I started this side…

Hey there, I'll start with the disclaimer, as lately HN comments have tendency of becoming toxic - everything I write is my personal opinion. With that behind us I can start. I'll try to write this for someone who knows very little about JS, but knows her/his way around basic programming/cs. Firstly I love JavaScript, I have been writing it for 10 years now, but there are bad parts of it as well. Let's start with good stuff * It is evolving in the right direction * You can do a lot of things with it (web apps, games, mobile apps, server...) * Materials for learning are everywhere * It will be easy to find a job Bad stuff * It is moving at crazy to follow pace * There are a lot of different ways of doing same things * As it is very hip thing to do, there is a lot of bu___hit (beware of the hype train) Learn plain javascript before moving to frameworks. Focus on ES6 and new stuff as it will make your life way easier. * Someone already mentioned Dr. Axel Rauschmayer, pick any of his books - http://exploringjs.com/ * Another good one is You Dont Know JS - https://github.com/getify/You-Dont-Know-JS Try to make small app on your own. You'll get into all sort of problems, but that's the fun part I guess. That will help you to understand what frameworks are trying to solve. Then you can start learning one of the frameworks. React, Vue, Angular are all solid choices. My pick is React, as I know it best. Apply the same mindset as with learning plain JS. Try to write…

> why is the language taking a OO direction Classes are just sugar over how devs were already doing class-like stuff with prototypes (see backbone/ember/angular etc). So I'd disagree that the language is 'taking an OO direction'. > If the tendency of the developer community is towards (faux) functional programming Wouldn't agree with that either. Some sub-communities perhaps. But e.g. in React there's a big push back towards using (class-based) Components and good old setState(). > I'd like to use ES6 classes, but I can't because I'm told it's not idiomatic These people need re-informing! React Components and setState() are what Facebook use. In my opinion, setState() plus a router will handle the vast majority of state in your app just fine. To get more of a feel for this setState() vs Redux kerfuffle: Ryan Florence (of React Router) is a Components/setState proponent, and great person to follow on Twitter. I like his intro to this talk [1] where he talks about the issue. Also highly recommend reading 'Functional setState is the Future of React' [2]. And of course I think it's already been posted elsewhere in the thread, but Dan Abramov's own 'You might not need Redux' is definitely worth a read [3]. [1] https://www.youtube.com/watch?v=kp-NOggyz54 [2] https://medium.freecodecamp.com/functional-setstate-is-the-future-of-r… [3] https://medium.com/@dan_abramov/you-might-not-need-redux-be46360cf367

Since I am developing on a daily basis with React, it is obviously my favorite choice. It is not a framework, but a view layer library. However, by only using the view layer you can already build frontend applications. The ecosystem around React is huge. But you don't have to use anything to build an application with React. [0] For instance, most people try too early to use a state management library. But you don't have to use it from the start [1], because React comes with its own internal state management. It makes sense to learn the React fundamentals first and build your own application with it [2] before you dive deeper into the ecosystem [3]. - [0] https://www.robinwieruch.de/reasons-why-i-moved-from-angular-to-react/ - [1] https://medium.com/@dan_abramov/you-might-not-need-redux-be46360cf367 - [2] https://www.robinwieruch.de/the-road-to-learn-react/ - [3] https://github.com/markerikson/react-redux-links

This reminds me of a recent article by the author of Redux, who wrote ["You might not need Redux"](https://medium.com/@dan_abramov/you-might-not-need-redux-be46360cf367)… It was refreshing how he emphasized that Redux is just an implementation of a design pattern (or a composition of a few), that it's not necessarily "the solution". If another state management library works better for some applications, then use that instead. "Overhyped" implies that its popularity is not worth its value. It's clear that it has proven its value to a majority of developers working with React. Especially as applications grow larger, I've found that using Redux provides an intuitive pattern for sane state management. It does have its pain points (verbosity, async actions) but there's a plethora of libraries one could choose from, depending on need and preference. Since the core functions are so simple, they can be adapted as needed - for example, in a recent project I wrote a wrapper (~20 lines) to extend actions and reducers with namespaces. An additional advantage of Redux, I think, is that it's becoming widely adopted, so when I look at an open-source codebase built on React + Redux, it's so easy to understand the application architecture.

The React way is different and I was hesitant, but it is better. It combines the best parts of native app development with the best parts of web development, then improves on them. The old way of doing CSS was crazy and unmanageable because CSS was intended for documents. Cascading styles are useful for publications, but they are unwieldy for UI components. There aren't many native app designers clamoring for global cascading styles. The React way of separating design concerns from logic is to build container components[1] that handle the logic and pass props down to simple components that just display the data they're given. I would expect designers to spend more time in presentational components and CSS modules[2] while developers would build container components. (I'm a one-man shop doing both.) [1] https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0… [2] https://github.com/css-modules/css-modules

I'm all for uni-directional data flow and React's concept of being explicit by passing data down through props. When it comes to application state however, that's when I whip out React's context (now documented https://facebook.github.io/react/docs/context.html). I follow the pattern of Redux/Baobab of having a monolithic state and partitioning it by module namespace (to avoid data dependency issues, e.g. Flux's waitFor hell http://christianalfoni.github.io/javascript/2015/02/06/plant-a-baobab-… Each module manages its slice of state and exposes an API for encapsulation. This also plays really well with React Router. In other words, the application state and the actions that can be performed on the state are passed down through the context. I prefer Redux's concept of smart/dumb components (https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0… to make sure the application state isn't being spaghettied all over the code. With Mobservable, there's a specific part of their documentation which I think does a decent job of explaining a similar set up: https://mweststrate.github.io/mobservable/best/store.html

I'm not the original commenter, but see the 2019 update on this Dan Abramov article: https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0