react-router v4 && react-hot-loader@3 && Code Splitting#919
react-router v4 && react-hot-loader@3 && Code Splitting#919ZeroCho wants to merge 2 commits intoreactGo:masterfrom ZeroCho:master
Conversation
|
I'll do a fresh pull to night and check this out! <-- excited 😄 |
|
@ZeroCho Thanks for the ping! Very exciting, I will take a look at it as soon as I get some free time. Without having looked at it - does this PR do server-side rendering + code splitting with |
|
@GGAlanSmithee Yes. SSR + Code splitting with react-router@4 I haven't used redux-first-router |
|
@ZeroCho This is an excellent! I like the fact that we are no longer relying on react-router-redux any longer. Decoupling our navigation from redux was one of the aims I had in mind. I would like to spend some time this weekend playing around further with this branch in order to have an understanding of what's changed. Perhaps some modules can be split into more, mainly because they seemed to be doing too many things. But I would have to try it out in order to give a better comment! |
|
@choonkending Decoupling However, I like |
| "webpack-manifest-plugin": "^1.1.0" | ||
| "style-loader": "^0.18.2", | ||
| "url-loader": "^0.5.9", | ||
| "webpack": "^3.5.2", |
There was a problem hiding this comment.
Wow! @ZeroCho - You've also updated webpack. Bloody champion
|
So i've started to play around with it on my side and i'm getting I presume that this happens because of the promise there.. How would it be possible to disable the async component loading on the server side? Doesnt seem to be necessary anyway, no? Maybe with something like https://github.com/thejameskyle/react-loadable ? Edit
['import-inspector', { serverSideRequirePath: true, webpackRequireWeakId: true }]
const externalModules = fs.readdirSync('node_modules')
.filter(x => ['.bin'].indexOf(x) === -1 && x !== 'react-loadable' && x !== 'is-webpack-bundle' && x !== 'webpack-require-weak')
.reduce((acc, cur) => Object.assign(acc, { [cur]: 'commonjs ' + cur }), {});I still received the same error and then i stumbled upon jamiebuilds/react-loadable#54 . Tried to make the change on the local library and the error was gone 😄 . I now wonder when and if it will be merged or if there is a better solution. |
|
|
|
Been testing this a bit and it seems to be working fine, with the small aside mentioned by @slavab89. I definitely agree that code splitting on the server should be avoided if possible. I have no idea how to do this with
Care to elaborate on this? Not sure what you are reffering to exactly. |
|
@GGAlanSmithee Ah, I now got what @slavab89 meant. I had some misunderstanding. I think I can change some code of And about |
|
So i've just discovered something that might bring us the solution..? Did anyone of you heard about this? |
| const Dashboard = () => <div>Welcome to the Dasboard. Stay tuned...</div>; | ||
| class Dashboard extends Component { | ||
| componentWillMount() { | ||
| const { user: { authenticated }, history } = this.props; |
There was a problem hiding this comment.
Is it possible to couple this with route config as in rr3? Or is this the new way of protecting routes? If so, maybe this should be in it's own component (or HoC)? Usage would be like
<Protected redirect={'/login'}>
<MyComponent/>
</Protected>There was a problem hiding this comment.
Here is an example of a HOC doing this:
import {Component} from 'react'
import PropTypes from 'prop-types'
import {connect} from 'react-redux'
import {Redirect} from 'react-router'
const asProtected = (WrappedComponent, selectData) => {
class Protected extends Component {
static propTypes = {
user: PropTypes.object,
history: PropTypes.object
}
state = {
redirect: false
}
componentWillMount() {
const {user: {authenticated}} = this.props
if (!authenticated) {
this.setState({
redirect: true
})
}
}
render() {
if (this.state.redirect) {
const {history} = this.props
const location = {
pathname: '/login',
state: {
nextLocation: history.location
}
}
return (
<Redirect to={location}/>
)
}
return <WrappedComponent {...this.props}/>
}
}
const mapStateToProps = ({user}) => ({
user
})
return connect(
mapStateToProps
)(Protected)
}
export default asProtectedUsage:
import asProtected from 'hoc/asProtected'
const MyComp = () => (
<div>
Only for logged in users!
</div>
)
export default asProtected(MyComp)There was a problem hiding this comment.
This will always redirect to the login route., but could be changed to take the redirection path as an argument if needed I guess.
The original location (to the route which is protected) will be stored in the location.state.nextLocation object, so that it can be used to redirect after succesfull login.
| }; | ||
| } | ||
|
|
||
| export default [{ |
There was a problem hiding this comment.
a bit sad to see the jsx route trees go, was visually intuetive too me, but I guess that's the way the cookie crumbles.
|
Took a brief look at the code. Not too much to add unfortunatley, it looks fine too me. The only real issue discovered so far is the server-side code splitting if I understand it correctly? It might be inconveniant, but it's not really a bug. This PR seems like the way to go. |
|
Hey peeps, just an update, Ive been working on a branch inspired by @ZeroCho 's work here. It's still in WIP (lots to cover) master...choonkending:react-router-4-clean. I thought there might be a better way around our server side and client side data fetching, so I was experimenting around with that. Just to let you peeps know that I'm not ignoring this awesome PR! |
|
So i've recently tried to use https://github.com/faceyspacey/react-universal-component to achieve SSR + Code Split. I can say that its really easy to do it with it. Just follow their demo. What do you guys think? Or do we have some progress on this? |
|
@slavab89 I'm still on my spike branch based off this one master...choonkending:react-router-4-clean which I think has an acceptable solution to rr4, but without code splitting yet. I was thinking that could be tackled once we have a solution for this first! :D |
| <AppContainer> | ||
| <Provider store={store}> | ||
| <ConnectedRouter history={history}> | ||
| <PendingNavDataLoader routes={routes} store={store}> |
There was a problem hiding this comment.
should this be
<PendingNavDataLoader routes={r} store={store}>?
There was a problem hiding this comment.
Good catch. You're right
| }; | ||
| const presets = createPresets(enableHotModuleReplacement); | ||
|
|
||
| const presets = ['es2015', 'react', 'stage-0']; |
There was a problem hiding this comment.
should this be
const presets = [
['es2015', {modules: false}],
'react',
'stage-0'
]to allow for webpack dead code elimination?
There was a problem hiding this comment.
@GGAlanSmithee Does that work in client environment too?
There was a problem hiding this comment.
@ZeroCho I don't see why it shouldn't. The webpack bundling (and therefor code elimiation) happends at "compile" time, so it shouldn't matter in what environment the final code is used. Is there any specific reason that makes you think it wouldn't work in browsers?
There was a problem hiding this comment.
@GGAlanSmithee You're right. I checked out that it works in client too
@choonkending @slavab89