Comments (29)
Thanks. Working fine now in browser without any hacks.
from react-async-component.
It actually had its benefits. It allowed me to make sure my app was able to handle situations where for some reason parts of it had to re-render that wasn't expecting it 👍
from react-async-component.
Haha yeah it still double renders for me but I am guessing that is cause its SSR and its meant to do it that way?
from react-async-component.
Yeah I would imagine it has to do with being able to dive deeper into the tree and get the necessary DOM
from react-async-component.
It does appear to be a problem that occurs the second HMR connects
from react-async-component.
Hmmm, I have it working perfectly in a client implementation. I will try get it integrated into the next
branch or as a PR on react-universally
as soon as I can.
from react-async-component.
It would appear I should be expecting the app to have to render twice, right? walk tree seems to call and run all the components as it does it.
from react-async-component.
I figured out those errors were due to the app being rendered before the async call is made. I fixed the situation since my code didn't expect that and now it appears to startup but not sure if that caused any other issues. I see this in react-tree-walker:
// Call componentWillMount if it exists.
if (instance.componentWillMount) {
instance.componentWillMount();
}
from react-async-component.
Just figured I would provide what I am doing in full for better context and since you will recognize the boilerplate and know where I did everything:
In my server render:
// server/middleware/reactApplication/index.js
const app = (
<ServerRouter location={request.url} context={reactRouterContext}>
<Provider store={store}>
<App store={store} />
</Provider>
</ServerRouter>
);
// run helper on our app
withAsyncComponents(app)
.then(({ appWithAsyncComponents, state, STATE_IDENTIFIER }) => {
// We need to renderToString
const reactAppString = renderToString(appWithAsyncComponents);
// Generate the html response.
const html = generateHTML({
// Provide the rendered React applicaiton string.
reactAppString,
// Nonce which allows us to safely declare inline scripts.
nonce,
// Running this gets all the helmet properties (e.g. headers/scripts/title etc)
// that need to be included within our html. It's based on the rendered app.
// @see https://github.com/nfl/react-helmet
helmet: Helmet.rewind(),
// We provide our code split state so that it can be included within the
// html, and then the client bundle can use this data to know which chunks/
// modules need to be rehydrated prior to the application being rendered.
// ~~ DISABLED IN FAVOR OF ASYNC COMPONENTS MODULE
// codeSplitState: codeSplitContext.getState(),
// Provide the redux store state, this will be bound to the window.__APP_STATE__
// so that we can rehydrate the state on the client.
initialState: getState(),
asyncComponents: {
state,
STATE_IDENTIFIER,
}
// Pass through the react-jobs provided state so that it can be serialized
// into the HTML and then the browser can use the data to rehydrate the
// application appropriately.
// Disabling ReactJobs for now during setup
// jobsState: {
// state,
// STATE_IDENTIFIER,
// },
});
// generateHTML.js
...
${
// Bind our async components state so the client knows about them
asyncComponents
? inlineScript(`window.${asyncComponents.STATE_IDENTIFIER}=${serialize(asyncComponents.state)};`)
: ''
}
...
You have seen the client render method as originally posted...
Now I am trying to build a setup to automatically code split and render routes based on directory structure I use. I am fairly certain this should be setup properly.
// shared/app/routes.js
export default [
{
id: 'Home',
exactly: true,
props: {
title: 'Home'
},
pattern: '/',
component: () => import('./screens/Home')
},
{
id: 'SecurityCenter',
props: {
title: 'Security Center'
},
pattern: '/security-center',
component: () => import('./screens/SecurityCenter')
}
]
Where I will pass the "component" prop to createAsyncComponent
// shared/app/App (I believe in original boilerplate it was just index.js here
render() {
return (
<div>
{/*
All of the following will be injected into our page header.
@see https://github.com/nfl/react-helmet
*/}
<Helmet
htmlAttributes={safeConfigGet(['htmlPage', 'htmlAttributes'])}
titleTemplate={safeConfigGet(['htmlPage', 'titleTemplate'])}
defaultTitle={safeConfigGet(['htmlPage', 'defaultTitle'])}
meta={safeConfigGet(['htmlPage', 'meta'])}
link={safeConfigGet(['htmlPage', 'links'])}
script={safeConfigGet(['htmlPage', 'scripts'])}
/>
<Layers />
<Navbar />
{
routes.map( route => {
const matchProps = {
...route,
key: route.id || 'Unknown',
exactly: route.exactly == true,
pattern: route.pattern,
}
return <Match {...matchProps} render={ renderProps => {
const appProps = {
...matchProps,
...renderProps,
}
return (
<Body key={matchProps.key} {...matchProps.props}>
<AppMiddleware {...appProps} />
</Body>
)
}}
/>
})
}
<Miss component={Error404} />
<LayerStackMountPoint />
</div>
)
}
AppMiddleware is just a middle-man to connect to redux and render the async component
class AppMiddleware extends Component {
shouldComponentUpdate(np) {
if ( np.location.pathname !== this.props.location.pathname ) {
return true
}
console.info('App Middleware refuses to update', this.props, np)
return false
}
render() {
const { component, defer = false, props} = this.props
const Component = BuildAsyncComponent( component, defer )
return <Component {...props} />
}
}
const BuildAsyncComponent = (component, defer) =>
createAsyncComponent({
resolve: component,
defer
})
export default connect(
state => ({
page: pageSelector(state)
})
)(AppMiddleware)
With the intent that I would then asynchronously walk down "screens" in the folder structure with a similar structure to the above routes for children routes.
from react-async-component.
Hey @bradennapier
This sounds awesome! I don't have time to get into your details now, but I definitely want to go through it all as soon as I can.
FYI I pushed another release, it includes a fix for hot module reloading. It may have been impacting you.
https://github.com/ctrlplusb/react-async-component/releases/tag/0.1.2
from react-async-component.
Hey @bradennapier
I had a brief look at your code, key word "brief", but my gut tells me that you should consider creating the AsyncComponent instances within your routes definition.
// shared/app/routes.js
export default [
{
id: 'Home',
exactly: true,
props: {
title: 'Home'
},
pattern: '/',
component: createAsyncComponent({
resolve: () => import('./screens/Home')
})
},
{
id: 'SecurityCenter',
props: {
title: 'Security Center'
},
pattern: '/security-center',
component: createAsyncComponent(
resolve: () => import('./screens/SecurityCenter')
})
}
]
I don't know how well this helper will operate when being executed in the lifecycle methods of your components. This is because the helper tries to attach a determinable identifier to each async component instance so that I can try and track which ones have been resolved without using Babel/Webpack hacks.
Is your reasoning for using the AppMiddleware to create the instances because you wish to dynamically determine whether a route should be deferred or not?
from react-async-component.
EDIT: This got pretty long so sorry to take up so much of your time! If you don't have time to respond I understand, no worries!
I want to automate building of routes by building nested matching and resolving as we move deeper into the directory path.
I think I am fairly close at this point. Basically I want to walk through "screens" and build nested routes dynamically.
So in this directory structure I have "shared" which are saved components among all deeper-level components (they can reference anything in that folder as if it were a node_module).
Screens are for routes essentially, they will possibly nest deeper screens or an actual component:
So in the above "UserProjects" screen we are routing to it using /project
{
id: 'UserProjects',
props: {
title: 'Project Select'
},
pattern: '/project',
component: () => import('./screens/UserProjects')
}
Right now I have the /screens/UserProjects/index.js
look like this:
import React from 'react'
import Resolver from 'app/resolver'
const routes = [
{
id: 'ProjectSelect',
pattern: '/',
exactly: true,
component: () => import('./screens/ProjectSelect')
},
{
id: 'ProjectDashboard',
pattern: '/dashboard/:projectSlug',
component: () => import('./screens/ProjectDashboard')
}
]
export default props => (<Resolver {...props} routes={routes} />)
So this is then dynamically built and says that /project
should go to ./screens/ProjectSelect
while /project/dashboard/:projectSlug
should go to ./screens/ProjectDashboard/
.
I could then have the deeper paths return another <Resolver routes={routes} />
to build deeper paths within the directory itself. This allows my directory structure itself to define the routes without dealing with a huge match page that gets out of hand as the app grows.
Right now <Resolver ... />
looks like this:
import React, { Component, PropTypes } from 'react'
import { connect } from 'react-redux'
import { createAsyncComponent } from 'react-async-component'
import { Match, Miss } from 'react-router';
const RoutedResolver = ({ routes, ...props }) => (
<div>
{
routes.map( route => {
if ( ! route.id ) { throw new Error('Route Does not have an ID: ', route) }
const matchProps = {
...route,
key: route.id,
exactly: route.exactly == true,
pattern: route.pattern === '/'
? props.pathname
: props.pathname + route.pattern
}
return <Match {...matchProps} render={ renderProps => {
const appProps = {
...matchProps,
...renderProps,
}
return <Resolver {...props} {...appProps} />
}}
/>
})
}
</div>
)
const Loading = () => (<div>LOADING</div>)
const Resolver = ({ component, defer = false, routes, ...props }) => {
const Component = routes
? RoutedResolver
: component
? BuildAsyncComponent(component, defer)
: Loading
if ( routes ) { props.routes = routes }
return <Component {...props} />
}
export const BuildAsyncComponent = (component, defer) =>
createAsyncComponent({
resolve: component,
defer
})
export default Resolver
This does appear to work so far, I am sure there are some parts I will need to work on but my worry is how it ends up being handled by code splitting etc - especially when considering the nested routes end up requiring two imports, one for the route then another for the path.
The goal here is to determine within resolver whether we need to build new routes via <Match />
or if we should build the component using BuildAsyncComponent.
This becomes fairly ideal as it also outlines Smart vs Dumb very well. A "Smart" component will always be the final resolved Component and its dumb components will then be rendered from there within the components directory:
Sorry to write a book here, just trying to make sure the general concept laid out here isn't going to cause any major issue with how the resolving and handling of the async components work!
from react-async-component.
A few more bug fixes have landed @bradennapier - one that could have especially been affecting you regarding component id cycling.
from react-async-component.
FYI my app is sstill loading twice, even using vanilla configuration (Home Mounts is the Home route). It loads the entire application then asyncComponents destroys it and restarts it again
from react-async-component.
I added a log here to show when async runs
from react-async-component.
Any chance you could share a working model so I could try debug it for you?
from react-async-component.
Well, when I say "working" I mean an executing example that demonstrates the issue
from react-async-component.
Just invited you to the project, shouldn't be any top secret stuff there yet - just transferred it all over to the next branch etc
from react-async-component.
👌
from react-async-component.
I am facing similar issue when trying to use this library in an existing application (browser-side). componentWillMount()
is getting called twice. In below example App
is getting called twice - once before withAsyncComponents
callback and once after. I fixed it using a wrapper component and an extra variable but it is just a hack.
let readyToRender = false
const App = () => {
console.log('This will be printed twice')
if (!readyToRender) {
return null
}
console.log('This will be printed once')
return <MyApp />
}
withAsyncComponents(<App />)
.then(result => {
readyToRender = true
const { appWithAsyncComponents } = result
render(appWithAsyncComponents, document.getElementById('app'))
})
from react-async-component.
Ah, okay, I see now. This is by design. I'll update the docs to reflect why this occurs. It will be good to be aware of this moving forward.
What type of things are you doing in componentWillMount
? Prepping state?
from react-async-component.
Yes mainly network calls to fetch data. It is making same network calls twice. Is the solution I had the only workaround for this or is there a better way to handle this?
from react-async-component.
Is your React application a browser only app?
from react-async-component.
Yes
from react-async-component.
A bug! New release is out. You were experiencing behaviour meant for server side execution only. Apologies.
from react-async-component.
This should fix mine as well? Nice!
from react-async-component.
Sorry about the confusion @bradennapier
from react-async-component.
Yep, for SSR this is expected/needed. I will update docs with reasoning around this.
from react-async-component.
Ok, closing this as we continue a more focused discussion on #9
from react-async-component.
Related Issues (20)
- if more the one same async components are rendered in same page, only one will be rendered
- Chunk rendered in the server is requested in the client again HOT 1
- Need Help : How can I solve "System is not defined" HOT 5
- Error walking your react tree HOT 1
- No-match routes rendered during async loading HOT 1
- Combining with <link rel="prefetch" /> results in loading async components twice
- Upgrade to support react-async-bootstrapper 2
- App component rendered twice because of AsyncComponentProvider wrapper in RU
- Solved : Flashing LoadingComponent and render twice
- getErrors missing after migration to 2.0.0
- When used with react-hot-loader, async component gets stuck on the loader HOT 3
- Async component not rendering on directly open page
- Client error: Failed to resolve asyncComponent on Safari 11.1
- React.Children.only seems to fail on IE11 HOT 1
- Is it possible to load the async'd components from a custom URL? HOT 1
- Two same simultaneously async components HOT 5
- Informing about React.lazy() HOT 2
- Cannot read property 'helmetInstances' of undefined HOT 3
- migrate to New Context API
- Error async-component, state not reloaded after error
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from react-async-component.