Support for React-Router 4

[sebmor]

Since it's somewhat officially released now, any plans for redux-connect to support it?

https://reacttraining.com/react-router/

[AVVS]

Well, I havent personally invested time in understanding the differences between v4 and v3, but so far it looks like routes would instead be simple components, hence there might be a need to revisit the whole thing on how we evaluate render tree and gather async props

[Rmannn]

I wrote a module that works with react router v4, but it's experimental.
https://github.com/Pop-Code/redux-async-load
Maybe this could help.

[AVVS]

@Rmannn thanks, though this requires us to render something 2 times. Its a huge blocking overhead I'd like to avoid at all costs possible.

[AVVS]

Once the bottom 2 repos are stable I assume we can actually integrate this module with the new react-router, since they can still match the routes before hand and if we can still do that - then we can still prefetch data

[harmonyjs]

Any updates?
These packages are quite stable and already ready for use, IMO

[AVVS]

I think I'd have time to investigate router version 4 futher soon, but if any1 wants to budge in with some help before that happens - let me know

[oyeanuj]

@AVVS Just checking to see if you've had a chance to look at RR4 to update this package?

[AVVS]

I did, but it still doesnt support redirects and some of the other configuration features. It's definitely possible to integrate as there are examples & docs, but the solution would be incomplete, so I'm quite hesitant at this point to invest time in this as I personally can't use it in production on any of the projects I'm involved with, I'm revisiting this every few weeks though to see if there is any progress on that front

[finom]

@AVVS any news?

[AVVS]

no progress on their front for the modules in question, so no news here either

[andykais]

according to this stackoverflow post the way to accomplish redirects is through the history object within Router of 'react-router-dom'. Aka, createBrowserHistory(), then pass that instance to react-router AND redux-connect and then you can programatically do most routing things using the
const { push, replace, go, goBack, goForward } = history api

Its actually even simpler to get the history instance shown in this official example, you can pull history out of react-router-dom with withRouter function

does this satisfy all the requirements to start supporting v4?

[jchook]

Since this package is slow to adopt React Router 4.x, we just factored it out of our app.

It really wasn't too hard. Router 4.x plus redux-saga makes it trivial to preload data for your app in a uniform way at any level of the component tree. We just wrote a decorator to automatically inject a loading animation when this.props.loading === true.

[AVVS]

thats another way to do it, I'd suggest you make a README entry here for those who want react-router v4 support. For me it really drops down to hacks that are needed to make this work (even though it can certainly happen)

@jchook please do provide your solution here via a PR - it would be superb to give more options to people!

[jaraquistain]

@jchook does your implementation work on the server as well? Will it wait until all external async data is returned before sending a response?

[jchook]

@jaraquistain unfortunately it does not. We didn't need "universal" rendering support so we removed it during the refactor.

I can work on a README in my spare time for folks that don't need server-side rendering. Otherwise, I think @andykais is correct about withRouter, etc and that 4.x support should be feasible.

[AVVS]

thing is, whole purpose of this module is to do SSR, if you don’t need SSR - there is completely no use for this module, tbh

…

On Jul 17, 2017, at 12:47 PM, Wes Roberts ***@***.***> wrote: @jaraquistain <https://github.com/jaraquistain> unfortunately it does not. We didn't need universal support so we removed it during the refactor. I'll work on a README in my spare time for folks that don't need server-side rendering. Otherwise, I think @andykais <https://github.com/andykais> is correct about withRouter, etc and that 4.x support should be feasible. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#107 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABol0WOvhaR2T_Y6DBxmmed9ce3Um1TOks5sO7pIgaJpZM4L80I->.

[jaraquistain]

@AVVS That's precisely what @jchook is saying, correct? He removed this module entirely in favor of loading screens and browser rendering.

Either way, I'll keep checking here for progress as it seems like if the statements above are true then something should be feasible soon

[jchook]

Sorry for any confusion about that.

