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

81–90 of 205 posts

Re: React: Mixins Considered Harmful

#81

Post by eweise »

nathancahill wrote: post #19
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.

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

Re: React: Mixins Considered Harmful

#82

Post by mikegerwitz »

I'm not familiar with React's mixins, but I get the impression from the suggestion to use higher order functions that it doesn't allow overriding methods from other mixins. E.g. Scala's concept of stacking.

For those interested in the concept in JS, I implemented a full trait system in GNU ease.js designed around Scala's approach, with support for stackable traits. The system also supports protected/private properties and methods, which can also be taken advantage of in traits to provide public and protected APIs, and keep state encapsulated in traits. I don't have documentation available yet (soon), but I do have a great many test cases that demonstrate various aspects:

https://www.gnu.org/software/easejs/#traits https://www.gnu.org/software/easejs/news.html#d9b86c1

Hopefully others find this to be interesting even if they don't agree with ease.js itself.

Re: React: Mixins Considered Harmful

#83

Post by danabramov »

daliwali wrote: post #80
danabramov wrote: post #60

Earlier quoted context omitted.

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

>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-class thing indicates a deficiency. By this logic, functions are deficient in JavaScript because you can pass a function to [].map(), or Promises are deficient because you can resolve() a Promise to another Promise.

I think the opposite is true. The abstractions are more powerful when they afford building higher level abstractions on top of them. Obviously you shouldn’t overuse this, just like you shouldn’t overuse higher order functions, but it’s a nice property to have.

Re: React: Mixins Considered Harmful

#84

Post by mg74 »

thatswrong0 wrote: post #49
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'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

Export every component like this:

export class MyComponent extends React.Component { ... }

export default SomeHOC(MyComponent)

And in your test simply import the non-hoc version:

import { MyComponent } from './mycomponent'

Now the HOC won't get in the way of your testing.

Re: React: Mixins Considered Harmful

#85

Post by ThePhysicist »

danabramov wrote: post #58
ThePhysicist wrote: post #55

Earlier quoted context omitted.

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…

>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

Re: React: Mixins Considered Harmful

#86

Post by tptacek »

zuck9 wrote: post #61
danabramov wrote: post #3

Earlier quoted context omitted.

You can use React without Flux/Redux if that works well for you. The “mentality” is just people solving their own problems in a way that makes sense to them, and sharing those solutions. As noted in the blog post, higher order components are not a React feature. And it is not related to Flux or Redux. It is just a thing you can do with components, like you can do it with functions. We think HOCs are a useful pattern…

What I think OP refers to, is how there are so many different choices to do anything in the React ecosystem. It's cool that people share their work. But so many choices just cause decision fatigue. It's hard to have any kind of real-world usage from just React. You have to learn and use some kind of Flux, routing library, AJAX patterns for that Flux library, another library for and , etc. If you want server-side rend…

You really don't need to learn some Flux to solve problems with React. React works fine without Flux, or really any formal data layer; you can comfortably use it simply as a really nice view library.

I agree that people give up on React after tutorials that make them think about routing and Flux. It's a shame, because the core concept of React is incredibly simple, and anyone can pick it up in a couple hours.

Flux is a useful, experience-based contribution and I'm happy to have it as an option. But it's heavily cargo-culted.

Re: React: Mixins Considered Harmful

#87

Post by danabramov »

Double_Cast wrote: post #46

So uh, HOC's are basically monads. Right?

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

Re: React: Mixins Considered Harmful

#89

Post by iandanforth »

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.

Re: React: Mixins Considered Harmful

#90

Post by acemarke »

zuck9 wrote: post #61
danabramov wrote: post #3

Earlier quoted context omitted.

You can use React without Flux/Redux if that works well for you. The “mentality” is just people solving their own problems in a way that makes sense to them, and sharing those solutions. As noted in the blog post, higher order components are not a React feature. And it is not related to Flux or Redux. It is just a thing you can do with components, like you can do it with functions. We think HOCs are a useful pattern…

What I think OP refers to, is how there are so many different choices to do anything in the React ecosystem. It's cool that people share their work. But so many choices just cause decision fatigue. It's hard to have any kind of real-world usage from just React. You have to learn and use some kind of Flux, routing library, AJAX patterns for that Flux library, another library for and , etc. If you want server-side rend…

Uh... on the contrary, there's a bunch of fairly in-depth tutorials out there. I have a number of them listed at [0] and at [1]. Also, I think a couple of the more commercial courses do that sort of thing as well. Wes Bos's Redux course builds a "Reduxstagram" app or something, Tyler McGinnis's "React.js Program" course builds up a couple specific apps, etc.

[0] https://github.com/markerikson/react-redux-links/blob/master...

[1] https://github.com/markerikson/react-redux-links/blob/master...

Post reply on HN