Live data from Hacker News

React: Mixins Considered Harmful

facebook.github.io

91–100 of 205 posts

Re: React: Mixins Considered Harmful

#91
post #8

I personally moved all my projects away from mixins a while ago when I first heard they were deprecated. At first I was frustrated because of JS churn but this certainly was the right move. For anyone who is apprehensive, the shift in thinking from using mixins to HOCs was not so difficult even if it's initially puzzling. Quick edit: forgot to mention that this shift made my code way easier to understand in some plac…

> I personally moved all my projects away from mixins a while ago when I first heard they were deprecated.

Mixins were actually one of the things that turned me away from React in the first place. Perhaps a good time to reconsider :)

(Are there any other known anti-patterns left in React?)

Re: React: Mixins Considered Harmful

#92
post #81

Earlier quoted context omitted.

> "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.

IMO its no more trouble to put state in a redux store than in the component directly and doing so makes my components more consistent. I'm not a react guru though so maybe I'm missing something.

Eh, sometimes state isn't relevant outside of a component, so while you could put it in a store, it's possibly better to put it in the component. Single responsibility.

Re: React: Mixins Considered Harmful

#93

For those of you complaining about "javascript complexity": I think one of the biggest misunderstandings about JS and a large portion of the community complaining about "churn rate", is that JS does not have a churn problem, it has an inexperienced developer problem. Which is not to say that is a bad thing, JS/web is the first language for MANY programmers now. When you get stuck on learning this framework vs that fr…

0.3 - 0.1 = 0.19999999999999998

Re: React: Mixins Considered Harmful

#94

Earlier quoted context omitted.

>migrates the subscription logic from the component/mixin into the decorator. It was not migrating the logic from the component. The example was about getting rid of a mixin. I think the article even mentions the opposite: “If there is just one component subscribed to this data source, it is fine to embed the subscription logic right into the component. Avoid premature abstractions. >the problem is that everyone else…

Thanks again for clarifying, I don't want to criticize the work of the React authors or the community (which is outstanding), I'm just voicing what I observe from my "vocal bubble". Maybe I really spend too much time on HN :D

Yea, no problem. HN can be super misleading. I suggest to build apps and learn from the experience instead. ;-)

Re: React: Mixins Considered Harmful

#95
I like how core features of React are being considered harmful. First it was component internal state, now it's mixins and next thing will be the lifecycle methods.

React components will then boil down to pure render functions. React will then be replaced by simpler VirtualDOM implementation. JS function declaration boilerplate will be removed from render functions, so they will be more HTML with some JS as the other way around. Also they will be called templates.

We are getting back to good-old-days PHP-style webcoding, but with few HUGE improvements.

1. no globals, mostly pure functions

2. no business logic in templates, but in easy-to-reason-about redux-style state reducers

3. client-side rendering / isomorphic apps possible

Re: React: Mixins Considered Harmful

#96
post #95

I like how core features of React are being considered harmful. First it was component internal state, now it's mixins and next thing will be the lifecycle methods. React components will then boil down to pure render functions. React will then be replaced by simpler VirtualDOM implementation. JS function declaration boilerplate will be removed from render functions, so they will be more HTML with some JS as the other…

Component state is hardly considered harmful. What has given you that impression?

Re: React: Mixins Considered Harmful

#97
post #95

I like how core features of React are being considered harmful. First it was component internal state, now it's mixins and next thing will be the lifecycle methods. React components will then boil down to pure render functions. React will then be replaced by simpler VirtualDOM implementation. JS function declaration boilerplate will be removed from render functions, so they will be more HTML with some JS as the other…

>First it was component internal state

You won’t find any place in React docs that claims internal state is harmful. There are some guides claiming that but this is not the official position (and I say this as author of Redux and a member of React team). We use state a lot at Facebook, and it’s a large part of what makes React useful.

>next thing will be the lifecycle methods.

Lifecycle methods are also fine. Sure, it’s best when there aren’t too many and they don’t do too much, but it’s a supported feature for a reason. It is occasionally super useful. They aren’t going away.

>React components will then boil down to pure render functions. React will then be replaced by simpler VirtualDOM implementation.

This is an explicit non-goal of React. We think stateful components with lifecycle methods are very useful. If you don’t agree, however, React is indeed not the best choice for you, as it does too much.

I’ve read a lot of misconceptions around React so I plan to put up “Design Goals” document in the repo so people can get a better idea of the direction that we’re moving into, and why.

Re: React: Mixins Considered Harmful

#99
post #95

I like how core features of React are being considered harmful. First it was component internal state, now it's mixins and next thing will be the lifecycle methods. React components will then boil down to pure render functions. React will then be replaced by simpler VirtualDOM implementation. JS function declaration boilerplate will be removed from render functions, so they will be more HTML with some JS as the other…

>First it was component internal state You won’t find any place in React docs that claims internal state is harmful. There are some guides claiming that but this is not the official position (and I say this as author of Redux and a member of React team). We use state a lot at Facebook, and it’s a large part of what makes React useful. >next thing will be the lifecycle methods. Lifecycle methods are also fine. Sure, i…

>You won’t find any place in React docs that claims internal state is harmful.

But it is the first principle of Redux

The state of your whole application is stored in an object tree within a single store.[1]

Am I getting it wrong?

>I plan to put up “Design Goals” document in the repo

That would be great. The "why" is sometimes hard to understand.

[1]http://redux.js.org/docs/introduction/ThreePrinciples.html

Re: React: Mixins Considered Harmful

#100
post #99

Earlier quoted context omitted.

>First it was component internal state You won’t find any place in React docs that claims internal state is harmful. There are some guides claiming that but this is not the official position (and I say this as author of Redux and a member of React team). We use state a lot at Facebook, and it’s a large part of what makes React useful. >next thing will be the lifecycle methods. Lifecycle methods are also fine. Sure, i…

> You won’t find any place in React docs that claims internal state is harmful. But it is the first principle of Redux The state of your whole application is stored in an object tree within a single store. [1] Am I getting it wrong? > I plan to put up “Design Goals” document in the repo That would be great. The "why" is sometimes hard to understand. [1] http://redux.js.org/docs/introduction/ThreePrinciples.html

I think you are confusing React with Redux. They are two very different things. You can use them together but Redux is not the “default” way of using React.

>But it is the first principle of Redux

Redux is a very opinionated library and it is not related to React in any way. React does not officially endorse Redux. If (and that’s a big if!) React patterns don’t scale for you or if you personally prefer Redux to them, you can use it, but a Redux app !== a React app.

Which doesn’t mean either of them is the “right” or “wrong” way. Learn React first and try to use it. If you have issues related to state or if you’re just curious, you can also learn Redux to compare their approaches. If you like, you can combine them, or use them separately.

Post reply on HN