I'm trying to theorize a way to accomplish SSR in this way. Since 4.x allows routes nested deep within the component tree, the technique/implementation may need to change significantly, and I don't imagine it will be backwards compatible.

Here is an ignorant and likely oversimplified description of how I imagine it working:

1. decorator provides most of the functionality
   a. stores async promises in an array
   b. loading and error indicators/callbacks (for client-side rendering)
   c. connecting state to props as configured (when promise is resolved)
2. server.js awaits promises stored by initial render
3. then respond with final, pre-loaded HTML

[jchook]

Also, it looks like react-router is developing a package called react-router-config for 4.x that will (hopefully?) provide an official solution.

[AVVS]

yes, I’m waiting until its production ready to migrate this

…

On Jul 17, 2017, at 8:45 PM, Wes Roberts ***@***.***> wrote: Also, it looks like react-router is developing a package for 4.x that (hopefully?) will provide an official solution for static route analysis: https://github.com/reacttraining/react-router/tree/master/packages/react-router-config <https://github.com/reacttraining/react-router/tree/master/packages/react-router-config> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#107 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABol0f8GHio-nlx4YN12OWvqkaAMV1hhks5sPCpJgaJpZM4L80I->.

[adam-26]

I forked this project and modified it to support react-router v4, the API is completely different - so I'm not sure if it will be of interest, but given the changes in rr-v4 I don't think a migration could maintain the current API of this project.

Given the API change, i've renamed it react-router-dispatcher, its available on NPM. I'd be interested in any feedback.

[AVVS]

It would be great if you prepare a PR and we can review it & publish under new branch version and gradually switch over there, since there is a lot of demand for RR4!

[oyeanuj]

@AVVS Instead of waiting on react-router-config or making that a requirement, could we use something like React Tree-Walker instead to compute the data dependencies?

Unless of course, you think merging @adam-26 package is a better strategy.

[oyeanuj]

@AVVS Couple of more things -

1. It seems like a few libraries are now using react-router-config - do you think it makes sense to have it a next branch to have a solution and you can make it the stable branch once react-router-config goes out of beta?

2. Here is another strategy that I ran into someone using for async components with RR4, but could totally be useful for redux-connect: Upgrade to React@16 (next) ctrlplusb/react-universally#479 (comment)

[adam-26]

@oyeanuj, just so you are aware, the async components you mention above performs more than 1 render per-request when rendering server-side, it has to make a first pass of the render tree to determine the components to be rendered, then another pass to actually render the components. The first render is not a complete render. I don't know the exact performance hit, but probably not ideal if you're site receives a lot of traffic.

[oyeanuj]

@adam-26 Yes, totally. Infact, a little further below in that thread, the author of the comment does address that - ctrlplusb/react-universally#479 (comment). TLDR: His opinion is that as a discovery algorithm, it is not nearly as much as the render cost when they measured.

It seems like the alternatives would be to either just declare data dependencies on the top container or at a route level - in both of which cases, we lose a lot of flexibility. Like everything else, tradeoffs 😄

[sebmor]

Check also this package https://github.com/gabrielbull/react-router-server

Also this example repo of another implementation is also pretty cool, he used getInitialState similar to NextJS https://github.com/jaredpalmer/react-router-nextjs-like-data-fetching

[oyeanuj]

@AVVS Any thoughts based on this comment and below? Seems like there are a few different ways to explore - I'm curious to see which one feels more like the right path for you?

[AVVS]

react-router-config is definitely a must, then match the tree and walk using it. My main concern was handling redirects, and some other features I've tried tackling were not supported as well.

I'd be grateful if some1 can at least provide a set of tests to iterate upon and then I'd be able to adjust the code

[warrenc5]

Thought I'd share some of my experience here,

At first I thought I was insane to try to upgrade this module, but then I read the documentation about react and redux and used the chrome debugger to construct a working example of the async using v4 routing.

I'm sure it's super sub-optimal and lame but it did allowed me to port my app to r16.

Basically, I had to remove the RouterContext import/require from the components/AsyncConnect source code.

I also had to remove component from the props to route, because you can't have component and override render for ReduxAsyncConnect constructor or otherwise react will ignore render.

Using the debugger I could see how the connect would put a static reduxAsyncConnect map of keyed promises on the connected component.

And then when the <ReduxAsyncConnect> mounts it resolves all the static map promises and dispatches the promises thened result to redux on their key. ( Or something to that effect)

const Rac = ({component,...props})=>
    <ReduxAsyncConnect {... props}
        components={[component]} reloadOnPropsChange={reloadOnPropsChange}
        render={props=>React.createElement(component,props)}
    />

const AsyncRoute = ({component, ...props}) => (
    <Route {...props} render={props => <Rac component={component} {... props} />}/>
)

I further extended the routing to a static component route ... although my Login component is also MyComponent and rather than use a redux route dispatcher or a redirect in the componentDidCatch method I decided to do it with a v4 Redirect as the following shows.

export class RouteCatch extends MyComponent {
    render() {
        const {component:Component, ... rest} = this.props
        const isError = super.isError()
        return <Route {... rest} render={props => (
            isError?
               <Redirect to={{
                    pathname: ERROR,
                  }}/>
            : <Component {...props} />
            )}/>
    }
}

const Rac = ({component,...props})=>
    <ReduxAsyncConnect {... props}
        components={[component]} reloadOnPropsChange={reloadOnPropsChange}
        render={props=>(<RouteCatch component={component}/>)}
    />

const AsyncRoute = ({component, ...props}) => (
    <Route {...props} render={props => <Rac component={component} {... props} />}/>
)

And my use is

 <Route path={ERROR} component={Logout} pageTitle="Error"/>
                        <AsyncRoute exact path={LOGIN} component={Login} pageTitle="Sign In"/>
                        

Thanks for all your work and support with this module. It's clearly the easiest to use for the big win without heavy weight middleware.

[AVVS]

As promised quite a long time ago - #119, its WIP, but will handle most of the cases

[AVVS]

Closed in https://github.com/makeomatic/redux-connect/releases/tag/v7.0.0

[bertho-zero]

By switching from react-router 3 to 4, I dropped redux-connect to create my own component (https://github.com/bertho-zero/react-redux-universal-hot-example/blob/master/src/components/ReduxAsyncConnect/ReduxAsyncConnect.js), I'd like to go back to redux-connect now.

I find myself with something very similar but I added Nprogress to show the page loadings as on github or youtube, and I don't know how I could integrate that with redux-connect, maybe you could help me to return to redux-connect.

At home (L32 + L58):
https://github.com/bertho-zero/react-redux-universal-hot-example/blob/04489fb51dd994d182bad540fd92ef45b0e20671/src/components/ReduxAsyncConnect/ReduxAsyncConnect.js#L24-L60

Redux-connect:

redux-connect/modules/components/AsyncConnect.js

Lines 74 to 96 in cedd35b

	loadAsyncData(props) {
	const { store } = this.context;
	const loadResult = loadAsyncConnect({ ...props, store });
	this.setState({ previousLocation: this.props.location });
	// TODO: think of a better solution to a problem?
	this.loadDataCounter += 1;
	this.props.beginGlobalLoad();
	return (loadDataCounterOriginal => loadResult.then(() => {
	// We need to change propsToShow only if loadAsyncData that called this promise
	// is the last invocation of loadAsyncData method. Otherwise we can face a situation
	// when user is changing route several times and we finally show him route that has
	// loaded props last time and not the last called route
	if (this.loadDataCounter === loadDataCounterOriginal && this.mounted !== false) {
	this.setState({ previousLocation: null });
	}
	// TODO: investigate race conditions
	// do we need to call this if it's not last invocation?
	this.props.endGlobalLoad();
	}))(this.loadDataCounter);
	}