I know there’s an aversion to classes in a lot of the current React community but the Component design in React was really much easier to reason with.

I really hope this idea makes it into the mainstream react community and even blend with it. Let’s call this react 2.0 and start building on it, while keeping it compatible with react 1.x for now!

React, in its current form, requires classes or something class-like in order to implement stateful components with lifecycles. It also does not require that you handle data immutably - you can run `this.state.someArray.push(newValue); this.setState({someArray : this.state.someArray})`, and React will re-render just fine.

However, React also pushes you in functional programming directions: render methods should be pure functions, performance optimizations with `shouldComponentUpdate` work best if you've handled data immutably, and so on. The React team also plans to investigate a "stateful functional component" API at some point after the React 16 release.

It's also worth noting that React was not the only reason why classes were added to Javascript. There were hundreds of "pseudo-class" implementations out there already (all a little bit different than the others), and there was clearly enough demand for the concept to add it to the language in a standardized way.

Meanwhile, Redux has definitely helped popularize the idea of updating data immutably. The array spread operator was already added in ES6, and the object spread operator is nearing finalization. No, the language doesn't have full-blown immutable data structures, but handling data immutably is absolutely possible. If you don't like dealing with immutable updates yourself, there's Immutable.js (as you said), or dozens of immutable update utility libraries.

Particularly in the case of Redux, use of classes for data is discouraged because of the other constraints Redux asks you to follow. Plain serializable data is needed in order for time-travel debugging and persistence scenarios to work properly.

Overall, your complaints are split across a couple things. Classes exist because some JS devs want to use them. Functional-style approaches exist because some devs want to use them. Languages like C# and C++ have been "everything and the kitchen sink" for a while now, supporting multiple different paradigms in one language - Javascript is now the same way.

I just started playing around with react pretty recently, and it definitely seems like people's opinions about how to structure things have shifted pretty quickly.

(How's that different from just a function? It shows up as separate thing in React DevTools, it can have default props or, in the future, shouldComponentUpdate (or built-in memoization strategy?), you can potentially later change it to be stateful without rewriting consuming code, etc)

One one hand, staying within the world of React components gives you a lot of functionality for free. And with Suspense and Hooks, the amount you can do within a component has become even greater.

On the other hand, there are still things that you can't do within a component. For example, you can't easily run an async function once when the component mounts - which in my opinion, would be the perfect way to fetch data.

I've been building Navi to try and create a more natural way to map routes to views and a stream of data. The thing is, the more edge cases you cover, the closer it becomes to just building React from scratch.

At this point I still think that routing and data fetching is better handled externally from React, but it's less clear cut than it used to be.

That said, I don't miss higher order components, but I do find myself reaching for renderprops sometimes. I think it's still a great pattern.

The change is subtle and easy to misinterpret. It's not that React drank ES6 class kool-aid and we're now gonna use inheritance over composition. (Nope[1], in fact pretty much the opposite[2].)

The real change is that React.createClass is no longer the way to create components. It's just a fancy wrapper (which is not even being deprecated). You want magic, you opt-in to it.

ES6 classes are also not the way to create components. As mentioned at the end of the article, you can even use ES3 module pattern:

    function MyComponent(initialProps) {
      return {
        state: { value: initialProps.initialValue },
        render: function() {
          return <span className={this.state.value} />
        }
      };
    }

Competition for mixin systems is now possible.

Finally, this change opens up more possibilities for potential React-like frameworks to “interpret” React components. Of course we don't do that today, but it's still a nice property and may be handy later when you decide to switch to future React-like competitor.

It's the anti-lock-in.

[0]: http://jlongster.com/Modularity

[1]: https://github.com/facebook/react/issues/613#issuecomment-29...

[2]: https://github.com/reactjs/react-future/blob/master/01%20-%2...

> My favorite way to do data fetching is as close to the place where I am using the data. React made it possible up until this change.

Well, yes, but we are nowadays in a situation where every component interacts directly with the state, or makes calls to the API (eg with the overuse of query), going against one of the architecture principles of react. It's like we're not building components, we're building component sized micro-ui.

The major issue is life cycle. When is a class component instance created or destroyed? The answer is "whenever the framework feels like it," and that's a really ugly model for instance life cycle. Additionally and most importantly, it means that member variables on a React class component instance don't work the way that members are expected to work; you just can't rely on them having any particular value because the framework can create or destroy an instance when it feels like it for performance reasons. What good is a class and instance abstraction if when you try to use member variables (one of the key features of object-oriented programming) you're highly likely to just break the model in hard-to-debug ways?

Because the framework isn't using class component instances like instances are supposed to be used, the React team is tossing that model to the curb.

Please read the official release notes when upgrading.

Nowhere does 0.14 say you need to change components to use classes. They are allowed now (since 0.13) but React.createClass() is still there and is not going away any time soon. I’m afraid you listened to bad advice.

React is a really great fit for Om, persistent data structures, and functional programming in the following ways:

1. We want to allow developers to elegantly describe their user interface at any point in time, as a pure-as-possible function of data dependencies.

2. We allow hooks for your system to help guide the updating process along. These hooks are not necessary. Often, we'll add optimizations long after we ship. We strongly believe that perf optimizing shouldn't get in the way of writing code elegantly and shouldn't get in the way of the creative development process and actually shipping to your users. At the same time, performance matters - a lot. So we ensure that at any point in the update process, if you know better than the framework, you can help guide the system. The fact that this is optional and doesn't change the functionality or correctness of the system is critical. Persistent data structures are an excellent (likely the very best) way to hook into the update system without making the developer do anything special.

Some people here were wondering about the apparent OO influence in React. Here's how I personally think of React's OO support/influence:

1. It's there to help you bridge with other existing mutative, stateful libraries in your stack - you know you have them. The DOM falls into this category as well.

2. It's there when you want to treat state as an implementation detail of a subcomponent. This is only because we don't have a good way of externalizing state changes, while simultaneously keeping the nature of them private. We just need more people to think about it (I'm sure the ClojureScript community can help us chew on this). Our internal motto is to keep things as stateless as possible.

3. A lot of the OO support in React is there as a concession, more than being considered a virtue. It's really cool to have the FP community involved in the UI space. Those people are already sold on FP and statelessness and get the luxury of programming in tomorrow's paradigms today (how ironic that FP has been around for decades!) To accelerate this momentum, we also want to reach out to people who aren't yet sold and change how they think about building UIs and software in general. The most effective way to do this is to reach out to them where they stand today, on some middle ground. It's really great to see eyes light up when they see that they can use simple functional composition in order to build large, sophisticated apps.

We're really glad to have swannodette and the ClojureScript community checking out React (github.com/facebook/react). We should consider adding some level of support for persistent data structures in the React core. Let us know if there's anything we can do to help.

What you should be doing is just changing the parts that you know have changed. Letting react do the hard work will always lead to worse performance

It's the same concepts of props, state, context, and lifecycle behavior as before.

It's just that now you can do it in function components, not just class components, and the APIs let you handle things without having to have additional levels of wrapper components and without the complexity of class-related gotchas.