Trying to convert react-universally to use this now while I build up the routes manage

Hey <a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url=

[Discussion] Advanced use case,about ctrlplusb/react-async-component

Comments (29)

marella commented on September 10, 2024 1

Thanks. Working fine now in browser without any hacks.

from react-async-component.

bradennapier commented on September 10, 2024 1

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.

bradennapier commented on September 10, 2024 1

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.

bradennapier commented on September 10, 2024 1

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.

bradennapier commented on September 10, 2024

It does appear to be a problem that occurs the second HMR connects

from react-async-component.

ctrlplusb commented on September 10, 2024

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.

bradennapier commented on September 10, 2024

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.

bradennapier commented on September 10, 2024

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.

bradennapier commented on September 10, 2024

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.

ctrlplusb commented on September 10, 2024

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.

ctrlplusb commented on September 10, 2024

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.

bradennapier commented on September 10, 2024

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.

ctrlplusb commented on September 10, 2024

A few more bug fixes have landed @bradennapier - one that could have especially been affecting you regarding component id cycling.

from react-async-component.

bradennapier commented on September 10, 2024

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.

bradennapier commented on September 10, 2024

I added a log here to show when async runs

from react-async-component.

ctrlplusb commented on September 10, 2024

Any chance you could share a working model so I could try debug it for you?

from react-async-component.

ctrlplusb commented on September 10, 2024

Well, when I say "working" I mean an executing example that demonstrates the issue

from react-async-component.

bradennapier commented on September 10, 2024

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.

ctrlplusb commented on September 10, 2024

👌

from react-async-component.

marella commented on September 10, 2024

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.

ctrlplusb commented on September 10, 2024

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.

marella commented on September 10, 2024

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.

ctrlplusb commented on September 10, 2024

Is your React application a browser only app?

from react-async-component.

marella commented on September 10, 2024

Yes

from react-async-component.

ctrlplusb commented on September 10, 2024

A bug! New release is out. You were experiencing behaviour meant for server side execution only. Apologies.

from react-async-component.

bradennapier commented on September 10, 2024

This should fix mine as well? Nice!

from react-async-component.

ctrlplusb commented on September 10, 2024

Sorry about the confusion @bradennapier

from react-async-component.

ctrlplusb commented on September 10, 2024

Yep, for SSR this is expected/needed. I will update docs with reasoning around this.

from react-async-component.

ctrlplusb commented on September 10, 2024

Ok, closing this as we continue a more focused discussion on #9

from react-async-component.

[Discussion] Advanced use case about react-async-component HOT 29 CLOSED

Comments (29)

Related Issues (20)

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent