React: Mixins Considered Harmful • Hacker News Board

Re: React: Mixins Considered Harmful

#201

Post by lcarlson » Fri, Jul 15, 2016, 3:30 AM UTC

danabramov wrote: post #97

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…

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

What are your thoughts on just simple es6 classes and mvc? View=React, c=es6 class, m=immutable js. I use page.js for my router and call it a day.

Re: React: Mixins Considered Harmful

#202

Post by kerkeslager » Sat, Jul 16, 2016, 4:01 AM UTC

methyl wrote: post #172

kerkeslager wrote: post #123

Earlier quoted context omitted.

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

My observation is that going with local state is going to bite you sooner than later and in most cases having it in Redux Store from beginning is a good idea.

This has not been my experience. I wrote a good amount of React before introducing any Flux at all, and I've been bitten far more by my mistakes where I added things to stores unnecessarily than I have been by cases where I kept things in component state. Your experience might be different from mine.

It's my impression that a lot of people are coming from a Angular or Ember-ish background where they're building what amounts to single-page web applications. I'm building multi-page apps that have heavier-lifting back-ends, and React fills the space of building components that can be composed and embedded in the page.

When you're building a single-page app, stores make a great deal of sense. But when you're embadding components in a page, it doesn't make sense to use stores. Not only do I not want to have my components interact, I want to actively avoid having them interact, because that coupling would make the components non-reusable. So tying them to a global state presents serious issues for that model.

It occurs to me that this might account for our difference in perception of the importance of stores.

P.S. It's also worth noting that moving state out of a component and into a store is fairly painless. The reverse is not true; moving state out of a store and into component state is an extremely painful and error-prone process. So it makes sense to start with component state and move things into stores only as needed.

Re: React: Mixins Considered Harmful

#203

Post by johncip » Sun, Jul 17, 2016, 8:02 AM UTC

danabramov wrote: post #179

johncip wrote: post #130

Earlier quoted context omitted.

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?

String refs are bad in quite a few ways: 1. String refs are not composable. A wrapping component can’t “snoop” on a ref to a child if it already has an existing string ref. On the other hand, callback refs don’t have a single owner, so you can always compose them. 2. String refs don’t work with static analysis like Flow. Flow can’t guess the magic that framework does to make the string ref “appear” on `this.refs`, as…

Thanks for the thorough answer, Dan.

(Had I not followed the prescription for the sake of being future-proof, I probably would have had a painful debugging session over #3. And possibly #1 too.)

Re: React: Mixins Considered Harmful

#204

Post by developit » Mon, Jul 18, 2016, 2:20 PM UTC

danabramov wrote: post #179

johncip wrote: post #130

Earlier quoted context omitted.

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?

String refs are bad in quite a few ways: 1. String refs are not composable. A wrapping component can’t “snoop” on a ref to a child if it already has an existing string ref. On the other hand, callback refs don’t have a single owner, so you can always compose them. 2. String refs don’t work with static analysis like Flow. Flow can’t guess the magic that framework does to make the string ref “appear” on `this.refs`, as…

I think it's important people understand this. The last two points are precisely the reason String refs got moved from Preact's core into preact-compat.

Also, for the common-case usage of string refs, you can just use a helper to insert things into `this.refs`:

https://gist.github.com/developit/63e7a81a507c368f7fc0898076...

Re: React: Mixins Considered Harmful

#205

Post by udarkness » Tue, Jul 19, 2016, 11:04 AM UTC

Seems to be that the harmful part of the code is actually the OOP. The solution they provide is not a direct attack vs mixins (composition, multiple inheritance), instead they propose to use functions instead of methods but keeping the root of the problems (methods), they may notice in the future that the classes will bring the same issues (the parent can also have a method with the same name...). Notice that the key solution is to use functions (pure, deterministic). While react is a good improvement to remove states, it still promotes objects that are still holding states. I hope they can get more advise from their haxl team :)