DEV Community: Nicolas Cisco

A pain in the react: Challenges behind SSR

Nicolas Cisco — Thu, 16 May 2019 14:07:12 +0000

tl;dr In this post I'll try to show what, in my opinion, are the current pain points on the common ways to do ssr in React, comparing existing solutions in a didactic way.

First of all, what's SSR?. SSR is the acronym for server side rendering. On a high level, this means generating the complete web page on the server without having to rely on the client side javascript.

We won't enter into details of why we'd want to do this, but, it can be mainly motivated by SEO concerns, accessibility or just performance.

Problems behind SSR

If we take a quick look to the react documentation server side rendering might be seen as something quite simple. Just import react-dom/server and call renderToString method. Easy peasy:

const http = require('http');
const ReactDOMServer = require('react-dom/server');
const App = require('./App.js');

const server = http.createServer((req, res) => {
  const html = ReactDOMServer.renderToString(
    <App />
  );
  res.send(html);
});

server.listen(8000);

Well, sadly this will not work. Mainly because we are used to writing jsx in React, and we tend to forget that it isn't valid javascript. We could change the <App /> line to use React.createElement but that approach wouldn't escale for all the App.js file, the rest of the components and css files (it gets worse if a css pre-processor is used). So, here comes the first problem: The need of transpiling server code.

A common practice is dispatching data fetching on the componentDidMount lifecycle. But, do we have that life cycle method on server side?, spoiler: no. Really, it won't make any sense having componentDidMount on server, remember that renderToString is a synchronous single pass rendering, while on client side, we would call setState after data fetching is done in order to trigger another rendering phase. This difference between life cycles leds to several problems, first of all, how can we determine and fetch data before we render on server side?. And second, how can we share the state (which would have been generated with setState) between server and client?.

Last but not least, on client side we would trigger data fetching with ajax. Something like making a fetch call to an endpoint. This request will have specific information (mainly host information and headers such as the cookie one), how can this be replicated on server side?

To round up, we'll have to deal with the following issues:

Generating valid JS code for the server
Determining data dependencies
Actually fetching data
Sharing state

Generating valid JS code for the server

React is known for having a steep configuration in order to get it running. If we check what is considered a hello world example (using create react app) we would realize that we are including like 1300 dependencies . All these dependencies deal with a lot of features and requirements that we probably don't need, but, you get the point, it isn't something simple to get react running.

As far as how could we get valid node js code, we've got several options:

Webpack: apply similar building steps as it's done with the client code
Babel: transpile the code using babel-cli, no bundling.

