Skip to content

Bring the mixin back. #85

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
sterpe opened this issue Apr 18, 2016 · 8 comments
Closed

Bring the mixin back. #85

sterpe opened this issue Apr 18, 2016 · 8 comments

Comments

@sterpe
Copy link

sterpe commented Apr 18, 2016

Obviously, not everyone is using es6 class syntax with React, and I think as the README points out the discussion about how HOCs should work is not completely formalized. I just feel like the mixin was a better approach than wrapping another component in react-onclickoutside.

@Pomax
Copy link
Owner

Pomax commented Apr 18, 2016

I don't have to bring anything back, the old versions don't "go away", they're still all available through npm. This is a major version upgrade, because everything changed, so if you don't want that breaking change, don't install "the latest" version, but set up your package.json to explicitly use 4.x:

  "dependencies": {
    ...
    "react-onclickoutside": "4.x",
    ...
  }

And voila. Mixin.

But I'm not reintroducing it, Mixins are no longer part of React's recommendation, the Facebook team has deprecated a ton of them (if you liked the linked state mixin for instance, that's gone now... and I liked that mixin) and they're not bringing them back, so there is no value in pretending a mixin still makes sense for code that now targets React 15.

@Pomax Pomax closed this as completed Apr 18, 2016
@sterpe
Copy link
Author

sterpe commented Apr 18, 2016

No kidding. But still feel a little unilateral.

@Pomax
Copy link
Owner

Pomax commented Apr 18, 2016

I hear that, and you're absolutely right in that it is, but as a developer with a finite amount of time, I don't want to be maintaining code that was intended for versions of React that have all but been disavowed by the React team, so it's also my responsibility to make sure that at some point, support for legacy code stops, and for react-onclickoutside as a mixin that point is the new v5.

Having to move with the technology we chose to work with is a sometimes annoying consequence of the field we work (or play) in, and of all the ubiquitous projects I've seen so far, React moves super fast, they move through versions pretty rapidly, and older 0.12, 0.13 and 0.14 concepts, plugins and components have to keep up with those changes.

Of course, I also want to make sure things that worked for people yesterday keep working today, so I adhere to the semver standard, which npm honours; as long as new version doesn't break old versions, it's pushed as minor release, and npm will update it for you on an npm install, and when it --necessarily-- eventually does change so much it breaks backward compatibility, it's a major version release and npm will not update it for you unless you either do so yourself, or you had it (inadvisably) installed manually with a wildcard version like *. So, for those who cannot immediately upgrade (because you don't always have that luxury), you get to keep using code that worked before without any changes, whereas people who come into React today will get a component that's intended to be used with the version of React they start on.

@sterpe
Copy link
Author

sterpe commented Apr 18, 2016

Yeah, np. I think the other thing with React/Jest/etc is that they actually push out into open source way ahead of what they actually are internally using, I've been trying to stay back a bit of the bleeding edge on some of this.

I don't want to make it sound like I think you owe OSS community something, not my point, at all, just that I don't know how widespread ES6 Classes are being used in React applications generally, because mixins are so powerful, and with Classes they are totally unavailable, I suspect they are less in use than you I think. Fair enough, you have to write code to support your own use case first.

I got nailed on Semver because I did fresh install manually, and was like what?! ;)

@sterpe
Copy link
Author

sterpe commented Apr 19, 2016

Personal project, I might play with ES6 classes and React, but not for any type of professional application.

@Pomax
Copy link
Owner

Pomax commented Apr 19, 2016

The nice thing about ES6 is that uptake's getting pretty good. Node 4 has it waiting for you to enable it with the --harmony flag when you run node, and Node 5 simply runs in ES6 mode (which as a superset of ES5 means you usually don't even notice it has full ES6 support), and Firefox and Chrome already support pretty much everything in ES6 that is worth using today (IE is still working on landing most of ES6 in their IE Edge, so we're not quite at universal uptake yet).

I've held off moving to React 15 for a while, but it's been almost a month and a half and I'm only hearing good things about it, so it's time to make the switch. Not sure I'll use full ES6 classes quite yet, but even the basic ES6 syntax makes life a lot easier.

This is super nice, for instance:

var MyComponent = React.createClass({
  render() {
    return this.state.elements.map(e => <CustomThing {...e} onClick={this.handleClick} />);
  },
  handleClick(evt) {
    ...
  }
});

It's not full ES6, but it's a lot nicer than what the ES5 equivalent would be.

@sterpe
Copy link
Author

sterpe commented Apr 19, 2016

This is actually what we're doing. ES6 syntax, but not React classes. So
we still use React.createClass() and still get to use mixins, but for the
actual js syntax we are doing ES6 then via Babel to ES5.

We are also still running React 0.14. After a while, we just got tired of
chasing these guys every couple of months.

On Mon, Apr 18, 2016 at 5:22 PM, Mike Kamermans [email protected]
wrote:

The nice thing about ES6 is that uptake's getting pretty good. Node 4 has
it waiting for you to enable it with the --harmony flag when you run
node, and Node 5 simply runs in ES6 mode (which as a superset of ES5 means
you usually don't even notice it has full ES6 support), and Firefox and
Chrome already support pretty much everything in ES6 that is worth using
today (IE is still working on landing most of ES6 in their IE Edge, so
we're not quite at universal uptake yet).

I've held off moving to React 15 for a while, but it's been almost a month
and a half and I'm only hearing good things about it, so it's time to make
the switch. Not sure I'll use full ES6 classes quite yet, but even the
basic ES6 syntax makes life a lot easier.

This is super nice, for instance:

var MyComponent = React.createClass({
render() {
return this.state.elements.map(e => <CustomThing {...e} onClick={this.handleClick} />);
}
});


You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#85 (comment)

@Pomax
Copy link
Owner

Pomax commented Apr 19, 2016

It feels like with React, you're kind of stuck with "5 months of pretty awesome new stuff" and then a few weeks of porting to the new version. It can certainly get tiring! =)

And hopefully the next few releases of React can bring some clarity to the "official" way to do HOCs, too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants