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

181–190 of 205 posts

Re: React: Mixins Considered Harmful

#181

Post by danabramov »

smadge wrote: post #115
danabramov wrote: post #87

Earlier quoted context omitted.

I think the intuition might be a little bit related but AFAIK monad is a very specific thing (can “lift” something and map functions over it, or at least that’s what I remember from a monad tutorial), and HOCs are different (they just wrap components). “Decorator” might be a closer pattern. I would say HOC is more like a regular higher order function... which is why it’s called this way. :P

I agree, a "higher order component" just isn't a monad. A HOC is just good old fashioned object composition. I think you are right to call it the decorator pattern. It annoys me how React ,and in general the entire javascript ecosystem, reinvents the wheel, then gives their invention another name.

It’s not quite object composition though. We are not forwarding any method calls or containing the instances. HOCs are much closer to functional composition than to object composition.

Re: React: Mixins Considered Harmful

#182

Post by danabramov »

jameslk wrote: post #129

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]. Fo…

>the ability to compose it, to extend it and …. reflection

In our experience those are precisely the things that can turn codebases into a mess. It’s great that you can manage the complexity from inheritance and reflection, but in our experience most people had problems with these patterns (me included). On the other hand, we found that React composition model is enough to express everything we needed in the apps, and we didn’t miss inheritance or reflection.

Re: React: Mixins Considered Harmful

#184

Post by danabramov »

enugu wrote: post #167

Racket has classes as first-class values. So a mixin is a function from one class to another. This seems similar to higher order components solution. https://docs.racket-lang.org/guide/classes.html?q=mixin#%28t...

Similar but the big difference is the wrapping component does not extend the wrapped component. It uses React component model for composition.

Re: React: Mixins Considered Harmful

#185

Post by danabramov »

skwosh wrote: post #140

It's not clear to me why (in the pattern presented) the decorators don't return a subclass (which would preserve the dynamic and static properties and methods, etc). Instead you get hacks like `hoist-non-react-statics` to copy them over manually. For context, the article advocates the following: import GlobalClass from 'global-class' const decorator = SuperClass => class extends GlobalClass { render() { return } } Th…

In our experience inheritance causes a lot of hard-to-find issues, and muddles boundaries between component concerns. Some of the same problems I described we had in mixins also apply to inheritance.

>and you lose the nice function-composition-like behaviour provided by `super.method`.

We found this to be an anti-pattern. It’s easy to get lost in virtual calls across hierarchy, and people are going to create virtual methods (and override them) if you allow it.

>Instead you get hacks like `hoist-non-react-statics` to copy them over manually.

An alternative is to just not put static methods on component. It’s not such a useful feature.

Re: React: Mixins Considered Harmful

#186

Post by danabramov »

biocomputation wrote: post #166
hicksyfern wrote: post #164

Earlier quoted context omitted.

I don't think you've really read and understood the notion of function composition. All you're talking about here is having objects as properties of other objects - that is not function composition.

I'm not asking about function composition, I'm asking if there is any basis for disliking inheritance other than the fact that it is currently trendy to do so.

There’s something I’d like to clarify.

The article you are commenting on is about avoiding mixins in React components. It is not a general statement saying “Always use anything called ‘composition’ over anything called ‘inheritance’”.

We found that inheritance doesn’t work well for React components. And we found that composing React components with React’s composition model (which has very little to do with object composition) worked well for us.

Nowhere do we claim that object composition is better than object inheritance, or something else generic like this.

(Sorry if you didn’t interpret it this way. I just want to make it clear for future readers that this branch of discussion is not related to the contents of the article.)

Re: React: Mixins Considered Harmful

#187

Post by danabramov »

tlrobinson wrote: post #122
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(() => ({…

You don’t even need that syntax. (Please don’t use decorators in examples, they are not part of the language yet. This is super confusing.)

    function Foo(props) {
      return Hello {props.data.currentUser.username}!;
    }

    function getMeteorData() {
      return {
        currentUser: Meteor.user()
      };
    }

    export default createContainer(getMeteorData)(Foo)
Why do you see this as “lunacy” compared to mixins?

Re: React: Mixins Considered Harmful

#188

Post by danabramov »

_uhtu wrote: post #139

So there are a lot of features in React that are basically getting deprecated, like createClass in favor of ES6 components, mixins, etc. This is good that you guys are learning as you go, my question is will you ever release a version of React, possibly spin React off into a version which supports deprecated APIs and a version that doesn't and is therefore smaller, faster, and easier to maintain? Eventually you could…

We are not deprecating `createClass()` yet.

When we do, we will keep it for another major version (just like we always approached deprecations) and then move it to a separate package so only people who really want it would use it.

Re: React: Mixins Considered Harmful

#190

Post by danabramov »

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…

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

Why are you using a higher order function to `[].filter()` an array? It complicates the use case: iterating over items.

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

I don’t know what kind of apps you are building, but use cases for React at Facebook are very complex. You may create an Ads account and go through the ad campaign creation flow to see what I mean.

Post reply on HN