Live data from Hacker News

React: Mixins Considered Harmful

facebook.github.io

11–20 of 205 posts

Re: React: Mixins Considered Harmful

#11
post #9

It doesn't fare well that a framework that is only 3 years old already has an extensive list of anti-patterns and tons of statements on what not to do. Also having to do manual performance optimizations using the framework is a hassle to application developers and can be a major pitfall (ex. PureRenderMixin, shouldComponentUpdate).

As performance optimization goes, I've never seen a system for building apps where you never need to worry about performance. Our goal with React is to give good performance most of the time and to make it easy to optimize when you have problems -- in many cases, by adding a single shouldComponentUpdate. I think we generally succeed at this goal.

Re: React: Mixins Considered Harmful

#12
post #9

It doesn't fare well that a framework that is only 3 years old already has an extensive list of anti-patterns and tons of statements on what not to do. Also having to do manual performance optimizations using the framework is a hassle to application developers and can be a major pitfall (ex. PureRenderMixin, shouldComponentUpdate).

You have to consider that react was the first (popular) implementation of a virtual dom. We learned a tremendous amount how to implement and use the virtual dom in the mean time. And react isn't a framework, it only implements the view layer.

Re: React: Mixins Considered Harmful

#13
post #9

It doesn't fare well that a framework that is only 3 years old already has an extensive list of anti-patterns and tons of statements on what not to do. Also having to do manual performance optimizations using the framework is a hassle to application developers and can be a major pitfall (ex. PureRenderMixin, shouldComponentUpdate).

>It doesn't fare well that a framework that is only 3 years old already has an extensive list of anti-patterns and tons of statements on what not to do.

Doesn’t programming in general have solutions that scale well, and solutions that don’t scale well? Would you rather not have people writing about their experiences because it “doesn’t fare well”?

We are just sharing some things that worked well for us, and some things that didn’t. Things that didn’t (mixins) will eventually be forgotten as we move away from those APIs. So it looks like progress to me, but maybe I misunderstand something.

>Also having to do manual performance optimizations using the framework is a hassle to application developers and can be a major pitfall

You don’t “have to” do those optimizations. We only use them in about one in twenty components. But they are handy, and having an option to speed up a component with a few lines is better than having no such option. What do you think?

Re: React: Mixins Considered Harmful

#15
I see some React code using decorators but this article doesn't mention them. I'd love to get everyone's opinion on whether decorators are also an anti-pattern, even if decorators become a JavaScript standard.

Re: React: Mixins Considered Harmful

#16

I believe as time passes, we are moving away from the simplicity that made React win. Flux, Redux, higher order components generate too much complexity most of the time. React used to be simple, it still is, but the ecosystem and the mentality has gotten needlessly complex.

Just a small point, but React has always had higher order components as long as I've been using it because they're just a subset of higher order functions. It's more of a feature of JavaScript than it is of React. Also, I've been encountering higher order components since I started on React two years ago I think. The definition of what constitutes a higher order component is very broad. I think that any render() method which returns a component would qualify.

Re: React: Mixins Considered Harmful

#18

I believe as time passes, we are moving away from the simplicity that made React win. Flux, Redux, higher order components generate too much complexity most of the time. React used to be simple, it still is, but the ecosystem and the mentality has gotten needlessly complex.

Check out cycle.js. I haven't learned it quite yet but the promises seem really interesting. It's a fully reactive framework unlike react which is reactive only in view.

Cycle is indeed interesting! React is not “fully reactive” by design, and does not plan to move further into the reactive direction. We think that React is well-positioned in the app to understand how to efficiently schedule work instead, which is something that would be harder for us to do with a reactive “push” approach. I think as time goes, it will be interesting to see how both Cycle and React evolve into different directions, and what different tradeoffs they might present and benefit from.

Re: React: Mixins Considered Harmful

#19
post #6

I believe as time passes, we are moving away from the simplicity that made React win. Flux, Redux, higher order components generate too much complexity most of the time. React used to be simple, it still is, but the ecosystem and the mentality has gotten needlessly complex.

If simple things were possible before with React, then they still are, and that's not changing. You don't need Flux and Redux a lot of the time; in my experience they're overused and React component state is underused. I agree the community mentality of adding lots of complexity on top is a problem. We're working on improving this, but if you have ideas I'd be interested to hear them too.

> "in my experience they're overused and React component state is underused"

Thank you, I've felt the same way. A lot of projects take "ALL STATE MUST BE IN THE STORE" to an extreme.

Re: React: Mixins Considered Harmful

#20
post #17

Great post Dan. Just out of curiosity - what's your goto approach for replacing examples like the SetIntervalMixin ( https://facebook.github.io/react/docs/reusable-components.ht... ) with a HOC? I can't seem to find something that feels very elegant for these cases.

I’d probably create a class that lets me schedule intervals on its instance, and call `this.scheduler.dispose()` in `componentWillUnmount()`. I don’t think accidentally forgetting to dispose of it is a big problem as it’s easy to catch in a code review. But if it concerns you, HOC could work for this as well. In the future, we might build some helpers for this into React itself.
Post reply on HN