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

71–80 of 205 posts

Re: React: Mixins Considered Harmful

#71

Post by eiriklv »

coderzach wrote: post #53
thatswrong0 wrote: post #49

Earlier quoted context omitted.

I'm a fan of HOCs as well. My only problem with them is that I'm also a fan of shallow testing, and HOCs don't play nicely with shallow testing. I'm waiting on something like this ( https://github.com/airbnb/enzyme/issues/250 ) to get implemented

Why not just mock the HOC to be the identity fn? `(Component) => Component`

This is my preferred approach as well - and it (anecdotally) works great, since you can then just manually inject any props/spies as needed like any other "dumb" component.

Edit: But he might be pointing to the testing of the actual HOCs/component decorating functions.

Re: React: Mixins Considered Harmful

#72

Post by spicyj »

brlewis wrote: post #68
spicyj wrote: post #6

Earlier quoted context omitted.

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.

I bet React programmers who write a Mithril component or two would come back to React with more readiness to use component state. I don't have a plan for how you could use this idea to improve the community, though. As for the mentality of adding complexity -- are you sure that's a community problem? It seems a problem with programming in general. Advocates of adding complexity tend to be louder than advocates of usi…

I meant "community" as opposed to the official guidance we supply, where we try hard to keep things simple. I know that it's easy to slip into the trap of making things more complex and I don't blame anyone for that mentality winning out.

Re: React: Mixins Considered Harmful

#73

Post by spicyj »

wmccullough wrote: post #69

I'll likely catch some hell, but there's a reason mixins are considered an anti-pattern in most languages...

Yup, no news here. For people who already know that, this was designed as a post with specific examples that tend to pop up in React codebases and advice about how to migrate away from them.

Re: React: Mixins Considered Harmful

#74

Post by danabramov »

Cshelton wrote: post #52

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…

Thanks for saying this.

Re: React: Mixins Considered Harmful

#75

Post by gedy »

danabramov wrote: post #64
gedy wrote: post #54

Earlier quoted context omitted.

I think part of it is that not everyone is expert or familiar with functional programming (trained on OOP, etc) and it can feel overwhelming to many. "This is simpler - just another function" is somewhat subjective.

I believe this is exactly why we explain this pattern in the blog post in detail instead of just saying “this is simpler—just another function!” We are trying to both deliver a library that helps people ship quality apps, share our learnings about what worked, and what didn’t, and educate the community about the patterns that we found useful in our experience.

I agree, mainly addressing the general vibe that React is complex - many folks have a gut knowledge of imperative that they lean on to make snap judgements about complexity, even when you explain it fairly clearly.

Re: React: Mixins Considered Harmful

#76

Post by danabramov »

mrblueblue wrote: post #57
daliwali wrote: 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).

The "anti-pattern" patterns that you can use to build your React app are usually the "imperative escape hatches" the post is referring to. They are part of the framework to allow developers not familiar with functional and declarative ways of doing things to get stuff done I believe its part of the React team's long-term goal to educate framework adopters about the proper patterns and to slowly phase out these escape…

It is indeed a part of our strategy. We can’t just tell everyone to go functional. We are making mistakes and learning together with our users, and we are phasing our patterns when we are confident that the better patterns are accessible and we see that people can use them efficiently without extensive training.

Re: React: Mixins Considered Harmful

#77

Post by bcherny »

spicyj wrote: post #40
bcherny wrote: post #36

Implementing mixins correctly in JS (which React does not) is already a well explored problem space. I like https://leanpub.com/javascript-spessore for great explorations and derivations of various mixin patterns. It's not that mixins are bad in general, it's that React doesn't implement them well in particular.

Can you outline the biggest problems with React's mixins? I haven't heard this complaint before.

I'm sure you and @danabromov have more thoughts on this, but I would generally constrain the mixin system more:

- Don't let mixins call setState() directly; otherwise, it can be hard to track down what mutated the state. Have a well defined, canonical way to update state (proxy methods on the main component? Flux-style actions?)

- Don't let mixins define a render() method; this is the component's responsibility

- Separate mixin state from component state; mixins should not be able to see each others' state, and the component should not be able to see its mixins' state. Have a special API for a mixin to get its component's state (eg. this.getComponentState())

- Use vanilla ES6 mixins (class C extends mixin(A, B)) for interoperability with other libraries

Again, Spessore is a great exploration of how to implement these sorts of constraints.

Re: React: Mixins Considered Harmful

#78

Post by lopatin »

ThePhysicist wrote: post #43

The decorator-based approach sounds interesting, but (in my understanding) it will require moving the data fetching logic away from the main component into the decorator, which also creates a level of indirection that is intransparent to the component user, and I imagine stacking several of these decorators on top of each other should provide plenty of room for unforeseen side effects as well. Personally, I think alm…

Data declarations via decorators for use by some data fetching layer sounds like exactly what I want.

> creates a level of indirection that is intransparent to the component user, and I imagine stacking several of these decorators on top of each other should provide plenty of room for unforeseen side effects as well.

Unforseen side effects ... that sounds scary! Though vague. Imagine there is some controller component (a currency conversion widget) and we're adding a dependency on "/exchange_rates.json". If we could add a hypothetical @getJSON('/exchange_rates.json', 'rates') at the top of the component declaration to make sure the "rates" prop is always either missing (loading) or present (successfully returned data, or an error response), that sounds great. It only takes ownership of one prop. Stacking decorators would work nicely. Am I missing the glaring avenues for unforseen side effects?

Re: React: Mixins Considered Harmful

#79

Post by moogleii »

ThePhysicist wrote: post #55
danabramov wrote: post #48

Earlier quoted context omitted.

>it will require moving the data fetching logic away from the main component into the decorator We are not suggesting you to do anything like this. The article was about migrating from mixins to patterns like higher order components. If you do your data fetching right in the component, we are not suggesting you to change anything. It’s only mixins that we found problematic, and we are just sharing our experience migr…

Thanks for clarifying this! Maybe I misunderstood the example in the article that migrates the subscription logic from the component/mixin into the decorator. This was what made me question whether this will be more efficient/scalable than using the Mixin approach, as there is also some indirection here. Concerning the whole Redux issue: Yes, of course I can -and do- use React without it, but the problem is that ever…

> I find this problematic as it makes many components less portable, as they are bound to a given router / state loading paradigm.

Interesting, I find if you "reduxify" everything, even the top most component becomes somewhat dumb and agnostic. With react-redux, it won't even be aware of the dispatcher.

Re: React: Mixins Considered Harmful

#80

Post by daliwali »

danabramov wrote: post #60
daliwali wrote: post #35

Earlier quoted context omitted.

A corollary to what I'm saying is that the design patterns that are espoused by React authors can be eliminated by using another abstraction, they're specific to React and have nothing to do with programming in general. I wouldn't go so far as to say, never use mixins in JavaScript, for example. >You don’t “have to” do those optimizations. Sure, but it seems to be a trade off of complexity for user experience. It's j…

>they're specific to React and have nothing to do with programming in general Higher-order functions are extremely common and useful in all functional languages. In fact many people gave us the exact opposite feedback: React taught them many functional programming patterns that they later used elsewhere, both with and without JavaScript, not to say React. >I wouldn't go so far as to say, never use mixins in JavaScrip…

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

Post reply on HN