Patterns for incremental adoption

[AlanFoster]

Hi there; When generating the superglue boilerplate for rails, this file is created by default:

    const appEl = document.getElementById("app")
    // ...
         root.render(
           <Application
             ..
           />
         )

Currently the implementation renders a single "app" on the page powered by superglue; the question is - are there any patterns or recommendations for handling incremental adoption in legacy applications? i.e. having maybe 2 or 3 smaller components that are still powered by superglue's single store, such as some smaller graph components, or different forms, that exist in independent locations within disparate locations in the DOM; i.e. multiple apps powered by the same state etc, or would this be considered an anti-pattern/hit edgecases with implementation details/assumptions? The end goal would of course be a single app, but interested in learning if there are any incremental adoption techniques. Thanks!

[jho406]

Great question! Yes there is, and its closely related to this: thoughtbot/superglue_rails#13 I also find myself not globally using superglue from the start. Its an experience that can be improved.

[jho406]

.e. having maybe 2 or 3 smaller components that are still powered by superglue's single store, such as some smaller graph components, or different forms, that exist in independent locations within disparate locations in the DOM

Let me give this more thought, I think it may be already possible using React portals with the tradeoff that SPA navigation would a bit wonky. To do this you'd create something like index.json.props like you normally would, add a full index.html.erb like you would with classic rails, and to sprinkle, you'd add an index.jsx component that mostly exists to React.createPortal to the dom nodes you define in index.html.erb

[AlanFoster]

React portals could be interesting and might solve the issue in a clean way! For now I've created a single instantiation of setupProps similar to the out of the box code that superglue provides

      const setupProps = setup({
        // The global var SUPERGLUE_INITIAL_PAGE_STATE is set by your erb
        // template, e.g., index.html.erb
        initialPage: initialPage,
        // The base url prefixed to all calls made by the `visit`
        // and `remote` thunks.
        baseUrl: location.origin,
        // The initial path of the page, e.g., /foobar
        path: location.pathname + location.search + location.hash,
        // Callback used to setup the store
        store,
        // Callback used to setup visit and remote
        buildVisitAndRemote,
        history: undefined,
        navigatorRef,
      });

Then in the dom content loaded event I've got the main 'view' component being rendered that changes based on the page visited, and the setup props are just passed in to the components individually:

      if (appEl && window.SUPERGLUE_INITIAL_PAGE_STATE) {
        const root = createRoot(appEl);

        root.render(
            <ApplicationMain
              setupProps={setupProps}
              store={store}
              navigatorRef={navigatorRef}
              // Mapping between the page identifier to page component
              mapping={pageIdentifierToPageComponent}
            />
        );
...

And then later the 'global' components like the headers components etc loading separately

...
        root.render(
            <ApplicationComponent
              setupProps={setupProps}
              store={store}
              Component={Header}
            />
      )
...

And then the wrapper for rendering the main view that changes based on the page we're on:

export function ApplicationMain({
                                  store,
                                  mapping,
                                  setupProps,
                                  navigatorRef,
                                  ...rest
                                }) {
  const {visit, remote, nextHistory, initialPageKey, ujs} = setupProps;

  return (
    <div onClick={ujs.onClick} onSubmit={ujs.onSubmit}>
      <Provider store={store}>
        <NavigationProvider
          ref={navigatorRef}
          visit={visit}
          remote={remote}
          mapping={mapping}
          history={nextHistory}
          initialPageKey={initialPageKey}
        />
      </Provider>
    </div>
  )
}

And then the global components

/**
 * A standalone component that can read from application state; it renders the same component, regardless
 * of the current page. i.e. useful for header style components etc.
 */
export function ApplicationComponent({
                                       store,
                                       setupProps,
                                       Component,
                                     }) {
  const {visit, remote, nextHistory, initialPageKey, ujs} = setupProps;
  // Regardless of the page, we want the same component rendered - such as a standalone global toolbar component etc
  const mapping = new Proxy({}, {
    get(_page) {
      return Component
    }
  })

  return (
    <div onClick={ujs.onClick} onSubmit={ujs.onSubmit}>
      <Provider store={store}>
        <NavigationProvider
          visit={visit}
          remote={remote}
          mapping={mapping}
          history={nextHistory}
          initialPageKey={initialPageKey}
        />
      </Provider>
    </div>
  )
}

At the minute my generic global components are static (i.e. don't change based on the page you've visited), and don't trigger navigation, so it might not be a full solution - but it's more than enough to cover an initial integration. Long-term though - React portals might be a much nicer approach 💯