Forem: Marais Rossouw

Don't Put Your Data In React

Marais Rossouw — Sun, 14 Aug 2022 13:00:29 +0000

We've all got applications with views. You know, views, the macro components we use to compose together to build our pages. These pages then tie in with our routes to build our applications.

This post will walk you through creating something that resembles Relay EntryPoints, what that means for these views. And how it's not really a story about user interfaces, but a story about where your data lives.

Enter EntryPoint's

We have a layout of views, a collection we love to call pages. But let's think for a moment, what is that really?

In React we like to think we are composing components, you know, the thing you put inside off another thing¹. So let's riff of that for a second.

We can see we have something that looks like GitHub:

the global nav, persistent across multiple pages
the project header, persistent across multiple project tabs
the code tab, or the "main content"

All views or components that when composed together build up the repository page. Our page composed all those together into a single root node we're going to call the RepositoryView.

Before terminology gets out of hand, let's instead refer to it as "composing layouts of entry points".

So our entry point here would be the page itself, the RepositoryViewEntryPoint, a ProjectHeaderEntryPoint and of course the main content as well.

All these things are the building blocks of our application — an "entry point" into a piece of code (its view) and it's data.

Let's unpack what Entry Points are, and come full circle towards the end as we build GitHub.

EntryPoints are type-safe

Before we get into how Relay handles this, let's build our own! 😅

There is really 3 parts that go into making an entry point.

the type definition of what an entry point even is
a component
and an entry point code to that component

// 1. the type definition
type EntryPoint<Props> = {
    component: ComponentType<Props>,
    props: Props
};

// 2. the component
type Props = { user: { name: string } };
const Howdy: SFC<Props> = ({ user }) => (
    <div>Hello {user.name}</div>
);

// 3. the entry point 
const HowdyEntryPoint: EntryPoint<Props> = {
    component: Howdy,
    props: { user: { name: 'Mona' } },
};

... and now you think I've completely lost it! 😅 "You've just put the components props next to something that already defines it" ... but bare with me.

What we've done here is, we've established a container creating a type-safe dependency between the component and it's data.

Don't let me understate that, one of the powerful aspects of components especially with the help of Flow and TypeScript is the ability to define component prop types. So as we venture into this notion of "Don't Put Data in React", we need to retain this type-safe aspect.

If the component requires a new set of data requirements, since we've established this type-safe dependency between them, you won't forget to also give those new data to the component — your type-checker will have a whinge.

But how have we moved the data out of React? Really in the literal sense: <Howdy user={{ name: 'mona' }} />, has the { name: 'mona' } as data declare in-react. So we've moved the data alongside a reference to the component, in the form of a joining object, the EntryPoint.

Great! Let's render this to the screen, which would happens as you'd might expect:

const EntryPointContainer: SFC<{ entrypoint: EntryPoint<unknown> }> = ({
    entrypoint: {
        component: Component,
        props,
    },
}) => (
    <Component {...props} />
);

<EntryPointContainer entrypoint={HowdyEntryPoint} />

The EntryPointContainer here takes a reference to an entry point, and wires ups the props and renders.

EntryPoints describe the data dependency

Now! Wouldn't the world be wonderful if all we ever had was static data. If we did, the post would stop here 😂! Instead we live in a world where our data lives in remote places, databases, apis, your great aunts show box.

So let's reframe our mindset a little, instead of asking "what data goes with this component" lets ask "what query do I run to get the data for this component".

An entry point describes the data dependency.

Well, what does it mean to describe?

to give a report of how something is done — Cambridge

Notice how it's "how something is done", not "what the something is".

In terms of software, how do we describe how data is done, or fetched? Through a function perhaps? A function describes how data is resolved, not it's result.

Let's describe the data dependency and change our example to reflect this:

type EntryPoint<Variables, Props> = {
    component: ComponentType<Props>,
    fetch: (variables: Variables) => Promise<Props>,
    variables: Variables
};

const HowdyEntryPoint: EntryPoint<{ userId: string }, Props> = {
    component: Howdy,
    fetch(variables) {
        return fetchGraphql(graphql`query($id: ID) { user(id: $id) { name }}`);
    },
    variables: { userId: 2 },
};

Instead of passing the props we had statically before. We define a describing function on how to resolve the data, in our case by calling some api. As most functions do, they can accept some input to make it configurable, let's expose that by way of variables.

For the purposes of this post, use your imagination as to where to get those variables from, but could be something like useParams from your favourite routing library.

Our EntryPointContainer component also needs to be altered a little to handle this new fetch and variables properties.

const EntryPointContainer: SFC<{ entrypoint: EntryPoint<unknown, unknown> }> = ({
    entrypoint: {
        component: Component,
        fetch: fetchQuery,
        variables,
    },
}) => {
    const [props, setProps] = useState(null);

    useEffect(() => {
        fetchQuery(variables)
            .then(props => {
                setProps(props);
            });
    }, [fetch, variables]);

    if (props === null) return null;

    return <Component {...props} />;
};

Simple stuff, a useEffect² to call our fetch function and only rendering the Component once that data comes back.

... and the usage stays the same!

<EntryPointContainer entrypoint={HowdyEntryPoint} />

We can actually go one step further. We all use GraphQL around these parts. So instead of passing a fetch function, let's describe the data by way of a GraphQL query 🦸‍♂️.

type EntryPoint<Variables, Props> = {
    component: ComponentType<Props>,
    query: string,
    variables: Variables
};

const HowdyEntryPoint: EntryPoint<{ userId: string }, Props> = {
    component: () => import('./howdy'),
    query: /* GraphQL */`query($id: ID) { user(id: $id) { name }}`,
    variables: { userId: 2 },
};

Necessary encapsulation

What we did just then was describe the data dependency as something high-level, a GraphQL query. Which I cannot overstate as quite pivotal moment in our understanding of entry points.

We've moved the platform layer, the fetch function into a describing factor, leaving our platform engineers free to enact that fetch logic in our behalf, and at their pace.

I said before "a function describes how data is resolved, not it's result", but the problem with functions is they are heavy — often coupled to some network layer, so carries too much definition.

EntryPoints describe the ui dependency

Great! Our entry points can now mount and data is described.

But hang on... We've still got a synchronous bundle of the code. There is probably an entire article for this moment entirely.

If we continue down this notion of entry points being describing containers, we need to describe our component then as well — it's still the data not describing the data.

So let's fix that...

And what better way to do this than with our trusty esm import functions.

type EntryPoint<Variables, Props> = {
    component: () => Promise<ComponentType<Props>>,
    query: string,
    variables: Variables
};

const EntryPointContainer: SFC<{ entrypoint: EntryPoint<unknown, unknown> }> = ({
    entrypoint: {
        component,
        query,
        variables,
    },
}) => {
    const [props, setProps] = useState(null);
    const [Component, setComponent] = useState(null);

    useEffect(() => {
        fetchQuery(query, variables)
            .then(props => {
                setProps(props);
            });
    }, [query, variables]);

    useEffect(() => {
        component()
            .then(Component => {
                setComponent(Component);
            });
    }, [component]);

    if (props === null || Component === null) return null;

    return <Component {...props} />;
};

... the component and the data is both split away, creating a thin json serialisable³ definition of how to paint this entry point 🦄.

Need to quickly fix our HowdyEntryPoint to use these new properties:

const HowdyEntryPoint: EntryPoint<{ userId: string }, Props> = {
    component: () => import('./howdy'),
    query: /* GraphQL */`query($id: ID) { user(id: $id) { name }}`,
    variables: { userId: 2 },
};

... and it all still renders the same!

✨ You've made it! Congratulations 🎉, you have built Relay Entry Points!

We've taken what was "code" into what is now a "description"!

There's just one thing... Great! We've moved the data out of React and how, but why?

Why data doesn't belong in React

If we switch gears to looking at this question from the point of view of a server needing to prepare the data required for a page.

If all the data was in-react (noting it's not static as mentioned before), how would it know what data to go and prepare? We'd need to render the entire React tree to discover these things, which is quite a costly endeavour.

There's an entire article on this topic, and how routing might work. But to help me with this article, let's just say routes point to entry points. So when the server receives a request for a route, we can look at all our entry points, grab the one that matched.

So we have static/instant access to the data requirements — and how to get it.

That's it, that's why! Gee Marais, took you long enough!

Let's continue looking at how we can solve this. The clever ones might have realised, our application topology originally described global navs, main contents, project headers etc.. If those are all "Entry Points" we composed.

We'd get some pretty nasty waterfall loadings 😭, so let's fix that!

EntryPoints describe the rendering and loading

We're getting into the weeds now with respects to resource loading, and Suspense have a gander probably firstly. Super tl;dr — suspense is a way for React to handle promises for us.

In the first example we had our data right there available, 👋 mona. All we needed was { props: { data } }, and done. Now we've got this intermediate loading state, api shenanigans to deal with.

Wouldn't it be nice if we could take our definitions of entry points, and frame them back into a form where the data was static.

Let's try!

What immediately comes to mind is loading the data before we render:

// Something suspensey
type PreloadedEntryPoint<Data> = { ... };

const loadEntryPoint = <Variables, Props>(
    entrypoint: EntryPoint<Variables, Props>,
    variables: Variables,
): Promise<PreloadedEntryPoint<Props>> => { ... };

const EntryPointContainer: SFC<{ entrypoint: PreloadedEntryPoint<unknown> }> = ({
    entrypoint,
}) => {
    const { Component, props } = entrypoint.read(); // suspends

    return <Component {...props} />;
};

loadEntryPoint(HowdyEntryPoint)
    .then(entrypoint => {
        ReactDOM.render(<EntryPointContainer entrypoint={entrypoint} />);
    });

Much like our type-safe dependency we created with our Entry Point. We've created another layer of type-safety, joining an in-flight or preloaded type-safe container of the data to the entry point. This ensures we are passing around right preloaded data to the right component.

Now, you're thinking. We have to be explicitly be passing around these preloaded data containers, and wondering why.

It's actually a really good thing. If it quack like a duck, swims like a duck then call it a duck. It makes it quite clear who needs it, whose using it and of course when nobody uses anymore, it's safe to delete.

Our component doesn't need the definition of the data, it needs the data itself! So from the components point of view it effetely voices "hey I need this preloaded data", which answers the "who needs it" question.

The "who is using it" question, is tracked by way of passing that into the EntryPointContainer component. We're not going to get into Relay's concept of reference counting, but the idea is when the preloaded data is no longer used, we can omit this from our memory. Because it's safe to do. For if we need it again, we know how to get it again.

... and bam! You've achieved the Relay definition of entry points.

Let's see one, and build GitHub!

EntryPoints build GitHub⁴

As much as we loved our Howdy component, let's define something real like you'd expect to see.

ProjectHeader

const ProjectHeader: SFC<{
    queries: {
        queryRef: PreloadedQuery<typeof ProjectHeaderQuery>
    }
}> = ({ queries }) => {
    const data = usePreloadedQuery(graphql`query ProjectHeaderQuery($owner: String, $repo: String) {
        repository(owner: $owner, name: $repo) {
            owner
            name
            stars
        }
    }`, queries.queryRef);

    return <div>
        <h1>{data.repository.owner}/{data.repository.name}</h1>
        <button>Stars {data.repository.stars}</button>
    </div>;
};

const ProjectHeaderEntryPoint: EntryPoint<{
    owner: string,
    repo: string
}> = {
    root: JSResource('ProjectHeader'),
    getPreloadedProps(params) {
        return {
            queries: {
                queryRef: {
                    parameters: ProjectHeaderQuery,
                    variables: {
                        owner: params.owner,
                        user: params.repo,
                    },
                },
            },
        };
    },
};

RepositoryView

const RepositoryView: SFC<{
    queries: {
        queryRef: PreloadedQuery<typeof RepositoryViewQuery>
    },
    entryPoints: {
        projectHeader: typeof ProjectHeaderPoint
    }
}> = ({ queries, entrypoints }) => {
    const data = usePreloadedQuery(graphql`query RepositoryViewQuery($owner: String, $repo: String) {
        repository(owner: $owner, name: $repo) {
            readme {
                html
            }
        }
    }`, queries.queryRef);

    return <div>
        <EntryPointContainer entrypoint={entrypoints.projectHeader}/>

        <div>
            <h2>Readme</h2>
            <div dangerouslySetInnerHTML={{ __html: data.repository.readme.html }}/>
        </div>
    </div>;
};

const RepositoryViewEntryPoint: EntryPoint<{
    owner: string,
    repo: string
}> = {
    root: JSResource('RepositoryView'),
    getPreloadedProps(params) {
        return {
            queries: {
                queryRef: {
                    parameters: RepositoryViewQuery,
                    variables: {
                        owner: params.owner,
                        user: params.repo,
                    },
                },
            },
            entryPoints: {
                projectHeader: ProjectHeaderEntryPoint,
            },
        };
    },
};

Have a read of those, but our app would compose them into something like this:

Please don't crucify me, please do handle errors, edge cases, etc.. It's pseudo code at best.

let routes = {
    '/:owner/:repo': RepositoryViewEntryPoint,
};

const matchRoute = (url: string) => routes[url];

const initialPage = loadEntryPoint(matchRoute(location.href));

const App = () => {
    const { entrypoint, setEntryPoint } = useState(initialPage);

    useEffect(() => {
        // Please use something like https://github.com/lukeed/navaid
        window.addEventListener('pushstate', () => {
            setEntryPoint(matchRoute(location.href));
        });
    }, []);

    return <Suspense fallback={null}>
        <EntryPointContainer entrypoint={entrypoint}/>
    </Suspense>;
};

Wowzers! EntryPoints can compose other EntryPoints!!?!?!

Our project header is composed by the repository view (or page or layout), similar to the Outlet concept.

Relay when that top level EntryPoint is loadEntrypointed, will recursively call the getPreloadedProps, and all the data and code fetchers will all run in parallel.

Modals

... or really anything behind a user interaction — is an EntryPoint.

Seeing as the "building block" is described as an entry point we can preload, or deferred load this behind user interaction.

Like say the GitHub "code fly out", the fly out there requires — the users codespaces, the ssh or html preference, and potentially all sorts of other ui and data, which is not required for the critical load.

We can then declare this as an EntryPoint like so:

const CodeFlyout: SFC<{
    queries: {
        queryRef: PreloadedQuery<typeof CodeFlyoutQuery>
    }
}> = ({ queries }) => {
    const data = usePreloadedQuery(graphql`query CodeFlyoutQuery($owner: String, $repo: String) {
        repository(owner: $owner, name: $repo) {
            url {
                ssh
                https
            }

            codespaces {
                name
                url
            }
        }

        viewer {
            cloning_preference
        }
    }`, queries.queryRef);

    return (<div>
        <Tabs active={data.viewer.cloning_preference}>
            <Item name="ssh">
                <pre>{data.repository.url.ssh}</pre>
            </Item>
            <Item name="https">
                <pre>{data.repository.url.https}</pre>
            </Item>
        </Tabs>

        <p>Codespaces is awesome, you should use it</p>
        {data.repository.codespaces.map(item => (
            <a href={item.url}>Open codespace {item.name}</a>
        ))}
    </div>);
};

const CodeFlyoutEntryPoint: EntryPoint<{
    owner: string,
    repo: string
}> = {
    root: JSResource('CodeFlyout'),
    getPreloadedProps(params) {
        return {
            queries: {
                queryRef: {
                    parameters: CodeFlyoutQuery,
                    variables: {
                        owner: params.owner,
                        user: params.repo,
                    },
                },
            },
        };
    },
};

const RepositoryView = () => {
    return (<div>
        { /* all the other stuff from above */}

        <FlyoutTrigger entrypoint={CodeFlyoutEntryPoint}>
            {({ onClick }) =>
                (<button onClick={onClick}>Code</button>)
            }
        </FlyoutTrigger>
    </div>);
};

Just wonderful, we've declaratively composed what our page needs, its all feeling great from a UX point of view. The bits that sit behind user interaction are code-split and everything is great! And best of all, its type-safe through and through!!!

But really skies the limit now in how you use it!

you could preload the entry point on hover
you could intersection observer to check that all visible ModalTrigers have their entry points preloaded

EntryPoints can protect your routes

Note that routes object above can come from a window object, incrementally hydrated from an api or whatever — its just json.

A side moment, and something important ☝️.

To handle permissions, read access, and discoverability of routes. You may not want to flush your entire entry point map to the client. But instead before a navigation to a route occurs, you ask the server for the entry point json - or not return anything for like a 404.

You could do something like:

useEffect(() => {
    window.addEventListener('pushstate', () => {
        const target = location.href;
        fetch(`/routes?to=${target}`)
            .then(route => {
                if (route) {
                    Object.assign(routes, route);
                    setEntryPoint(matchRoute(target));
                } else {
                    setEntryPoint(matchRoute('404'));
                }
            });
    });
}, []);

... please write something better than that, but the idea is. Either on hover, or on click — first ask your well protected backend what the entry point is to power that route.

If it returns nothing, then 404. If it returns, go for it. Meaning all the "this user can access it" etc can all be surfaced hiding all the usual, "the route exists but the user can't see it" security risks.

Think like a private repo, if the entry point exists, and was attempted, then maybe you can use that to try other things.

Summary

Let's quickly recap what we've achieved and make sure you've grasped the main points.

entry points are thin json serializable definitions of, what code to run, and the data that code may need.
entry points describe the data dependency, not the data itself.
entry points describe the code dependency.
entry points are type-safe and statically analysable.
entry points are loaded and handled outside the react life cycle.
entry points should wrap things that sit behind user interaction, route transitions are behind user interaction.

What is `JSResource`?

Quite simply just function that returns a suspenseful wrapper around a promise. Remember before when I said entry points are json serialisable, well this is how. JSResource under the hood, would be going import('./components/${name}'). Or however you wish to resolve it.

Sample implementation 👉 npm jsr

Thanks

Special thanks to Tom Gasson for article inspiration ❤️

Cover photo by Ivan Aleksic

Follow me on twitter ~> @slightlycode

No not the John Cleese Royal Society For Putting Things On Top of Other Things because that would be rather silly. ↩
Don't use this in production for reasons, and for things error boundaries, loading states and so forth. ↩
Just need to move our async import into a string that is looked-up/fetched similar to how the query is. JSResource will be your friend. ↩
None of this is actually how GitHub is built, nor endorsed or sponsored by them. ↩

Scene Based Applications

Marais Rossouw — Mon, 09 Nov 2020 04:05:13 +0000

Recently I've found myself building lots of small microsites with 2, maybe 3 routes and I seem to struggle with how do I layout my files? I want my site to be able to grow, be resilient to change and ultimately know where to go looking for things. I also leverage the Module Federation technology, which mean's often areas of my route, or sometimes entire routes aren't actually part of that file tree.

And because of this, I introduce you to:

The "scene" pattern! A scene is single page instance, the "macro" component for a route if you will. Within the screenwriting industry, a scene is described as a narrative device, where the film is the story. Scenes are mini-stories that occur within that film. Similarly, a scene is a mini-story as part of the greater app.

What does this look like?

src/
├── scenes/
|   ├── homepage/
|   |   ├── Homepage.tsx
|   |   └── SupportingFile.tsx
|   └── product/
|       ├── ProductPage.tsx
|       └── Product.tsx
└── routes/
    ├── index.tsx
    └── product/
        └── $product.tsx

From that you can see that I have now clearly exported the page component for the route, leaving me to seamlessly change, alter or move my routes. Allowing me compose my scenes freely, and without an awareness of where (or what route) that scene might render.

Scenes don't compose other scenes. Scenes compose components that you may share.

In worlds such as Next or Remix that leverage file-based routing, often times all files in that sub tree will in-tern render a route. Which often leads to some large files with all the supporting components in them, or some circular dependencies because you have routes importing parts of another route and so on.

Photo by 丁亦然 on Unsplash

@fetchable with Relay

Marais Rossouw — Thu, 05 Nov 2020 01:00:26 +0000

How can I use Relay, but my backend doesn't support the Node interface? Great question, see like many companies or individuals out there wanting to leverage the power that comes with Relay, but soon realize that some of it's features cannot be used such as usePaginationFragment or @refetchable.

For a long time we Relay had introduced and used a Query field called node. This was used to effectively get any "node" from your graph of entities. Allowing for a more granular way to refetch (or update) an existing item on the screen, or to not have to drill down multiple nested fields to get back one thing, which in most cases is huge for performance depending on how your server is built.

This was leveraged by the usePaginationFragment hook, making it super easy to paginate a collection data, whereby the initial data was given to it, but needed to be "re-fetched" to get subsequent pages. This mean that you could have one page level query that got everything for the page, but then just re-fetching the list of comments, for example.

Now, this meant that your server needed to support the Node interface and node field. Which is well and good if you're starting on a greenfield server — but to others this is a daunting task.

Introducing the `@fetchable` SDL directive

This directive aims to solve the situation allowing you to progressive enhance your schema to make use of it's feature set without having to change too many things.

Its defined like this:

directive @fetchable(field_name: String!) on OBJECT

note here this is a directive you need to make available on the SDL not on your consumer queries.

along with this you also need to introduce a field__<typename>(<name>: ID!): <typename> Query field used to "re-fetch" that type.

so let's say you had this existing schema:

type Foo {
  databaseId: ID!
  name: String!
  baz: Int!
}

type Query {
  foo(name: String): Foo
}

for simplicity sake, just assume this type Foo was deeply nested somewhere super awkward to just query from the root.

and now you're wanting to refetch this, maybe for polling, or for pagination or what have you.

We simply need to introduce a new field, a directive and everything in the system should just work.

type Foo @fetchable(field_name: "databaseId") {
  databaseId: ID!
  name: String!
  baz: Int!
}

type Query {
  foo(name: String): Foo
  fetch__Foo(databaseId: ID!): Foo
}

and BOOM, we can now get back any Foo from any level, without needing to navigate a tree of fields.

Just to point this out as well. The server doesn't need to do anything special about that directive. It just has to implement the fetch field, and that's it. The relay-compiler will compile away that directive.

Just to quickly illustrate how this would look like with the node field.

interface Node {
  id: ID!
}

type Foo implements Node {
  id: ID!
  databaseId: ID!
  name: String!
  baz: Int!
}

type Query {
  foo(name: String): Foo
  node(id: ID!): Node
}

as you can see, we needed to add an interface make our type now extend that and add all the logic's around that new id field. This is still the prefers approach, as it would mean you'd end up with an extremely cluttered root query field as your field gamut grows.

Webpack 5 and Module Federation - A Microfrontend Revolution

Marais Rossouw — Mon, 02 Mar 2020 21:06:39 +0000

Picture this: you've got yourself a pretty whiz-bang component, not just any component, but that classic component that seems to just exist on every page... You know the header, or the authenticated state in that header, the CTA on the homepage... You get the gist. Up until now, you've probably been code sharing by simply sharing that component as an npm package, where you then build and deploy every application independently. Which seems reasonable, but there has always been something not quite right.

Now if you are anything like me, you've felt the pain when a designer asks you to change the border, or the background colour of that whiz-bang component. And you are dreading the deployment of having to now build each and every one of those apps. Maybe you will get lucky and it will all go smoothly, but probably not. You are impacting uptime perhaps, or maybe you are statically generating, and now your back-end gets hammered as you rush to get each of your 250k permutations built quickly to get this change out (personally, I've been there).

Introducing Module Federation! 🎉

Module Federation aims to solve the sharing of modules in a distributed system, by shipping those critical shared pieces as macro or as micro as you would like. It does this by pulling them out of the the build pipeline and out of your apps.

To achieve this there are two main concepts to get your head around: the Host's and the Remote's.

Host

A host is an artifact that can be loaded cold. Typically, the one that usually initializes from the window.onload event. A host app contains all the typical features from a SPA, or SSR app. It loads all the initial chunks, boots the app and renders what the user will see first. Now the main difference here is, instead of having that infamous super shared component even remotely bundled, it is referenced. Why? Because that component lives as part of the Remote!

You see, the beauty of this approach is that you can can have the critical JavaScript required to load that first app, and only the required; speaking true to the micro-frontend (MFE) philosophy.

An example config:

const ModuleReferencePlugin = require("webpack/lib/container/ContainerReferencePlugin");

new ModuleReferencePlugin({
    remoteType: 'global',
    remotes: ['app_one', 'app_two'],
    overrides: {
        react: 'react',
    }
});

Remote

A remote can both be a host or strictly a remote. A remote's job is to offer up, or rather expose modules that can be consumed by other Host's and Remote's.

You can also opt this remote into having some (or all) of its dependencies shared in the sense of; if the host already has react, just send it into this runtime, allowing the remote to not have to download its own copy of react.

An example config:

const ModuleContainerPlugin = require("webpack/lib/container/ContainerPlugin");

new ModuleContainerPlugin({
    name: 'app_one',
    library: { type: 'global', name: 'app_a' },
    shared: {
        react: 'react',
    },
    exposes: {
        Title: './src/components/Title'
    }
});

From the image above, you can see that a, b, c are all exposed components that come from different apps. B, and C come from our app_three container where A come from our app_two container. All three come together to make our green component, which you an also then expose!

To make things a bit simpler, and more uniform; we have a:

Federation Plugin 🕺

The important one!

But most of the time, you will want your apps to both expose and/or consume federated modules.

For this, we have a plugin to rule them all!

const ModuleFederationPlugin = require("webpack/lib/container/ModuleFederationPlugin");

new ModuleFederationPlugin({
    name: 'app_two',
    library: { type: 'global', name: 'app_a' },
    remotes: {
      app_one: 'app_one',
      app_three: 'app_three'
    },
    exposes: {
       AppContainer: './src/App'
    },
    shared: ['react', 'react-dom', 'relay-runtime']
}),

What you see up there is an app that can host its own copy of react, react-dom and relay, exposes its own AppContainer — but then has the ability to import the Title from app_one, and have the host share the dependencies, react, react-dom and maybe relay-runtime with that remote. Which means loading in that remote will only download the code needed to power that component, and NONE of the shared modules.

What this will allow you to do in practice is have each one of your MFE's expose its route-map, typically the component fragment that you'd give to react-router.

// AboutApp
// routes.jsx

export default () => (
    <Routes>
        <Route path="/about" component={About} />
    </Routes>
)

// AboutUserApp
// routes.jsx

export default () => (
    <Routes>
        <Route path="/about/:slug" component={AboutUser} />
    </Routes>
)

Marking that routes.jsx file as an exported member of the AboutApp, and AboutUserApp within their respective webpack configs.

// HomepageApp
// routes.jsx

import { lazy } from 'react';

const AboutAppRoutes = lazy(() => import('AboutApp/routes'));
const AboutUserAppRoutes = lazy(() => import('AboutUserApp/routes'));

// assuming you have suspense higher up in your tree 🤞
export default () => (
    <Routes>
        <Route path="/" component={Homepage} />
        <AboutAppRoutes />
        <AboutUserAppRoutes />
    </Routes>
)

and voilà you have yourself a lazy federated application!

whereby; the about app, and about user app are both loaded from their respective bundles - but act like they were all bundled together in the first place!

That's not all, what if you could also now wrap that router in a AppContainer, where you'd typically share headers and footers!

// AppContainerApp
// container.jsx

export default ({ title, children }) => (
    <>
        <Helmet>
            <title>{title}</title>
        </Helmet>
        <Header/>
        <main>
            {children}
        </main>
        <Footer/>
    </>
)
// Please don't actually do the Helmet part, re-renders are bad!

// HomepageApp
// App.jsx

import * as React from 'react';
import { render } from 'react-dom';
import { HashRouter } from 'react-router-dom';

import AppContainer from 'AppContainerApp/Container';
import RouterConfig from './routes';

const App = () => (
    <HashRouter>
        <Suspense fallback={'loading...'}>
            <AppContainer title="I'm the Homepage App">
                <RouterConfig />
            </AppContainer>
        </Suspense>
    </HashRouter>
);

render(App, document.getElementById('app'));

// AboutApp
// App.jsx

import * as React from 'react';
import { render } from 'react-dom';
import { HashRouter } from 'react-router-dom';

import AppContainer from 'AppContainerApp/Container';
import RouterConfig from './routes';

const App = () => (
    <HashRouter>
        <Suspense fallback={'loading...'}>
            <AppContainer title="I'm the About app">
                <RouterConfig />
            </AppContainer>
        </Suspense>
    </HashRouter>
);

render(App, document.getElementById('app'));

Boom! You have yourself an application that;

Has a homepage MFE that can be built, deployed and ran independently from our about app.
Has an about MFE that can also be built, deployed and ran 100% alone.
Has both applications share the common header and footer.
Has the about routes lazied into the homepage app, so... wait for it! You can have SPA transitions between 2 applications! And only download the delta between those 2 apps. react, react-router and such are all shared, so there is no re-download of that!

Think about the possibilities: you could share your design system so you could change the background colour of that component we spoke about, and effectively have all your things evergreen across your entire system! You could share the CTA that sits at the bottom of every article. What about that cross-sell component you'd like placed on the checkout and the product pages? Effectively endless.

Considerations

Now this all sounds amazing right? But there are few draw backs.

This is effectively micro-services on the frontend. So version is bound to come up. "Why did you introduce a breaking change"... For this I'd suggest a contract api snapshot jest test
If you are using relay, you cannot spread fragments on queries that wrap a potentially federated module. As the fragment could have changed. For this I'd suggest a QueryRenderer component.
Modules that depend on say a react context, where the provider is never exposed. Those sorts of things.
Loading in the right initial remote chunks is quite tedious at this stage. It requires knowing the chunk filenames ahead of time and manually injecting those. But we've got a few ideas.
Local development activities. Yet to find a nice clean way to not have to run all apps at once, but for now I personally have just been using webpack aliases, to point those app references to folders in my mono-repo.
... that is about it, in all my trials this solution hasn't surfaced any initial issues.

Community

The community has an amazing response for which Zack and myself (Marais) want to thank you all so much for assisting us, and shedding light to so many potential corner cases, and use cases which we are opening investigation as we grow this technology!

xiao

@varnull1

MicroFrontend solution of official webpack will come 😗😗😗
so excited and keep tracking
github.com/webpack/webpac…

15:20 PM - 29 Feb 2020

Liquid error: internal

Special thanks to:

Joel Denning author of SystemJS — for navigating us through the SystemJS space, and enlightening us about the world if importmaps, as further investigate dependency url resolution, which is fairly manual at the moment.
Tobias Koopers for webpack, and giving us such an amazing foundation to build this upon, and ultimately helping us carve the code needed to actually bring this concept into a reality.
AutoGuru for giving myself the space to create and experiment with this!

Photo by Daniel Fazio on Unsplash

Relay and SSR using createOperationDescriptor

Marais Rossouw — Thu, 19 Dec 2019 04:50:58 +0000

tldr;
Use createOperationDescriptor, and ask RelayEnvironment for the data, rather than sending queryProps to a window object.

const Component = () => {
    const environment = getRelayEnvironment(records);
    const queryConcreteRequest = getRequest(someGraphQLQuery);

    return (<SomeQueryAskingComponent {...environment.lookup(
        createOperationDescriptor(
            queryConcreteRequest,
            someVariables,
        ).fragment,
    ).data}/>);
};

A lot of what I see online in terms of articles around Relay + SSR is that they all follow a pattern similar to this:

They have a page level query ✅
The page level query gets fetched on the server with a fetchQuery ✅
They then dump the store to a window object (for hydration) ✅

But where they all fall apart is when they also flush the queryProps to the window object that you'd typically give to the component. ❌

Before I tell you why that is wrong, lets look at the flow of how things work.

Relay has 2 parts really, you have a RelayEnvironment, and a query (fragments, query renderes, etc..). The environment lives in a RelayEnvironmentProvider so when you have a useFragment or createFragementContainer it creates an identifier, and resolves data from its props. Those props typically come from a queryRenderer's render prop, or in SSR world come directly from a fetchQuery.

So the reason why the above is wrong is because if you have a massive page level query. The store is flushed to the window object, as well as the query props! Both contain duplicated bits of data. One being the map of ID's, and one being the "resolved data" for your query.

Now, in a production app using Next.js as the example, there is a NEXT_DATA, which is basically the window object constructed as a way for server side to relay (pun intended) initial props to the client side, for hydration. Now if you flushed both you end up with massive payloads. As an example, I had a blog that asked for authors, article bodies, tags, comments, reviews, related article's etc... All of that rolled into something like 46k lines of json (please just accept that it was large), which is horrible right!

Now lets get to the point of the article - How to fix this!

Instead of flushing the queryProps in the NEXT_DATA. Just figure out a way to resolve the queryProps on the client using nothing but the store. It's simple really.

You need 2 things: a reference to the query itself, and a RelayEnvironment. The query forms something of an "id" into the store, and the environment has the store. So create a relay store identifier through a createOperationDescriptor, which takes the query and its variables and spits out an id. Then use that id to lookup the data in the store, and simply give that to the component. Happy days! And now you're left with, and from our example, an almost 1k line JSON. Some ridiculous savings there!

Here is an example of this:

import { fetchQuery, graphql } from 'react-relay';
import { createOperationDescriptor, getRequest } from 'relay-runtime';

const WithData = (PageComponent, options) => {

    const WrappedComponent = ({ variables, records }) => {
        const environment = getRelayEnvironment(records);
        const queryConcreteRequest = getRequest(options.query);
        const requestIdentifier = createOperationDescriptor(
            queryConcreteRequest,
            variables,
        );

        const pageData = environment.lookup(
            requestIdentifier.fragment,
        );

        return <RelayEnvironmentProvider environment={environment}>
            <PageComponent {...pageData.data}/>
        </RelayEnvironmentProvider>;
    };

    WrappedComponent.getInitialProps = async () => {
        const environment = getRelayEnvironment();

        const variables = options.variables();

        await fetchQuery(
            environment,
            options.query,
            variables,
        );

        const records = environment
            .getStore()
            .getSource()
            .toJSON();

        return {
            variables,
            records,
        };
    };

    return WrappedComponent;
};

export default withData(
    ({ article }) => <h1>{article.name}</h1>,
    {
        query: graphql`
                    query ArticleQuery($slug: String!) {
                        article(slug: $slug) {
                            name
                        }
                }`,
        variables() {
            return { slug: 'example' };
        },
    });