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

121–130 of 205 posts

Re: React: Mixins Considered Harmful

#121

Post by adregan »

danabramov wrote: post #102
amelius wrote: post #91

Earlier quoted context omitted.

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

Could you expand on string refs as an anti-pattern?

Re: React: Mixins Considered Harmful

#122

Post by tlrobinson »

sergiotapia wrote: post #118

React dropping mixins is the #1 reason why I stopped using Meteor. Sure Meteor has Blaze, but nobody uses it. Before we had a nice mixin called getMeteorData: ``` var HelloUser = React.createClass({ mixins: [ReactMeteorData], getMeteorData() { return { currentUser: Meteor.user() }; }, render() { return Hello {this.data.currentUser.username}! ; } }); ``` Short, simple, you knew exactly what it was doing without breaki…

I was going to sketch out a higher order component for you that does the same thing but it looks like they've already implemented that: https://atmospherejs.com/meteor/react-meteor-data

I guess this is the "create container lunacy" you're talking about?

I'm not sure what's so horrible about it, especially if you enable decorators in Babel (admittedly non-standard syntax but it works great):

    @createContainer(() => ({
        currentUser: Meteor.user()
    }))
    export default class Foo extends Component {
         return Hello {this.props.data.currentUser.username}!;
    }
This is basically how Redux's React bindings works too.

Is it really just the syntax you're upset about, or am I missing something?

Re: React: Mixins Considered Harmful

#123

Post by kerkeslager »

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 can't speak for the community as I've been using React/Flux for under a year, but I think that Redux and other Fluxes serve a very different role from component state, and using Redux/Flux to store all your state will cause problems with both performance and code complexity.

Redux manages the state of your application as a whole. But individual pieces within the page have no reason to know about the page state. Likewise, there's no reason for your Redux stores to concern themselves with the detailed workings of every component. Why should your app care what's going on inside a button or a menu? That leads to gigantic, overcomplicated states. Let the components manage things for themselves.

A good rule of thumb might be that if three layers of components need to know about a piece of data, it might be good to consider moving it into a store. But if it's only a component and its child components that need to know about it, you're not gaining much by moving it into stores--the stores and actions you'll have to implement are just added complexity. It's incredibly frustrating when I come across code where I have to push data through an action and a store and dispatch when a simple call to setState would have done all the same things faster and with less code.

Re: React: Mixins Considered Harmful

#124

Post by pka »

daliwali wrote: post #110
danabramov wrote: post #83

Earlier quoted context omitted.

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

Higher order functions are not such a complicated concept. Just a function passed to a function.

You use functions, right?

Re: React: Mixins Considered Harmful

#125

Post by Bahamut »

danabramov wrote: post #104
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 us…

I would add that there seems to be a push against inheritance in general with UI components in the frontend web app world. React clearly is designed against using it, and same thing with Angular 2 (inheritance does not play well with decorators, which are metadata on specific component classes). I don't think we really see any modern UI library/framework adopting inheritance as a valid pattern at the component level, precisely due to the problems of leading developers down the path of creating potentially incorrect abstractions & being too painful to fix when UI can potentially change quite a bit structurally.

In addition, anything a user can accomplish with inheritance, a user can also accomplish with composition, but while retaining flexibility, so when considering how much the UI layer can change in an app, one generally wants that flexibility. Inheritance is more useful when creating low level abstractions or maybe wrappers around such, but should generally be avoided when it comes to consumption for higher order constructs because of the complex chains involved.

* This is what I have found at least - perhaps I'm making some incorrect points. If so, I'd like to know why I'm wrong here, since these are just conclusions I've drawn from experience so far.

Re: React: Mixins Considered Harmful

#126

Post by iandanforth »

danabramov wrote: post #104
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 us…

This is incredibly unfortunate. I feel like this attitude will turn off and hamper a lot of potential users. It smacks of functional proselytizing and it is not appreciated.

Re: React: Mixins Considered Harmful

#127

Post by juanger »

jacobr wrote: post #96
janci wrote: 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?

not exactly harmful, but in the docs they promote stateless functions by saying:

"In an ideal world, most of your components would be stateless functions because in the future we’ll also be able to make performance optimizations specific to these components by avoiding unnecessary checks and memory allocations. This is the recommended pattern, when possible."

See https://facebook.github.io/react/docs/reusable-components.ht...

Re: React: Mixins Considered Harmful

#128

Post by smac8 »

janci wrote: 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…

Not sure what you mean on component state, as I've never heard anyone say that is explicitly harmful, but I think what you might be getting at is the principal in react of creating MINIMAL state such that any logic - for example something that renders an item - can compute off that MINIMAL state, rather than creating a new state that's the result of processing that basic state. The example given in Thinking in React[1] is having an array in state, but computing it's length somewhere (say in render), rather than making the length of the array also part of the state.

On this note, I find that I rarely use state in child components, because as much as possible I have functions that compute values off props and simply return that where I need them, rather than storing them as state variables.

[1] https://facebook.github.io/react/docs/thinking-in-react.html

Re: React: Mixins Considered Harmful

#129

Post by jameslk »

That's too bad, mixins were simple to grasp and worked really well. The oft suggested alternative to mixins is higher order components. Here's one of my favorite quotes[0] on the matter:

> You lose so much with [higher order components], especially with es6:

> You lose the (original) class, and with it, the ability to compose it, to extend it and …. reflection. All your components are [the higher order component]. For example, you cannot rely on the Class.name in es6.

> You lose the ability to extend the component and expose extra members. Your higher order component will not ‘pass’ that through.

> The above two basically renders the ability to compose several decoupled and agnostic one to the other “higher level components” impossible.

> It is verbose and non-declarative , and basically much less readable and maintainable.

If there's a better pattern than mixins, I would say its traits[1]. For some reason, I don't find it used much often in the wild. I'm not sure it would be practically applied to React anyway without ending up with mixins again, but at least the concept would be clearer: there should be no shared state and dependencies are explicit.

0. https://medium.com/@danikenan/you-lose-so-much-with-your-sol...

1. https://en.wikipedia.org/wiki/Trait_%28computer_programming%...

Re: React: Mixins Considered Harmful

#130

Post by johncip »

adregan wrote: post #121
danabramov wrote: post #102

Earlier quoted context omitted.

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

Could you expand on string refs as an anti-pattern?

I'd like an answer to this as well. I've only ever needed string refs, and the callback refs are noisy. I can see where the React team may not want to support both, but are string refs actually bad in some way?
Post reply on HN