Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

React: Mixins Considered Harmful

facebook.github.io

Post reply on HN
Print view View original

101–110 of 205 posts

Re: React: Mixins Considered Harmful

#101

Post by [deleted] »

janci wrote: post #99
danabramov wrote: post #97

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

[deleted]

Re: React: Mixins Considered Harmful

#102

Post by danabramov »

amelius wrote: post #91
n0us wrote: 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?)

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

String refs and `findDOMNode()`. Both are anti-patterns but not deprecated yet. Both replaced by callback refs.

Re: React: Mixins Considered Harmful

#103

Post by janci »

danabramov wrote: post #100
janci wrote: post #99

Earlier quoted context omitted.

> 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,…

I had an impression, that React community (not the authors) considers Redux as an best-practice. My first post was a little bit exaggerated view on where is this whole React-based website developement (including Redux and other libraries and tools) going, not only the React itself.

Re: React: Mixins Considered Harmful

#104

Post by danabramov »

iandanforth wrote: post #89

I worry this suggests an opposition to inheritance in general. Sharing code through class hierarchy is incredibly useful and common. I'd hate for ES6 to add decent classes and then have React push people away from 'extends'. But perhaps I'm reading too much into this.

>I worry this suggests an opposition to inheritance in general. Sharing code through class hierarchy is incredibly useful and common.

This is indeed opposition to inheritance in general, precisely because we tried it, and it doesn’t work great in React apps. React has a strong composition model that does not need inheritance.

https://discuss.reactjs.org/t/best-practices-for-extending-s...

Of course you are free to use inheritance for other purposes. (Or even React components if you insist.) But as the team behind this library, we strongly suggest you to use composition instead of inheritance when defining React components.

Re: React: Mixins Considered Harmful

#105

Post by danabramov »

janci wrote: post #103
danabramov wrote: post #100

Earlier quoted context omitted.

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,…

I had an impression, that React community (not the authors) considers Redux as an best-practice. My first post was a little bit exaggerated view on where is this whole React-based website developement (including Redux and other libraries and tools) going, not only the React itself.

>I had an impression, that React community (not the authors) considers Redux as an best-practice.

A part of React community, yes. Another part, no. Guess which part is vocal because they can write tutorials, examples, articles that generate clicks? ;-) I am as guilty of this as anyone of course, if not the most.

Obviously React has some deficiencies addressed by Redux. So does Redux have deficiencies addressed by React. Eventually some of the ideas from Redux might make it back into React.

However I suggest learning to build apps with React itself first before using more radical approaches like Redux. You’ll benefit immensely from knowing both ways. I would not necessarily put trust into articles saying “X is the best practice” or “Y is an inferior paradigm”. I would, however, listen to somebody who says “we tried X and Y, and here’s what worked best for us and why”.

>My first post was a little bit exaggerated view on where is this whole React-based website developement (including Redux and other libraries and tools) going, not only the React itself.

Ah okay, sorry then! These are both interesting, albeit different directions. I think it’s easy to misunderstand them as an “evolution” whereas it’s really a “fork” (in the traditional, non-technical sense). These are two separate ways, and both lead to interesting but different things.

Re: React: Mixins Considered Harmful

#106

Post by hardwaresofton »

zpao wrote: post #21
hardwaresofton wrote: post #14

Did facebook just rediscover that mixins are an anti-pattern? I would have expected them to know that going in, figured they had just thought it was fine as long as they convinced people to use them very sparingly

No we've known and said it for a long time but not very loudly. People haven't used them sparingly and they tend to infect a codebase. Now we're just making a more concerted effort to communicate more broadly that they can be bad.

Thanks for replying -- I assume in whatever planning/architecture meetings went on before react was released that this was a measured decision you all chose to take, weighing the potential dangers less dangerous than the initial usefulness. Is this assumption correct?

If you could do it again, would you leave in mixins or would you keep them out?

Re: React: Mixins Considered Harmful

#107

Post by janci »

danabramov wrote: post #105
janci wrote: post #103

Earlier quoted context omitted.

I had an impression, that React community (not the authors) considers Redux as an best-practice. My first post was a little bit exaggerated view on where is this whole React-based website developement (including Redux and other libraries and tools) going, not only the React itself.

>I had an impression, that React community (not the authors) considers Redux as an best-practice. A part of React community, yes. Another part, no. Guess which part is vocal because they can write tutorials, examples, articles that generate clicks? ;-) I am as guilty of this as anyone of course, if not the most. Obviously React has some deficiencies addressed by Redux. So does Redux have deficiencies addressed by Rea…

I did. I started with React itself. Then I added Redux (first time, it was beacause of the project manager decision).

I really like the state reducers.

I find internal state clumsy, beacause you have three kinds of functions around the very same state object - get initial state, get state after some props changed and get state after some user action. For simple cases they are very similar to repeatedly write, but still different to abstract out.

I hate putting everything in One-Rules-Them-All Redux Store (specially form input on each key press), beacause it creates too much little components to glue it all together - Action declaration, action generator, reducer implementation, projection from Store to component's props

I did not see any good solutions that take best of both approaches and I was tired searching. But I plan to wrap my brain around this and think about what exactly is bothering me and how to solve that. In first sight it is what I outlined in my first post. The next thing comes to my mind are Redux-style reducers for component's internal state.

Re: React: Mixins Considered Harmful

#109

Post by danabramov »

janci wrote: post #107
danabramov wrote: post #105

Earlier quoted context omitted.

>I had an impression, that React community (not the authors) considers Redux as an best-practice. A part of React community, yes. Another part, no. Guess which part is vocal because they can write tutorials, examples, articles that generate clicks? ;-) I am as guilty of this as anyone of course, if not the most. Obviously React has some deficiencies addressed by Redux. So does Redux have deficiencies addressed by Rea…

I did. I started with React itself. Then I added Redux (first time, it was beacause of the project manager decision). I really like the state reducers. I find internal state clumsy, beacause you have three kinds of functions around the very same state object - get initial state, get state after some props changed and get state after some user action. For simple cases they are very similar to repeatedly write, but sti…

I hope this helps:

    dispatch(action) {
      this.setState(prevState => reducer(prevState, action))
    }

Re: React: Mixins Considered Harmful

#110

Post by daliwali »

danabramov wrote: post #83
daliwali wrote: post #80

Earlier quoted context omitted.

>Higher-order functions are extremely common and useful in all functional languages. Yes but higher order components as you call them, seem to be an abstraction that you would only use because the base unit of organization is a React component. I'm of the opinion that design patterns emerge due to deficiencies in the language or abstraction level, and that they can be avoided.

>Yes but higher order components as you call them, seem to be an abstraction that you would only use because the base unit of organization is a React component. I don’t really see the issue here. “How do you parameterize Y by X?” “Create a function that takes X and returns Y.” Doesn’t really seem React-specific. The unit of organization is indeed the component. Again, I’m not sure I understand why it being a first-cl…

>“How do you parameterize Y by X?” “Create a function that takes X and returns Y.” Doesn’t really seem React-specific.

I'm not talking about the what, but why would anyone think of using higher order functions to build user interfaces in the first place. It complicates the use case: building and mutating DOM Nodes.

>I think the opposite is true. The abstractions are more powerful when they afford building higher level abstractions on top of them.

And what may I ask requires so much power for building web front-ends?

Post reply on HN