There are many more options, we could use another bundlers (or compile with zeit's ncc), but it doesn't make much sense to throw new tooling.

Being pedantic, we should not need webpack, babel could be the one and only tool used for generating valid node js code. In fact, webpack will use babel under the hood for transpiling, so we could skip the intermediary. On the nodejs case, bundling isn't something we need, we can have many files and include them via node's module system, ie., in a less fancier way, use require.

The problem of the one tool to rule them all approach (ie. only babel) is that generally webpack is doing more tasks that only transpiling. For example, are we using css modules?, so, webpack is doing a name mangling of the classes to renerate unique names via the css loader. Are we using build time constants?, we are probably defining them with webpack's define plugin. There are more examples of tasks that webpack is performing (static files, etc, etc), but for each of these tasks we'll have to find a babel preset or plugin that performs this job.

If we stick with the webpack path, although we won't have the same configuration file for client and server, both files will be very similar, sharing most of its code. Also, most webpack loaders have a sort of explanation of how to use them for server side rendering (for example, css loader has the exportOnlyLocals option ).

Well, returning to our objective, we'll need to add some packages:

Webpack (and webpack cli)
Babel (preset and loaders)
React (and react dom)

yarn add --dev webpack webpack-cli webpack-node-externals @babel/core @babel/preset-env @babel/preset-react babel-loader
yarn add react react-dom

You may be wondering what webpack-node-externals is, well, on node, we don't want to bundle packages that can be included (require) on runtime (all packages from node_modules and the standard library), webpack-node-externals does exactly that.

Instead of separating build phases of server and client will use webpack's array configuration:

module.exports = [
  // Client configuration
  {
    mode,
    entry: path.join(src, 'client'),
    output: {
      path: dist,
      filename: 'client.js',
    },
    module: {
      rules: [
        {
          test: /\.js$/,
          include: [src],
          use: [
            {
              loader: 'babel-loader',
              options: {
                presets: [
                  ['@babel/preset-env', { modules: false }],
                  '@babel/preset-react'
                ],
              },
            },
          ],
        },
      ],
    },
  },
  // Server configuration
  {
    mode,
    target: 'node',
    entry: src,
    output: {
      path: dist,
      filename: 'server.js',
    },
    module: {
      rules: [
        {
          test: /\.js$/,
          include: [src],
          use: [
            {
              loader: 'babel-loader',
              options: {
                presets: [
                  ['@babel/preset-env', { targets: { node: 'current' }}],
                  '@babel/preset-react'
                ],
              },
            },
          ],
        },
      ],
    },
    externals: [
      nodeExternals(),
    ],
  },
];

I won't enter into details about babel presets: babel-preset-env is the easiest way to support new ECMA syntax and babel-preset-react allow us to write jsx.

Full example can be found here.

So, have we finished?. The quick answer is no. This example was the minimum to get React server side rendering running, it lacks of many features (no css, no static files, no source map, no production optimization, no vendor bundle, no code spliting, etc). Although we could start building a full project from this, I wouldn't recommend it. Now a days, we will probably use a tool that solves all this configuration, such as razzle, next.js or react-server. The idea of the example was to understand, on a higher level, how these tools work under the hood.

For the following examples we will use razzle to reduce the needed boilerplate.

Determining data dependencies

As I have said before, React on server behaves differently than on client. When calling renderToString, we are doing a sync one pass render. This means that in order to generate the complete page we will have to figure out how to fetch all the needed data before rendering.

There are mainly two approaches to solve this problem:

A Page / Route based approach (NextJs's getInitialProps or Afterjs's getInitialProps)
Component tree based approach (Apollo's getDataFromTree)

The first one relies heavily on using a router that works inside and outside the react world. Firstly, we would define Pages or Routes, ie, React components that will be rendered when a particular url is fetched. This can be done in many ways, eg, NextJs's uses a filename convention, or we could just have a routes object where urls are mapped to specific components.

It is important to note that we will only take into account data dependencies of pages (or routes), child components will be ignored. This is also highlighted on NextJs's doc:

Note: getInitialProps can not be used in children components. Only in pages.

So, the idea will be something like the following:

Get the url from the request
Determine the pages that will be rendered for that url
Call getInitialProps (or the data fetching method of the page)

We'll start writing a routes file in order to define what pages are rendered with each urls:

import Home from './Home';
import Other from './Other';

const routes = [
  {
    path: '/',
    component: Home,
    exact: true
  },
  {
    path: '/other',
    component: Other,
    exact: true
  }
];

export default routes;

Next step is to determine what pages match the requested url. To achieve this, we'll use React Router's matchPath function, and then call the getInitialProps static method if it exists:

server
  .get('/*', async (req, res) => {
    // Requested url
    const url = req.url;
    let promise;

    routes.some(route => {
      const match = matchPath(url, route);
      const { getInitialProps } = route.component;

      if (match && getInitialProps)
        promise = getInitialProps();

      return !!match;
    });

    // XXX: should handle exceptions!
    await promise;

    // render
  });

Note: Although, React router has a package which does this job, react-router-config, to keep things simple the example won't use it.

On client side, we'll have to add some code to run the getInitialProps method (something like the After component does in afterjs).

For the sake of simplicity, we'll follow a slightly different approach than afterjs. On the componentDidMount and componentDidUpdate methods, we'll just call getInitialProps :

class Home extends Component {
  static async getInitialProps() {
    console.log('Fetching Home!');
  }

  componentDidMount() {
    Home.getInitialProps();
  }

  componentDidUpdate(prevProps){
    // Only fetch data if location has changed
    if (this.props.location != prevProps.location)
      Home.getInitialProps();
  }

  render() {
    return (
      <div className="Home">
        This is the home!
      </div>
    );
  }
}

Full example can be found here.

On the other hand, Apollo GraphQL uses a tree based approach. This way of determining data dependencies is more declarative, as any component (not only pages) could have them.

The drawback of this solution is that is rather complex (we are kind of doing a pre render to get data dependencies), I won't enter into too much details, as Apollo's Blog has a great post explaining how it works. To make a short summary, Apollo has a function called getDataFromTree which walks through the entire React tree checking if components need to fetch information. Before the 2.5 branch, Apollo had a custom walkTree method which somehow reimplements React rendering algorithm (this is explained on the mentioned apollo's blog post).

Now a days (since Apollo 2.5), the getDataFromTree method uses React-Dom's renderToStaticMarkup under the hood. The Query component only renders its children when data has been fetched. And renderToStaticMarkup is called until no more information is needed to be fetched. So, Apollo calls renderToStaticMarkup to collect all the promises of the query components. As those components, if they have a data dependency, don't render its children (bare in mind that fetched data might affect what the children are), renderToStaticMarkup has to be called when those promises are resolved. This process is repeated until no more promises are collected. This approach allows to declare data dependencies on any node in the react tree, but has the performance issue of having to render the tree many times.

Although, we are able to determine, on client and server, what data dependencies we need to fetch, we haven't actually fetched any data nor shared across client and server!

Actually fetching data

On the previous step, we've detected what data is needed, but we haven't developed a way to actually fetch that data. Going to the basics, fetching data will be a simple ajax call (calling fetch on client side and a node compatible fetch implementation on server side). But, we must bare in mind that on the client side, fetch does some extra jobs under the hood:

const fetch = require('node-fetch');

fetch('/data');

// UnhandledPromiseRejectionWarning: TypeError: Only absolute URLs are supported

Apart from the absolute url, the client stores and sends http headers (eg.: Cookie) that we'll need to forward while doing SSR.

Both APIs, NextJs getInitialProps and AfterJs getInitialProps, implement a similar interface. This method is called with a bunch of parameters:

req: The request object (only server side)
res: The response object (only server side)
Location (url) related information

The problem here is that we are left alone when resolving the differences between server and client. Next nor AfterJs provide us a way to solve this. This often led to use a package such as fetch-ponyfill in order to have an isomorphic fetching function which could result in sending unnecessary code to the client and adding a base url (also forwarding request headers) if the req param is present:

// ...
const fetch = require('fetch-ponyfill')();

const Component = () => /* ... */;

Component.getInitialProps = async ({ req }) => {
  let url = '/data';
  let opts = {};
  if (req) {
    url = `${req.protocol}://${req.headers.host}${url}`;
    opts.headers = req.headers;
  }

  return fetch(url, opts);
};

Note: The simplest way of replicating the ajax request on server side is doing a request to itself, that's why we are prepending the host to the requested url. This isn't the most efficient solution, but it just works.

Well, so in order to provide a unified data fetching api, we'll slightly modify the getInitialProps api adding a fetch function. On server side, this function will take care of adding the base url stuff and headers, while on client side, it will be the default fetch.

import nodeFetch from 'node-fetch';

//...

server
  // ...
  .get('/*', async (req, res) => {
    const fetch = (url, opts = {}) =>
      nodeFetch(`${req.protocol}://${req.headers.host}${url}`, {
        ...opts,
        headers: {
          ...req.headers,
          ...opts.headers
        }
      });

    // Requested url
    const url = req.url;
    let promise;

    routes.some(route => {
      const match = matchPath(url, route);
      const { getInitialProps } = route.component;

      if (match && getInitialProps)
        promise = getInitialProps({ fetch, match });

      return !!match;
    });

    // XXX: should handle exceptions!
    await promise;

    // ...
  });

While on client:

class Home extends Component {
  static async getInitialProps({ fetch }) {
    return fetch('/data')
      .then(r => r.json())
  }

  // ...

  componentDidMount() {
    Home.getInitialProps({
      fetch,
      match: this.props.match,
    }).then(r => this.setState(r));
  }

  componentDidUpdate(prevProps){
    // Only fetch data if location has changed
    if (this.props.location != prevProps.location)
      Home.getInitialProps({
        fetch,
        match: this.props.match,
      }).then(r => this.setState(r));
  }

  // ...
}

This concept of not using a global fetch function and relying on the set up to differentiate implementation between server and client could also be used if we have a redux stack. When setting up the store, we could add a middleware which provides the same interface for data fetching but different implementations. A quick example can be achieved using redux-thunk (Note: we could also write a custom middleware and dispatch custom actions):

// createStore.js
import { createStore, applyMiddleware } from 'redux';
import thunk from 'redux-thunk';
import rootReducer from './reducers/index';

export default function (fetch) {
  return createStore(
    rootReducer,
    applyMiddleware(thunk.withExtraArgument(fetch))
  );
}

// client
import createStore from './createStore';

const store = createStore(fetch);

// server
import createStore from './createStore';

server
  // ...
  .get('/*', async (req, res) => {
    const fetch = (url, opts = {}) =>
      nodeFetch(`${req.protocol}://${req.headers.host}${url}`, {
        ...opts,
        headers: {
          ...req.headers,
          ...opts.headers
        }
      });
    const store = createStore(fetch);

    // ...
  })

On any action creator, we will use the third argument as the fetch function:

const actionCreator = (dispatch, getState, fetch) => {
  dispatch(loading());

  return fetch('/data')
    .then(data => {
      dispatch(receivedData(data));
    });
}

If we check Apollo's GraphQL approach, we will see a similar solution:

server
  // ...
  .get('/*', (req, res) => {
    const client = new ApolloClient({
      ssrMode: true,
      // Remember that this is the interface the SSR server will use to connect to the
      // API server, so we need to ensure it isn't firewalled, etc
      link: createHttpLink({
        uri: `${req.protocol}://${req.headers.host}`,
        credentials: 'same-origin',
        headers: {
          cookie: req.header('Cookie'),
        },
      }),
      cache: new InMemoryCache(),
    });

    // ...
});

Going back to the example (you can download the full example here), if we run it we'll have a splash:

Well, although we are fetching data on server side, we are not sharing it with the client nor using it on the server!.

Sharing state

We've managed to sort out how to detect what data request we need, actually fetched that data, but we aren't sharing that state between server and client.

First of all, we'll have to develop a way to use the initial state generated by the server. For the component, this means initializing its state with a prop instead of an empty object:

class Home extends Component {
  // ...

  state = this.props.initialState || {};

  // ...
}

(Yes, we are not reacting to initialState prop change which is considered an anti pattern in react world, but the idea of this example is to portrait the concepts which makes ssr work, not developing a production ready code. Also, initialState should be inmutable, so, taking that precondition here should not be a problem).

The parent component, also, has to pass the initial state:

const App = ({ initialState }) => (
  <Switch>
    {routes.map(({ path, exact, component: Component }) => (
        <Route
          key={path}
          path={path}
          exact={exact}
          render={props => (
            <Component
              initialState={initialState[props.location.pathname]}
              {...props}
            />
          )}
        />
    ))}
  </Switch>
);

Although initialState will only bring data of one component (will only have the value of the resolved promise created by the matched component's getInitialProps), it's a dictionary whose key is the url for the fetched data. The reason behind this is just simplifying the code needed to access that data: initialState[props.location.pathname] will return the data if it is the server side fetched component or it will return undefined if it isn't.

As far as the server is concerned, we will store the resolved value and pass it to the Appcomponent:

server
  .get('/*', async (req, res) => {
    // ...
    const initialState = {
      [url]: await promise,
    };
    const markup = renderToString(
      <StaticRouter location={url}>
        <App initialState={initialState} />
      </StaticRouter>
    );

    // ...
  });

We still need to pass the state from the server to the client. To achieve this, we will append a script tag that will attach the initialState to a global variable (eg: window.__INITIAL_STATE__):

res.status(200).send(
  `<!doctype html>
    <html lang="">
    <head>
        <!-- ... -->
    </head>
    <body>
        <div id="root">${markup}</div>
        <script>
          window.__INITIAL_STATE__ = ${JSON.stringify(initialState)};
        </script>
    </body>
</html>`
);

This is the approach suggested by most libraries (Redux, NextJS, Apollo GraphQL). On production, we would probably want to use a safer library for serialization.

And in the client, we will read that variable:

const initialState = window.__INITIAL_STATE__ || {};

hydrate(
  <BrowserRouter>
    <App initialState={initialState} />
  </BrowserRouter>,
  document.getElementById('root')
);

The full example can be found here

Are we done?

Well, really, no. There are many things left aside. My objective while writing this post was to sort out my ideas of what are the problems while trying to implement a basic react server side rendering app, in a way which could also help somebody else!. Personally, I think that to understand how the tools I use work will allow me to use them in a better way or create out-of-the-box solutions for known problems.

The examples of this post are far from being production code, just to name a few issues:

The Home component is the only one that does data fetching. All the needed logic is implemented on that component, clearly this won't scale. Data fetching code should be abstracted (it's not the component's concern!), perhaps high order components (eg: withInitialProps) or render props could be use to encapsulate it. (Well, probably for a non-didactic purpose, it's better to follow AfterJs / NextJs implementation and put that data-fetching implementation on the page's parent component)
We haven't even talk about how to prevent fetching the same resource multiple times if more that one component request it (this would happen when a Apollo-like approach is followed or if multi-level pages, ie children pages, are implemented).
Avoid the network for local queries: on the examples we have being doing a fetch to localhost, but this is rather inefficient. Apollo GraphQL has a section about how to do this, but in the practice is rather hard to implement it.

This post comes with a deprecation notice.

As I've said at the start of the post most of the problems appear because React doesn't provide us with a standard data fetching solution. We have to implement one of our own on top of the react api. All of this might change with the introduction of Suspense, Concurrent and Cache. The issue is that is not ready yet. React doesn't support suspense on server side rendering. And on the client it's only supported to do code splitting via React.lazy. React cache is on its early alpha and many things are prefixed with an unstable. Although there are many experiments out there (such as react ssr prepass or react lightyear), we won't be able to use them for anything more than playing around with what might be the future. But, let's cross our fingers that React's data fetching future might look bright, we just need to await React.suspense().

Originally published at https://nckweb.com.ar.

You don't want to keep all of your eggs in one basket: razzle plugin (II)

Nicolas Cisco — Sun, 31 Mar 2019 21:09:59 +0000

This is a round up of the first talk I did called “No metas todo en la misma bolsa: generando bundles por dispositivo” (which could be translated to the title of this article).

This is the second post in a series where I explain how to encapsulate the specific device logic into a Razzle plugin:

Building bundles per device
Avoiding boilerplate: Developing a razzle plugin (this post)
Generalizing: Developing a webpack plugin (wip)

tl;dr; the idea is to reduce the needed boilerplate in order to serve particular experiences for each device.

This post will be more code related, I’ll show how I encapsulated the specific device logic into a razzle plugin and all the problems I’ve had to sort that out. In the end, there will be a working example of this feature.

Razzle

Well, first of all, what is Razzle?:

Universal JavaScript applications are tough to setup. Either you buy into a framework like Next.js or react-server, fork a boilerplate, or set things up yourself. Aiming to fill this void, Razzle is a tool that abstracts all complex configuration needed for SSR into a single dependency — giving you the awesome developer experience of create-react-app, but then leaving the rest of your app’s architectural decisions about frameworks, routing, and data fetching up to you. With this approach, Razzle not only works with React, but also Reason, Elm, Vue, Angular, and most importantly……whatever comes next.

In shorts, it’s a tool that let’s you concentrate on developing the app instead of setting up all the SSR configuration. I’ve been using it since the 0.8 version and I really liked. Version 2.0 introduced plugins in order to modify webpack set up. And this last feature is what will be used.

Plugins

Razzle plugins are functions that are called after razzle creates the webpack config object.

'use strict';

module.exports = function myRazzlePlugin(config, env, webpack, options) {
  const { target, dev } = env;

  if (target === 'web') {
    // client only
  }

  if (target === 'server') {
    // server only
  }

  if (dev) {
    // dev only
  } else {
    // prod only
  }

  // Do some stuff...
  return webpackConfig;
};

This function is called for each configuration (web and node) and allows you to modify and return a new configuration object.

Keep in mind that what returns the last plugin will be thrown to webpack. We will abuse of this, webpack’s config object will be replaced with an array in order to use the multicompiler feature.

DeviceModuleReplacementPlugin

The magic behind the device module implementation is resolving to a device specific file, instead of the required one. As it was explained in the first post, the idea is that if a file with the device extension ( <filename>.<device>.js) exists, it will be used instead of the regular file ( <filename>.js).

On the first post, webpack’s NormalModuleReplacement plugin was used, in order to clean things up, a new webpack plugin was developed.

I won’t enter into details of how webpack internally work as this was mostly inspired by NormalModuleReplacement code:

class NormalModuleReplacementPlugin {
    // ...

    apply(compiler) {
        const resourceRegExp = this.resourceRegExp;
        const newResource = this.newResource;
        compiler.hooks.normalModuleFactory.tap(
            "NormalModuleReplacementPlugin",
            nmf => {
                nmf.hooks.beforeResolve.tap("NormalModuleReplacementPlugin", result => {
                    if (!result) return;
                    if (resourceRegExp.test(result.request)) {
                        if (typeof newResource === "function") {
                            newResource(result);
                        } else {
                            result.request = newResource;
                        }
                    }
                    return result;
                });
                nmf.hooks.afterResolve.tap("NormalModuleReplacementPlugin", result => {
                    if (!result) return;
                    if (resourceRegExp.test(result.resource)) {
                        if (typeof newResource === "function") {
                            newResource(result);
                        } else {
                            result.resource = path.resolve(
                                path.dirname(result.resource),
                                newResource
                            );
                        }
                    }
                    return result;
                });
            }
        );
    }
}

To summarize things, imported files are called modules. Webpack has a normal module factory that is encharged of creating the entity that represents that module. Plugins can hook to certain events of this factory in order to change custom behavior.

The idea is to hook up to the beforeResolve and afterResolve events in order to modify the requested module, just as normal module replacement plugin does. But, as this is a custom plugin, it has access to webpack’s internal resolver which will be used to check if the device specific file (aka module) exists.

class DeviceModuleReplacementPlugin {
  resolveByDevice(nmf, result, callback = () => {}) {
    const resolver = nmf.getResolver('normal', result.resolveOptions);
    const request = result.request.split('!');
    const { root, dir, name, ext } = path.parse(request.pop());
    const contextInfo = result.contextInfo || result.resourceResolveData.context;
    const device = contextInfo.compiler.split('.')[0];
    const file = path.format({
      root,
      dir,
      name,
      ext: `.${device}${ext}`
    });

    resolver.resolve(contextInfo, result.context, file, {}, err => {
      if (!err) {
        request.push(file);
        result.request = request.join('!');
      }

      callback();
    });
  }

  apply(compiler) {
    compiler.hooks.normalModuleFactory.tap(
      'DeviceModuleReplacementPlugin',
      nmf => {
        nmf.hooks.beforeResolve.tapAsync('DeviceModuleReplacementPlugin', (result, callback) => {
          if (!result) return callback();
          if (!result.context.startsWith(this.folder)) return callback();
          this.resolveByDevice(nmf, result, callback);
        });

        nmf.hooks.afterResolve.tapAsync('DeviceModuleReplacementPlugin', (result, callback) => {
          if (!result) return callback();
          if (!result.context.startsWith(this.folder)) return callback();
          this.resolveByDevice(nmf, result, callback);
        });
      }
    );
  }
}

As a side note, remember that Webpack allows to declare loaders using an inline syntax. This means that a resource might be something like this:

import Styles from 'style-loader!css-loader?modules!./styles.css';

Data is piped using an exclamation mark ( !) and the file is always at last.

Another note, the device name can be got from the compilers name (contextInfo.compiler.split('.')[0]), as a convention, the compiler name will be set to ${device}.${target} (target is web or node).

Web bundle

As far as configuration for web bundle is concerned, only two things have to be done:

Generate one bundle per device
Replace modules with device specific ones

To achieve the first objective, it is going to be abused the fact that the modified configuration is passed directly to webpack. The returned object will be replaced by an array. Each item of the array is going to be the configuration for each device.

As regards the second, DeviceModuleReplacementPlugin will do the trick. This plugin will be added to the original config.

function web(config, { devices }, webpack) {
  const clients = devices.map(device => ({
    ...config,
    name: `${device}.client`,
    entry: {
      [`${device}.client`]: config.entry.client,
    },
    output: {
      ...config.output,
      filename: config.output.filename.replace('bundle', `${device}.bundle`),
      chunkFilename: config.output.chunkFilename.replace('[name]', `${device}.[name]`),
    },
    plugins: [
      ...config.plugins,
      new webpack.DefinePlugin({
        'process.device': JSON.stringify(device),
      }),
      new DeviceModuleReplacementPlugin(path.resolve('./src')),
    ],
  }));

  return clients;
}

After some tests, I’ve realized that dev server stopped working as expected. I got some CORS errors on the browser’s console and the bundle failed to load:

To understand a bit what was happening, I had to pay special attention to the How razzle works (the secret sauce) part of the readme:

In development mode (razzle start), Razzle bundles both your client and server code using two different webpack instances running with Hot Module Replacement in parallel. While your server is bundled and run on whatever port you specify in src/index.js (3000 is the default), the client bundle (i.e. entry point at src/client.js) is served via webpack-dev-server on a different port (3001 by default) with its publicPath explicitly set to localhost:3001 (and not / like many other setups do). Then the server's html template just points to the absolute url of the client JS: localhost:3001/static/js/client.js. Since both webpack instances watch the same files, whenever you make edits, they hot reload at exactly the same time. Best of all, because they use the same code, the same webpack loaders, and the same babel transformations, you never run into a React checksum mismatch error.

My best bet is that I was somehow overriding dev server configuration. Checking razzle’s start script, I came across that the devServer property of webpack’s configuration was being used:

  // Create a new instance of Webpack-dev-server for our client assets.
  // This will actually run on a different port than the users app.
  const clientDevServer = new devServer(clientCompiler, clientConfig.devServer);

  // Start Webpack-dev-server
  clientDevServer.listen(
    (process.env.PORT && parseInt(process.env.PORT) + 1) || razzle.port || 3001,
    err => {
      if (err) {
        logger.error(err);
      }
    }
  );

Just setting that property to the returned array fixed the problem:

function web(config, { devices }, webpack) {
  const clients = devices.map(device => ({
    ...config,
    name: `${device}.client`,
    entry: {
      [`${device}.client`]: config.entry.client,
    },
    output: {
      ...config.output,
      filename: config.output.filename.replace('bundle', `${device}.bundle`),
      chunkFilename: config.output.chunkFilename.replace('[name]', `${device}.[name]`),
    },
    plugins: [
      ...config.plugins,
      new webpack.DefinePlugin({
        'process.device': JSON.stringify(device),
      }),
      new DeviceModuleReplacementPlugin(path.resolve('./src')),
    ],
  }));

  clients.devServer = config.devServer;

  return clients;
}

Node bundle (or must i say bundles?)

The node part is a bit trickier. Generating a bundle per device won't work, as it is needed an extra one that does the server's listening and device detection (to execute the device specific rendering and bundle serving).

Production build

We will start with production build, since it's simpler (I'll explain later why).

Tasks to be done:

Generate server bundle
Generate bundles per device
Develop a way to import the device specific bundles in the main server one

Well, the first task is the easiest one. No work has to be done, as it's the default bundle that razzle generates. So, our node function will start being something like this:

function node(config) {
  return config;
}

For the second objective, we can't just add the DeviceModuleReplacementPlugin, as this will generate a duplication of common server stuff (server listening, device detection, etc). In order to perform device separation, all the code that could be different per device will live on another entry point.

src
├── index.js
├── client
│   └── ...
└── ssr.js

The code that's in the main server's entry point (ie: src/index.js) won't be changed per device:

import http from 'http';
import express from 'express';

const server = http.createServer(
  express()
    .disable('x-powered-by')
    .use(express.static(process.env.RAZZLE_PUBLIC_DIR))
    .get('/*', (req, res) => {
      res.status(200).send('To be rendered');
    })
);

server.listen(process.env.PORT || 3000);

While the server side rendering entry point (ie: src/ssr.js) will:

import App from './client/App';
import React from 'react';
import { StaticRouter } from 'react-router-dom';
import { renderToString } from 'react-dom/server';

const manifest = require(process.env.RAZZLE_ASSETS_MANIFEST);
const assets = Object.entries(manifest)
  .reduce(
    (assets, [key, value]) => {
      const [device, k] = key.split('.');
      if (device === process.device)
        assets[k] = value;
      return assets;
    },
    {}
  );

const render = (req, res) => {
  const context = {};
  const markup = renderToString(
    <StaticRouter context={context} location={req.url}>
      <App />
    </StaticRouter>
  );

  if (context.url) {
    res.redirect(context.url);
  } else {
    res.status(200).send(
      `<!doctype html>
  <html lang="">
  <head>
      <meta httpEquiv="X-UA-Compatible" content="IE=edge" />
      <meta charSet='utf-8' />
      <title>Welcome to Razzle: ${process.device}</title>
      <meta name="viewport" content="width=device-width, initial-scale=1">
      ${assets.client.css
        ? `<link rel="stylesheet" href="${assets.client.css}">`
        : ''}
      ${process.env.NODE_ENV === 'production'
        ? `<script src="${assets.client.js}" defer></script>`
        : `<script src="${assets.client.js}" defer crossorigin></script>`}
  </head>
  <body>
      <div id="root">${markup}</div>
  </body>
  </html>`
    );
  }
};

export default render;

As far as device select, the same approach of the web bundles will be used, DeviceModuleReplacementPlugin:

function node(config, { devices, entry }) {
  const bundles = devices.map(device => {
    const filename = `${device}.server.js`;
    return {
      filename,
      device,
      name: `${device}.server`,
      path: path.join(config.output.path, filename),
    }
  });

  return [
    config,
    bundles.map(({ device, name, filename }) => ({
      ...config,
      entry,
      output: {
        ...config.output,
        filename,
      },
      plugins: [
        ...config.plugins,
        new webpack.DefinePlugin({
          'process.device': JSON.stringify(device),
        }),
        new DeviceModuleReplacementPlugin(path.resolve('./src')),
      ]
    })),
  ];
}

Note: In order to use process.device to get the device, I've webpack's DefinePlugin to set that variable.

At last, but not least, it's needed a way to import the deviced modules into the main server file. Keep in mind that as we are using the multicompiler feature, deviced server modules are being created in parallel with the main server module, so, just trying to import it will fail (webpack will complain about not finding the required file).

As there is no need of compiling all the server into one file, we could just tell webpack to differ importing those deviced modules to runtime. The easiest way to achieve it is just setting them as externals.

function node(config, { devices, entry }) {
  const bundles = devices.map(device => {
    const filename = `${device}.server.js`;
    return {
      filename,
      device,
      name: `${device}.server`,
      path: path.join(config.output.path, filename),
    }
  });

  return [
    {
      ...config,
      externals: [
        ...config.externals,
        bundles.map(({ filename }) => filename),
      ],
      plugins: [
        ...config.plugins,
        new webpack.DefinePlugin({
          'process.devices': JSON.stringify(devices),
        }),
      ],
    },
    bundles.map(({ device, name, filename }) => ({
      ...config,
      entry,
      output: {
        ...config.output,
        filename,
      },
      plugins: [
        ...config.plugins,
        new webpack.DefinePlugin({
          'process.device': JSON.stringify(device),
        }),
        new DeviceModuleReplacementPlugin(path.resolve('./src')),
      ]
    })),
  ];
}

Note: In order to use process.devices to get the device, I've webpack's DefinePlugin to set that variable.

As far as the main server is concerned:

import http from 'http';
import express from 'express';
import mobile from './mobile.server';
import desktop from './desktop.server';

const server = http.createServer(
  express()
    .disable('x-powered-by')
    .use(express.static(process.env.RAZZLE_PUBLIC_DIR))
    .get('/*', (req, res) => {
      if ( /* decide if it's mobile */ ) {
        mobile(req, res);
        return;
      }

      desktop(req, res);
    })
);

server.listen(process.env.PORT || 3000);

Note: Razzle comes with a react-dev-utils version that doesn't support webpack's multicompiler output, a newer version must be loaded using the selective version resolutions.

Dev

On development, things got a little bit harder as razzle has hot module replacement. Particularly, this brings several problems:

Hot reloading plugins have to be removed from the deviced modules
Start Server plugin isn't prepared for a multicompiler environment
externals approach for importing deviced modules will not hot reload

The first issue is pretty straight forward to be solved, filtering instances of webpack.HotModuleReplacementPlugin will do the trick:

plugins.filter(plugin => !(plugin instanceof webpack.HotModuleReplacementPlugin))

Regarding Start server plugin, it wasn't develop to deal with a multicompiler environment, ie, it starts the server when the afterEmit event of the compiler is dispatched. The problem in the multicompiler environment is that we don't have just one compiler, so we'll have an afterEmit event per device (and one extra for the main server). The server will be started when the first event is dispatched, but we want to start it when the last event is fired. In order to address this issue, is sent a PR, hoping that we could just do the selective version resolution trick.

Unluckily, I got no response from the plugin's maintainers. So, I ended up forking and publishing the plugin under a scope. From the razzle plugin side, we'll have to filter the Start server plugin and add the new one:

const StartServerPlugin = require('@nickcis/start-server-webpack-plugin');

// ...

function node(config, { dev /*, ... */ }, webpack) {
  // ...
  let plugins = config.plugins;

  if (dev) {
    const startServerOptions = config.plugins.find(
      p =>
        p
        && p.constructor
        && p.constructor.name === 'StartServerPlugin'
    ).options;

    plugins = [
      ...config.plugins.filter(
        p =>
          p
          && (
            !p.constructor
            || p.constructor.name !== 'StartServerPlugin'
          )
      ),
      new StartServerPlugin(startServerOptions)
    ];

    // ...
  }

  // ...
}

Last issue to be addressed is how to fix hot reloading for the deviced modules. The externals approach will only be used for the production build, for development, we'll just write a mock module which requires itself on runtime. In this way, webpack will bundle the require which will trigger importing on runtime. How can we trick webpack into writing an actual require?, easy, with a dirty eval:

// desktop.server.js
const r = eval('require');
module.exports = r('./desktop.server');

For the time the server starts, the deviced module bundling will have been finished and the mocked file will have been replaced with the actual module (which will trigger a rebuild and hot reloading). Although, this isn't ideal, it works (and is only used for development).

Rounding up things:

function node(config, { dev, devices, entry }, webpack) {
  const bundles = devices.map(device => {
    const filename = `${device}.server.js`;
    return {
      filename,
      device,
      name: `${device}.server`,
      path: path.join(config.output.path, filename),
    }
  });

  let plugins = config.plugins;

  if (dev) {
    const startServerOptions = config.plugins.find(
      p =>
        p
        && p.constructor
        && p.constructor.name === 'StartServerPlugin'
    ).options;

    plugins = [
      ...config.plugins.filter(
        p =>
          p
          && (
            !p.constructor
            || p.constructor.name !== 'StartServerPlugin'
          )
      ),
      new StartServerPlugin(startServerOptions)
    ];

    writeMockModules(bundles);
  }

  const serversPath = path.join(config.output.path, 'servers.js');

  return [
    ...bundles.map(({ device, name, filename }) => ({
      ...config,
      name,
      plugins: [
        ...plugins.filter(plugin => !(plugin instanceof webpack.HotModuleReplacementPlugin)),
        new webpack.DefinePlugin({
          'process.device': JSON.stringify(device),
        }),
        new DeviceModuleReplacementPlugin(path.resolve('./src')),
      ],
      entry,
      output: {
        ...config.output,
        filename,
      }
    })),
    {
      ...config,
      externals: [
        ...config.externals,
        ...(dev
          ? []
          : bundles.map(({ filename }) => `./${filename}`)
        ),
      ],
      plugins: [
        ...plugins,
        new webpack.DefinePlugin({
          'process.devices': JSON.stringify(devices)
        }),
        new ServersPlugin(serversPath, bundles, dev),
      ],
    },
  ];
}

Note: writeMockModules is supposed to write the mock initial require files for all the deviced modules, on the actual implementation a webpack's plugin does this job.

The final implementation is called razzle-plugin-device-spcific-bundles it can be found on github.

As far as installation and usage is concerned, the package has to be added:

yarn add --dev razzle-plugin-device-specific-bundles

And then, the plugin should be specified on razzle.config.js , it should be the last plugin:

// razzle.config.js

module.exports = {
  plugins: ['device-specific-bundles'],
};

Some options can be edited:

devices: An array of the enabled devices, by default [ 'desktop', 'mobile' ]
entry: The server's deviced entry point, by default ssr.js
alias: The alias used in the server to include an object with all the deviced modules, by default SSR

We'll write the following server's main entry point:

// src/index.js

import http from 'http';
import express from 'express';
import modules from 'SSR';

const server = http.createServer(
  express()
    .disable('x-powered-by')
    .use(express.static(process.env.RAZZLE_PUBLIC_DIR))
    .get('/*', (req, res) => {
      const device = process.devices[Math.floor(Math.random() * process.devices.length)];
      modules[device](req, res);
    })
);

server.listen(process.env.PORT || 3000);

Note: in order to fake device decision we'll just pick any device randomly, ideally, user agent sniffing or something of the sort should be done.

And have the following src/ssr.js:

// src/ssr.js

import App from './App';
import React from 'react';
import { StaticRouter } from 'react-router-dom';
import { renderToString } from 'react-dom/server';

const manifest = require(process.env.RAZZLE_ASSETS_MANIFEST);
const assets = Object.entries(manifest)
  .reduce(
    (assets, [key, value]) => {
      const [device, k] = key.split('.');
      if (device === process.device)
        assets[k] = value;
      return assets;
    },
    {}
  );

const render = (req, res) => {
  const context = {};
  const markup = renderToString(
    <StaticRouter context={context} location={req.url}>
      <App />
    </StaticRouter>
  );

  if (context.url) {
    res.redirect(context.url);
  } else {
    res.status(200).send(
      `<!doctype html>
  <html lang="">
  <head>
      <meta httpEquiv="X-UA-Compatible" content="IE=edge" />
      <meta charSet='utf-8' />
      <title>Welcome to Razzle: ${process.device}</title>
      <meta name="viewport" content="width=device-width, initial-scale=1">
      ${assets.client.css
        ? `<link rel="stylesheet" href="${assets.client.css}">`
        : ''}
      ${process.env.NODE_ENV === 'production'
        ? `<script src="${assets.client.js}" defer></script>`
        : `<script src="${assets.client.js}" defer crossorigin></script>`}
  </head>
  <body>
      <div id="root">${markup}</div>
  </body>
  </html>`
    );
  }
};

export default render;

Remember that the App component has device implementations, what is to say, some child components will have different implementations for desktop and mobile:

src
├── index.js
├── ssr.js
├── client.js
├── App.js
├── Component.desktop.js
└── Component.mobile.js

So, when mobile's render is called, it will run the bundle with the Component.mobile.js and when the desktop's one is called, the bundle with Component.desktop.js will be used.

The full example can be found on github.

Although, most of the boilerplate was reduced, there are several things to improve.

On the next post of the series, we'll try to generalize the implementation writing a webpack plugin in order to remove the need to use razzle. So, the device feature could be implemented on any project that uses webpack!. In addition, working directly with webpack will give us the possibility of removing all those compilations, improving build times!.

Yes, I've probably repeated webpack too much.

Originally posted on nckweb.com.ar

Android BYOD: Staying connected without losing phone control

Nicolas Cisco — Fri, 29 Mar 2019 14:49:38 +0000

Some months ago the company where I work introduced a new policy called bring your own device (BYOD). Although, many already had set up the company's google mail on our phone for free, now we were encouraged to use our personal device to work, but in order to do so, we had to install a Google App Device Policy. We were told that the objective of this policy was to protect sensible company's data and that this app will only enforce us to have a lock code and device encryption.

According to google's help:

Depending on how your administrator manages Android devices in your organization, you might need to install the Google Apps Device Policy app on your device. The app enforces your organization’s security policies on your device to protect corporate data and make it more secure. If you don’t install the app, but your admin requires it, you can’t access G Suite data on your device, including work email, calendar, and contacts.

As far as the initial description is concerned, the app wasn't something I could complain of, but after reading what the admin could do with the app, it really got on my nerves:

Some organizations require their users to install the Google Apps Device Policy app on their device. If you don't install the app, your mail, calendar and contacts may not sync with your device. Contact your G Suite admin for more details.

Your admin can set the following security policies:

Device password strength and required length.

Number for the following items:

Invalid passwords allowed before the device is wiped.

Recently expired passwords that are blocked.

Days before a device password expires.

Idle minutes before a device automatically locks.

Days device has not synced before wiping.

Application auditing.

Remote wipe a device or an account from a device.

Device policy app version requirements.

Blocking of security-compromised devices.

Your admin can also configure Wi-Fi networks and manage network access certificates using the app. They might choose to hide a network's details so that only users who have the network name and password can connect to it.

What?, Why on Earth would I allow the company I work for to audit the application I use on my personal device and allow them to wipe it?.

Unsynced way of working

When the policy was enforced, mail, calendar and files stopped syncing on my personal device. At first, I thought that well, I'd never used google drive on the device, I often ignored mails but I would really suffer from not having the calendar. I'm a bit forgetful, so being able to have notifications about meetings and being able to check my daily schedule while commuting really helped me.

My first try what just sharing my calendar to my personal account, this worked, but after some days, it stopped syncing. Sharing non public events was also forbidden to accounts that aren't from the organization. Then, I remember that Google allows to export calendars using a Private Address, but, as I couldn't find it, I concluded that it wasn't allowed.

It makes sense enforcing protection over drive and email, but, I really couldn't understand why I wasn't allowed to have a read-only version of my work calendar on my phone, particularly when I'm allow to have slack.

Developers, developers, developers

Well, I'm a developer, I know that google has a calendar api, what else do I need to sync the calendar to my phone?.

Apparently, there is a calendar format which google supports syncing, so, my idea was generating a service which through an url exposes my calendar in that format and importing that url in my personal account calendar.

I didn't want to spend money on this project, and reduce time maintaining it, so my requirements were:

The service should run on a free tier (nodejs server, static hosting)
It should be serverless (aka, functions / lambda)
The service shouldn't store any data (The less infrastructure it requires the less maintaining effort from my side).

I wanted to use this as an excuse of trying some serverless approach, I've played with Zeit's Now v1, but never had a chance of doing something with their v2. It has a node builder and a next js which fulfilled my needs backend and frontend needs.

Starting is as easy as forking their monorepo example. As regards the nodejs endpoints, things got a little more trickier. I really liked Zeit's Micro approach, and although it's from the same company they don't have a builder yet. There is a community builder but it really didn't work for me. So, I ended up building a package called micronize which enhances a regular labmda function with micro powers.

The project was very straight forward to be developed. Google token is stored on the url (something like Google calendar's Secret Address). So, when the calendar's endpoint gets hit, it reads google token and the calendar's id from the url, calls events list api, generates the icalendar file and serves it in the response. I heavily relied on the ical-generator package to generate the ical output, which really made things easier.

The source code can be GitHub and a working copy on https://gics.now.sh.

Although, I had fun developing this project, I really don't get why sometimes organizations get in the way with bureaucracy. I understand that security concerns regarding sensible data stored on google products is important, but I don't think the way to achieve it is forbidding people to sync work's account in their personal phone, specially when they had been willing to do it for free. In most cases it will just decrease productivity, with no security increasement. I must highlight that I'm allowed (and also encouraged) to have Slack on the phone which probably has more sensible data than work's calendar.

Originally posted on nckweb.com.ar

Gatsby: canonical urls & react helmet

Nicolas Cisco — Sat, 02 Mar 2019 15:00:00 +0000

tl;dr Developing a gatsby-plugin-react-helmet-canonical-urls because gatsby-plugin-canonical-urls and gatsby-plugin-react-helmet do not play well together when using the canonical link.

Recently Dan Abramov announced that he would stop writing in medium, so, trying to set up my own gatsby blog was a great week-end project. I really didn't want something fancy, just a blog site with a clean look that didn't take me so many time to set up.

My first step was opening gatsby tutorial. Although, I must admit that the people from gatsby did a great work writing the docs, it seems to be targeted to new comers, i just didn't want to read how to install node and all that stuff. I wanted to throw a one liner in the terminal and figure out thins on the way.

I finally found the generator cli and borrowing some ideas from Dan's Overreacted, I picked gatsby's starter blog which, to be fair, met all my needs.

> npx gatsby new nckweb.com.ar https://github.com/gatsbyjs/gatsby-starter-blog

Mission accomplish 🚀.

I need to fix two SEO related issues and I was going to be ready to go:

I planned to import my medium stories, I've to figure out how to set the canonical tag in order not to be penalized by Google because of duplicate content.
I publish my site with www and without it, so I've to automatically set the canonical tag for all the page (e.g: www.nckweb.com.ar/foo page should have a canonical tag with the value: nckweb.com.ar/foo ).

Custom Canonical data

The boilerplate file structure seemed a bit straight forward:

.
├── content
│   ├── assets
│   │   ├── icon.png
│   │   └── profile-pic.jpg
│   └── blog
│       └── first-post
│           └── index.md
├── gatsby-browser.js
├── gatsby-config.js
├── gatsby-node.js
├── package.json
├── README.md
├── src
│   ├── components
│   │   ├── bio.js
│   │   ├── layout.js
│   │   └── seo.js
│   ├── pages
│   │   ├── 404.js
│   │   └── index.js
│   ├── templates
│   │   └── blog-post.js
│   └── utils
│       ├── global.css
│       └── typography.js
├── static
│   ├── favicon.ico
│   └── robots.txt
└── yarn.lock

Checking the markdown of an example post, you figure out that properties are written with a front matter syntax (just like jekyll's). I just added a new one called canonical_url which will have the canonical value. (As dev.to uses that name to set the canonical, I was in the hope 🤞 that it will automagically work, but i wasn't my lucky day).

I wanted to do some seo stuff, my first bet was checking the component with that name. Luckily, that component was using React Helmet. So, I just needed to figure out how to pass the front-matter canonical_url value to this seo component.

The next lead was the blog-post component:

class BlogPostTemplate extends React.Component {
  render() {
    const post = this.props.data.markdownRemark
    const siteTitle = this.props.data.site.siteMetadata.title
    const { previous, next } = this.props.pageContext

    return (
      <Layout location={this.props.location} title={siteTitle}>
        <SEO title={post.frontmatter.title} description={post.excerpt} />
        ...
      </Layout>
    )
  }
}

export const pageQuery = graphql`
  query BlogPostBySlug($slug: String!) {
    site {
      siteMetadata {
        title
        author
      }
    }
    markdownRemark(fields: { slug: { eq: $slug } }) {
      id
      excerpt(pruneLength: 160)
      html
      frontmatter {
        title
        date(formatString: "MMMM DD, YYYY")
      }
    }
  }
`;

Yay! 🎉. It was using the seo component and judging from the graphql query, getting the canonical_url was just adding the property to the frontmatter query.

So far, so good, I got the canonical for the imported posts.

Plugins, plugins, plugins

I didn't want to reinvent the wheel, so my first attempt was looking for a plugin and I came across gatsby-plugin-canonical-urls which did exactly what I needed.

Setting it up was as easy as reading its docs. But, things got a little bit ugly:

Two canonical links, why?

Getting hands dirty

I was decided to fix this issue, so I jumped directly into code.

As far as i understand (checking gatsby-plugin-canonical-urls and gatsby-plugin-react-helmet ) a plugin consist of the following structure:

.
├── index.js
├── package.json
├── .babelrc
├── README.md
├── src
│   ├── gatsby-browser.js
│   └── gatsby-ssr.js
└── yarn.lock

The relevant files are gatsby-browser.js and gatsby-ssr.js, index.js is just a stub. Those two first files allows the use of the browser api and the ssr api respectively.

Reading the code:

// gatsby-plugin-canonical-urls/src/gatsby-ssr.js

import React from "react"
import url from "url"

exports.onRenderBody = (
  { setHeadComponents, pathname = `/` },
  pluginOptions
) => {
  if (pluginOptions && pluginOptions.siteUrl) {
    const parsedUrl = url.parse(pluginOptions.siteUrl)
    const myUrl = `${pluginOptions.siteUrl}${pathname}`
    setHeadComponents([
      <link
        rel="canonical"
        key={myUrl}
        href={myUrl}
        data-baseprotocol={parsedUrl.protocol}
        data-basehost={parsedUrl.host}
      />,
    ])
  }
}

// gatsby-plugin-react-helmet/src/gatsby-ssr.js

import { Helmet } from "react-helmet"

exports.onRenderBody = ({
  setHeadComponents,
  setHtmlAttributes,
  setBodyAttributes,
}) => {
  const helmet = Helmet.renderStatic()
  // These action functions were added partway through the Gatsby 1.x cycle.
  if (setHtmlAttributes) {
    setHtmlAttributes(helmet.htmlAttributes.toComponent())
  }
  if (setBodyAttributes) {
    setBodyAttributes(helmet.bodyAttributes.toComponent())
  }
  setHeadComponents([
    helmet.title.toComponent(),
    helmet.link.toComponent(),
    helmet.meta.toComponent(),
    helmet.noscript.toComponent(),
    helmet.script.toComponent(),
    helmet.style.toComponent(),
  ])
}

Both plugins implement the onRenderBodyapi:

Called after every page Gatsby server renders while building HTML so you can set head and body components to be rendered in your html.js.

Gatsby does a two-pass render for HTML. It loops through your pages first rendering only the body and then takes the result body HTML string and passes it as the body prop to your html.js to complete the render.

It's often handy to be able to send custom components to your html.js. For example, it's a very common pattern for React.js libraries that support server rendering to pull out data generated during the render to add to your HTML.

At this point, I got a clear picture of what was happening:

Both plugins added elements on the head calling setHeadComponents
Gatsby didn't prevent from link rel="canonical" repetition
Both plugins didn't take care if other plugin added the canonical tag.

Possible solutions

As I didn't want to reinvent the wheel, my first attempt was to "fix" any of the mentioned issues.

Making Gatsby's setHeadComponents aware that link rel="canonical" have not to be repeated.

Although this was one of my firsts thoughts, I wasn't really convinced by it. First of all depended on the plugins execution order (ie.: the first call setHeadComponents will be the one which win). And in order to develop this, I needed a better understanding of how Gatsby worked.

Implement the onPreRenderHTML api on any of the plugins (or create a new plugin that implement this api) in order to remove the duplicated link rel="canonical".

In order to avoid the repetition I needed to use getHeadComponent to get all head components, check if there is a duplicated canonical and then use replaceHeadComponents to set the head components deduplicated. Doing this will also depend on the plugin's execution order which was something I wanted to avoid. In addition, the documentation has a uppercased warning ("WARNING if multiple plugins implement this API it’s the last plugin that 'wins'") which discouraged me from this approach.

React Helmet deals with this kind of duplication, if the canonical's plugin instead of using setHeadComponents set the link with react-helmet's api, the problem will be solved.

As I was using react-helmet in order to set meta tags, this solution actually made sense. I had just to figure out how to add the Helmet component.

Canonicals with Helmet

With this approach I'll have to add the Helmet element. As it has to be done before the onRenderBody is called, i shouldn't use that api. In addition, in order to give the lower priority to the default canonical tag, this component has to be placed first (ie, on a higher level in the react's component tree) than the Helmet component that the page uses.

A simple way to achieve those things is wrapping current page and inserting a Helmet component in that wrap:

const Wrapper = ({ children, ...props }) => (
  <>
    <Helmet>
      link={[
        rel: 'canonical'
        ...
      ]}
    />
    { children }
  </>
);

Gatsby has the wrapPageElement which allows to exactly do that:

const React = require('react');
const { Helmet } = require('react-helmet');

exports.wrapPageElement = ({ element, props }, pluginOptions) => {
  if (pluginOptions && pluginOptions.siteUrl) {
    const myUrl = `${pluginOptions.siteUrl}${props.location.pathname || '/'}${props.location.search}${props.location.hash}`;

    return (
      <>
        <Helmet
          link={[
            {
              rel: 'canonical',
              key: myUrl,
              href: myUrl,
            }
          ]}
        />
        {element}
      </>
    );
  }

  return element;
};

What about client side rendering?

In order to be consistent, the plugin should also add the Helmet component on the client side. Although, if I don't add it, I won't trigger any React hydratation issue (the DOM tree that react hydratates is the same with or without this default canonical Helmet component), the canonical link is being removed when the client side react runs.

In addition, if you check gatsby-plugin-canonical-urls, you'll notice that it also implement gatsby-browser:


exports.onRouteUpdate = ({ location }) => {
  const domElem = document.querySelector(`link[rel='canonical']`)
  var existingValue = domElem.getAttribute(`href`)
  var baseProtocol = domElem.getAttribute(`data-baseProtocol`)
  var baseHost = domElem.getAttribute(`data-baseHost`)
  if (existingValue && baseProtocol && baseHost) {
    domElem.setAttribute(
      `href`,
      `${baseProtocol}//${baseHost}${location.pathname}${location.search}${
        location.hash
      }`
    )
  }
}

Luckily, gatsby's browser api implements the wrapPageElement method. So fixing this client side issues is just exposing the same method under the browser's api.

So far the experience implementing a Gatbsy blog has been great!. The API is very simple, so if the long list of plugins doesn't suit you, you can easily implement yours.

Community around the project is very active, I even got a gift swag for fixing a little doc issue while doing this post!

Originally posted on nckweb.com.ar

You don’t want to keep all of your eggs in one basket: building bundles per device

Nicolas Cisco — Fri, 15 Feb 2019 17:07:07 +0000

This is a round up of the first talk I did called “No metas todo en la misma bolsa: generando bundles por dispositivo” (which could be translated to the title of this article).
2018-07 - ReactJS - No metas todo en la misma bolsa.pdf
*Defining specific characteristics per device without developing a platform for each one. *drive.google.com

This is the first post in a series where I explain how to build a react progressive web application that targets specific devices constraints:

Building bundles per device (this post)
Avoiding boilerplate: Developing a razzle plugin (wip)
Generalizing: Developing a webpack plugin (wip)

tl;dr; the idea is to incrementally start serving particular experiences for each device (i.e: Mobile / Desktop) in the lazy programming way.

In this post, I’ll give a background about the problem to be solved and the first attempt to do it. Although, the post will talk about a concrete feature, I won’t be showing too much code, the following posts will have working examples.

The problem

As every developer knows, problems are created by the product team.

We’ve started having UI requirements that were too specific for each device. Some of these often involved using libraries which only target that device (e.g.: drag & drop capabilities were only needed on desktop, not mobile).

Bundle size started to rise, code started to get dirty and differences between devices got worse and worse.

At the time, the PWA team was a small team (only ~5 devs), we just could fork the platform and treat each device as a particular development. In addition, we had a working product, we needed to make changes incrementally.

Although many teams may have this problem, the developed solution isn’t a silver bullet. It addressed our particular constraints and characteristics. In this post, my objective is to give some insights about the process of how that solution has been reached.

The stack

First of all, i’ll have to do a brief introduction about the stack in which the platform is developed.

PWA technology stack

The PWA uses the usual React+Redux+React router stack bundled with webpack.

The server code is transpiled with babel in order to re use react component to do server side rendering.

Backends are external microservices. The PWA’s server has a proxy in order to communicate with them.

Options

As i’ve said before, the idea was to start optimizing the platform for each device.

We thought of three possible approaches:

Adaptative / Responsive design: serving the same javascript, css bundles and html for all clients and using responsive sizes and media queries in order to change the user experience according to the device’s width.
Separate Sites: Developing a fork for each device. This would involve to start moving common code to packages or something similar in order to avoid code duplication.
Dynamic Serving: Serving different content (js, css bundles) depending on the requests headers (mainly the UserAgent). The problem of this approach is to investigate a way of building the different bundles without having to do radical changes on the current code.

We were using the Adaptative / Responsive approach which lead to some problems:

Client received the web duplicated, both mobile and desktop components.
Code became a bit messy
Client received unnecessary libraries (ie: mobile clients also received desktop only libraries)

We want to reduce initial learning curve for developers (easy developer’s transition) and the long term maintaining effort. As far as the separate sites approach, we should fork the current codebase and maintain different codebases (a huge long term maintaining effort) or refactor the current codebase in order to extract all the common code and then fork (hard transition, as developers should understand how to write the common code in order to share it between forks). So, this approach was a no op.

Dynamic Serving

We end up going for the *dynamic serving *approach. In order to do, we should resolve some problems:

find out how to guess what device is the client (ie: is it mobile?, desktop?)
generate device specific bundles

The company already had a DeviceAtlas contract, so it was an easy choice. DeviceAtlas is a device detection solution for parsing User Agent strings in the web environment, so it was just what we needed.

Proposed architecture

The following problem was building device specific bundles without having to make huge changes on the way developer’s work. The idea was trying to resolve everything on compile time, so we don’t get any runtime penalties while also having a easy developer experience.

Ideally, a developer would write a component like this:

While having the following file structure:

And for each device bundle, it would resolve to the appropriate file (ie: DeviceSpecificComponent.mobile.js for the mobile bundle, DeviceSpecificComponent.desktop.js for the desktop one, and so on).

Luckily, Webpack has a plugin called NormalModuleReplacementPlugin which allows to change the resource resolution. But, in order to build a bundle for each device using this approach, it requires to make a compilation for each device. To address this issue, webpack has the multi-compiler feature.

NormalModuleReplacementPlugin configuration

To recap:

two builds for each device, one build for the node server ssr and another one for the browser.
one server which requires all device specific SSR bundles, uses DeviceAtlas to find out what type of device is the client, runs the specific SSR device bundle and servers the specific device bundle
the developer doesn’t have to think about what device he/she is targeting, only include the component and write the device specific implementation (using the file naming convention).

In the next post in this series, i will talk about how can all the boilerplate to implement this feature can be abstracted into a razzle plugin. There will be more concise examples with working code!