Boatload of methods removed from State mixin

[etodanik]

So, in the latest commit to the State mixin, I can see that a boatload of functionality was stripped and moved here:
https://github.com/rackt/react-router/blob/master/modules/URLUtils.js

However, what I don't see is now a way of easily doing any of it in my components. Is there a way to reach this functionality? Or has it been removed with a vague assumption that nobody wants anything but isActive() from their State mixin?

[agundermann]

Not sure either. One reason for their removal could be that your route handlers get everything else injected as props anyway

• State.getRoutes() => props.branch
• State.getParams() => props.params
• State.getPathname() => props.location.pathname
• State.getQuery() => props.location.query
• State.getPath() => no equivalent but can be reconstructed with pathname and query

[etodanik]

Well, I'm not sure that's as useful. For instance - I have a <NavBar/> component that heavily depends on path. It feels kinda awkward injecting all the props into it.

Would have been way cleaner just having the State mixin.

[agundermann]

I have a component that heavily depends on path.

Well, if a component depends on something, passing it via props and being explicit about it is the cleanest way imo. I'm not objected to bringing back the old mixin methods though.

[jedwards1211]

+1 for bringing back the old mixin methods.

A workaround would be pretty easy; all one has to do is make the topmost route component put the pathnames, params, query, etc. obtained from URLUtils into the getChildContext() in some form, and make a replacement for the State mixin whose methods pull these values out of this.context.

[agilgur5]

Not sure if this is the reason for it, but mixins don't exist in ES6 style classes, just to keep in mind.

[mjackson]

We're generally trying to move away from mixins, so you'll have to use the props we pass to your route handler components instead. This will help users making the transition to ES6 classes (and possibly other usage paradigms, like pure functions) still be able to use the router.

[jedwards1211]

You mean you guys don't hope class mixins are incorporated into a future version of JS? I'm a little disappointed you'd give them up that easily. I did more than enough Java programming and debugging complex inheritance hierarchies, and I thought it was cool, until I got to JS and could use mixins. Besides, there are any number of alternative methods React could provide to mix methods into an ES6 class prototype.

[jedwards1211]

I've felt like React has served the community very well so far. If React takes away the convenience of things like the ReactMeteorData mixin I've been using, they'd better come up with a better alternative.

[jedwards1211]

I‘d rather see react-router take the approach that sebmarkhage (very active in the React project) advocates for them:

"However, I think we need to wait on this and not thrash this API since there is active work exploring what first-class mixins would look like in ES7+."

[gaearon]

I‘d rather see react-router take the approach that sebmarkhage (very active in the React project) advocates for them:

"However, I think we need to wait on this and not thrash this API since there is active work exploring what first-class mixins would look like in ES7+."

He said many things :-). Some things he said later:

To be clear, mixins is an escape hatch to work around reusability limitations in the system. It’s not idiomatic React.

Making composition easier is a higher priority than making arbitrary mixins work.

I’ll focus on making composition easier so we can get rid of mixins.

I wouldn't say mixins are the future for React, especially considering work in progress on components as pure functions. You can use the mixins if you like them, but libraries like React Router should provide a solution that works for everyone, and injecting props is the React component API.

[mjackson]

I'm a little disappointed you'd give them up that easily

To be clear, we are going to ship a 1.0 API that will use mixins, namely the Navigation and State mixins that are currently used in several of the examples. The majority of people are still writing React code that uses createClass (including the router) and we intend to support them. Also, many people who have used the router up to this point have used these mixins and we don't want to force everyone to change their entire codebase when we ship 1.0.

Having said that, all I'm saying here is that I don't want to introduce any more mixins because we'll be moving away from them post 1.0.

[gsdean]

To be clear, we are going to ship a 1.0 API that will use mixins, namely the Navigation and State mixins

Is this still the plan? if so, any idea when/where?

[taion]

What specifically did you want from that mixin?

[gsdean]

From State getPath, getQuery, etc. From Navigation transitionTo. Basically we are upgrading from 0.13, and without a drop in replacement, it's going to be difficult.

[taion]

Of course. Those are respectively context.location.pathname, context.location.query, and context.history.pushState (or just push, with a slightly different signature).

[gsdean]

Maybe I'm missing something. Are you saying that context should have those properties by default, or are you suggesting I implement getChildContext and provide them?

As far as I can tell, the this.context is empty by default...

[taion]

You need to use contextTypes to get context. See e.g. https://github.com/rackt/react-router/blob/73e6c85f427c48f90bae0bb0e9745b6b48536e2f/CHANGES.md#state-mixin, https://github.com/rackt/react-router/blob/f8bb8d9ef119ca53c78c7ed9ecc3cc9fe77d492b/docs/API.md#but-im-using-classes.

[gsdean]

I see. Thanks for the clarification. The comment We will probably provide a higher order component that will do this for you but haven't yet was leading me to believe that wasn't supported yet.

FWIW, i wrapped it up in a mixin that I can drop in. Seems to work well.

var LegacyStateMixin = {
    contextTypes: {
        location: React.PropTypes.object
    },
    getQuery: function () {
        return this.context.location.query;
    },
    getPath:function(){
        return this.context.location.pathname;
    }
};