Forem: Jovi De Croock

Prefresh, Fast-refresh for Preact

Jovi De Croock — Wed, 19 Aug 2020 16:32:14 +0000

Hot module reloading is a great way to improve developer experience, hitting save and seeing the output with the snap of a finger is great.
HMR by default can't really assume how a front-end framework works so it isn't able to just work out of the box, here solutions like react-hot-loader, react-fast-refresh and prefresh come into play.

In this article we'll mainly talk about prefresh and react-fast-refresh since the philosophy used by react-fast-refresh is the base for prefresh.

Well how does it work? This is a three-parter, we'll have the code-transformation part (Babel), the bundler part (we'll use webpack) and the actual runtime.

Code-transformation

In prefresh we use react-refresh/babel to perform this transformation for us. This will insert two methods:

register
sign

register will be inserted after every Component and will tell us what functions are declared within a file as well as their name.

Imagine the following code fragment:

const App = () => {
  const [count, setCount] = useState();
  return (<p>{count}</p>)
}

Here the babel plugin would insert register(App, 'App'). This helps us build up a registry of components which we can identify by file, ...

The sign function is a higher-order-function which will be used to create an instance for every component within the file. This instance will be used to calculate a unique implementation signature for a component or custom-hook.

So for instance a Component with a custom-hook will create a signature for that custom-hook and will also sign that custom-hook. This way we can see when changes happen to either of these.
The component changes arguments it passes to the custom-hook? The signature has changed.
The implementation of the custom-hook changes? The signature changed.

When the signature changes drastically we can't preserve the state of the component which is being swapped out, this could result in undeterministic behavior.

Here's an example illustrating this transformation.

Bundler

In the code-transformation part we saw that we utilised two functions: sign and register, these aren't just magically available. We need to provide them to our modules, this is the responsibility of the bundler. The bundler has an additional responsibility and that's hot-module-reloading itself, this is mostly available in dev-servers like webpack-dev-sever or the webpack HMRPlugin.

To achieve providing sign and register we'll have to inject code into every module, this code has to safely reset itself so we don't leak into other modules.

const prevRefreshReg = self.$RefreshReg$;
const prevRefreshSig = self.$RefreshSig$;

self.$RefreshSig$ = () => {
  return (type, key, forceReset, getCustomHooks) => {
    // Call runtime with signed component
  };
};

self.$RefreshReg$ = (type, id) => {
  // Register Component in runtime
};

try {
  // Here's your code, your bundler will wrap the module you provided it with.
} finally {
  // Restore to prevent leaking into the next module.
  self.$RefreshReg$ = prevRefreshReg;
  self.$RefreshSig$ = prevRefreshSig;
}

Now we've ensured that the code injected by the babel-plugin actually calls a valid function.

There's a bit more that we need to do inside of this plugin and that's react to hot-updates. In our case we only want to have files that contain Components hot-reload since these are the only ones our runtime will be able to react to.

This comes down to injecting:

    if (module.hot && hasComponents(module)) {
        const previousHotModuleExports =
            module.hot.data && module.hot.data.moduleExports;

        if (previousHotModuleExports) {
            try {
                    runtime.flushUpdates();
            } catch (e) {
                    self.location.reload();
            }
        }

        module.hot.dispose(function(data) {
            data.moduleExports = __prefresh_utils__.getExports(module);
        });

        module.hot.accept(function errorRecovery() {
            require.cache[module.id].hot.accept(errorRecovery);
        });
    }

You might wonder why we aren't wrapping custom-hooks in these HMR-boundaries, this is because HMR has a concept of bubbling. When we save on a custom-hook it will bubble up, we only use hooks inside of components so this will bubble up to all Components importing this custom-hook (or to nested custom-hooks and up to Components using that).

This connects the dots from our HMR to the runtime, but what does this runtime actually do. How does the virtual-dom allow us to manipulate HMR?

Runtime

Now that we're getting to the final part we're straying away a bit from how React handles this runtime. This runtime is specific to Preact and won't be a 1:1 mapping with how React does it.

A first thing to understand is that the Components we've been wrapping in the above examples don't map to one virtual-node, they map to several since a component can be used more than once. This means that inside of our runtime we need a way to track which Component maps to which virtual dom-nodes.

In Preact specifically we have a concept of option hooks (yes Marvin the secret is out). In our case we can use the vnode option which will fire every time Preact creates a virtual dom-node. All of these nodes have a property called type which represents a function signature and this function signature is what we've been wrapping in all of the above, the Component. This means that now we have a way to map a Component to an array of Virtual dom-nodes.

This actually means that we already have a lot since every time we hot-reload we'll see a set of register calls, these calls imply modules that are being hot-reloaded. All that's left at this point is a flush.

A flush means that we'll observe all these register calls, get the Components. All of these Components map to a set of Virtual dom-nodes, we can iterate over these and swap out their current .type for the new one, this ensures the vnode will use the new component-code. When we've swapped these old implementations out we can check whether or not this component has changed signature and reset the hooks-state accordingly. Finally we'll call the infamous forceUpdate method and see the new result on our screen.

Concluding

I hope you've enjoyed this insight into fast-refresh, please ask any questions you like on Twitter or here in the comments.

You can find all Prefresh integrations here.

How to urql, normalized caching

Jovi De Croock — Tue, 11 Aug 2020 18:12:22 +0000

Introduction

In our first blog post we talked about exchanges and how by default we're using a document-based cache. This is the cache that comes out of the box with urql and solves a lot of common cases, but what if this cache isn't sufficient for you?

There is a more advanced cache in the urql-ecosystem called Graphcache — this is a normalized cache. This cache brings certain possibilities like:

Reducing network traffic: this cache will enable you to update entities from a mutation response or a subscription trigger.
The cache reduces the amount of data in memory since it will "reuse" entities due to all data being normalized.

Just like the document-based cache, the normalized cache may be added as an exchange to the urql Client. Every time the Client receives a response it deeply traverses the response, to flatten the data, as if it came from a RESTful API. Imagine we receive the following response:

{
  "__typename": "Query",
  "todo": {
    "__typename": "Todo",
    "id": 1,
    "title": "implement graphcache",
    "author": {
      "__typename": "Author",
      "id": 1,
      "name": "urql-team"
    }
  }
}

In the document-based cache we would take this result, extract all typenames and store it so it knows when to invalidate this data.

In a GraphQL result we will see objects and arrays with typenames. An object with a typename is what we'd call an "entity" as it has a concrete type in the API's GraphQL schema. We would call fields on this type with values "records" and fields that refer to one or more different entities "links."

In a normalized cache we will need to traverse this response and transform it. We'll use the __typename and id fields to generate unique keys for each entity we encounter. We'll see two types during this traversal, one being a record, which is a property of the current entity, and the other being a link which describes how this entity links to another entity.

In the above example we see a link to an author — our Todo has a relation to an entity called Author.

Now we can start listing records for that Todo. We see a __typename and an id field so we can make the unique key for this entity Todo:1. A first record would be Todo:1.title = 'implement graphcache'. While traversing we notice another set of records for the Author entity. We save these as well and define that our Todo links to Author:1.

Essentially we make a list of authors and a list of todos and describe which of these relate to each other by the concept of links. This concept isn't new and can be found in Redux, for instance, where we'd manually have to do this. In GraphQL the query helps us structure this normalization.

You may wonder why we'd implement this complex logic when we have a key for each operation, which we can use to uniquely store a response. That's a great question and let's look at why this is not only better for memory but also for network traffic.

With the document-cache, when we receive a response to a mutation, we have to refetch all affected typenames. This results in all queries with said typenames to be invalidated and refetched. This invalidation can trigger a large amount of network requests — up to one for every query that's currently on the page. Not only that but each response that could have shared entities will be stored and take up more memory than needed.

With a normalized cache we'll share entities because we can identify them by id and __typename, this allows us to not only reduce the network payload but also to automatically update this entity on a mutation response. When a mutation would respond with the following payload:

{
  __typename: 'Todo',
  id: 1,
  text: 'Convert to @urql/exchange-graphcache'
}

We can safely do a lookup inside of our cache, find the Todo:1 and update its text property to be the new one instead of having to refetch all of these queries. Each entity is stored separately and we store how these entities link to each other. This allows us to treat responses as descriptions of how to update these entities and relations.

This is made possible with GraphQL because we already have instructions on how to traverse the result. This is the GraphQL Document that we send to the API as a query in the first place. A normalized cache can use __typename together with this document to automatically build stores of different types.

Caching logic

Graphcache can assume a lot automatically, but just like a real database it will need some explanation and logic to work more effectively. We've centralized this configuration since we believe that this should be reusable on an entity-level.

Identifying entities

When using Graphcache we prioritize developer ergonomics — this is why you a see a warning like this one which means the cache sees a __typename but is missing an identifier.

Let's say our todo is a bit out of the ordinary and uses a cid field to identify the entity. Graphcache allows us to specify this behavior with the keys config:

import { cacheExchange } from '@urql/exchange-graphcache';

const cache = cacheExchange({
  keys: {
    // We insert the Todo __typename
    Todo: (data) => data.cid
  }
});

Now we made our cache aware that cid is the identifier for every Todo.

Some entities may not be uniquely identifiable, like an object that just contains geo location coordinates. In this case this config can also be used to tell the cache that a certain entity has no key, by doing () => null . This will result in the keyless object to be embedded into its parent.

Resolving data

This pattern can be compared to the backend resolvers pattern of GraphQL. We'll specify a function that can override or resolve a certain piece of data. We'll see two use cases for this:

Connecting an entity from a list
Converting a piece of data to another format

Let's start with converting a piece of data. Let's say our entity has a field called createdAt. We need this to be a normal JS date object but at the moment it's returned as a string from our server:

const cache = cacheExchange({
  resolvers: {
    // Our _typename
    Todo: {
      // Our field
      createdAt: (parent) => new Date(parent.createdAt)
    },
  }
});

Now every time we query our Todo the createdAt field will be converted to a JS-date from the string.

The other use case is connecting an item from a list. Imagine we have queried a list of our entity and we want to click one of them to see its details. Our cache can't assume that a field called todo is a specific item from the queried todos, so we'll need to help our cache. We can do this very similar to the above — we know that in a normalized cache we need a __typename and id to resolve our entity. When we query a specific item we know what entity we are asking for and the id will most likely be part of the variables.

const cache = cacheExchange({
  resolvers: {
    // Our typename here is the root Queryfield
    Query: {
      // The field is one single todo
      todo: (parent, args) => ({ __typename: 'Todo', id: args.id })
    },
  }
});

Now the item queried from the list will be used for our details.

There's one caveat here: when there's a field missing that's not in the list, for instance in the list we only ask for the id and text but in the details, we also ask for the creator, ... then we still have to do a network fetch. This means the cache won't show you the data immediately since all partial data is considered a cache-miss. Unless graphcache is aware of the shape of your server-side schema (more about this later).

Updating data

The updater configuration allows you to define behavior that has to be executed when a subscription or mutation comes in. Graphcache will try its best to automatically update entities but when the entity isn't present in the cache (or has to be removed) it can't really assume how this should be done. Graphcache will need our help here. Let's consider a scenario where we add one todo to our list:

const cache = cacheExchange({
  updates: {
    // We tell graphcache that this field is a mutation, we can also do Subscription
    Mutation: {
      // The name of the field
      addTodo: (result, args, cache) => {
        cache.updateQuery({ query: TodosQuery }, (data) => {
          return { ...data, todos: [...data.todos, result.addTodo] }
        })
      },
    },
  }
});

Now we've told graphcache that when it sees a response to addTodo it has to append it to the existing list of todos.

Server-side schema

In the resolvers section we spoke about partial data and it not showing data without graphcache being aware of your server-side schema. Schema-awareness is our measure to show graphcache which of our fields are optional and which ones are mandatory, so when we provide the schema option you'll be able to return partial data for your entities. Not only that, but schema-awareness also brings you a set of developer warnings relating to Fragment matching. In short, the cache now has knowledge about how your data should look.

Adding a schema can be done like this.

Putting it into practice

Remember in the last post where we had a verbose piece of code which was only used to update our list of todos when a subscription triggered? With Graphcache we can now fix this without having to define custom logic in our React components.

You can follow along with this template.

If the API isn't working manually surf to https://k1ths.sse.codesandbox.io/ once to start it up.

Let's start off by adding our new cache to our dependencies.

npm i --save @urql/exchange-graphcache
## OR
yarn add @urql/exchange-graphcache

We're all set to start adding this to our client-exchanges now, so we go to our App.js and create the cache from the factory-function exported by @urql/exchange-graphcache and add it to our exchanges.

import { cacheExchange } from '@urql/exchange-graphcache';

const cache = cacheExchange();

const client = createClient({
  ...
  // Note that we removed the original cacheExchange.
  exchanges: [dedupExchange, cache, fetchExchange, subscriptions],
  ...
});

Now since we are using graphcache we can remove a lot of code from the Todos component since that custom logic to track subscriptions is now redundant.

export const Todos = () => {
  const [todosResult] = useQuery({ query: TodosQuery });

  useSubscription({ query: TodoSubscription });

  if (todosResult.fetching) return <p>Loading...</p>;
  if (todosResult.error) return <p>Oh no... {todosResult.error.message}</p>;

  return (
    <ul>
      {todosResult.data.todos.map(({ id, text, complete, updatedBy }) => (
        <Todo
          key={id}
          text={text}
          id={id}
          complete={complete}
          disabled={todosResult.fetching}
          updatedBy={updatedBy}
        />
      ))}
    </ul>
  );
};

This is all we need to listen for updated entities and react to them.

Conclusion

In this blog post we've touched on what normalization means, how to identify entities, how to resolve entity data and links, and how to update the data.

There's more to graphcache to achieve full-offline functionality. We'll be tackling this in subsequent posts.

All of this is also documented under a dedicated chapter around this cache.

How to urql, authentication & multiple users

Jovi De Croock — Wed, 04 Mar 2020 16:43:14 +0000

Introduction

In the last blog-post we covered the basics on how to query and mutate our data; in real-world applications, there's more to it. In this post, we'll cover setting an authentication token and handling multiple users interacting with the same data.

You can follow along by using this template.

The template above builds on the example we introduced in the previous blog post.

Authentication

Authentication is one of the most common needs in an application. When users log in, we need to provide an authentication token that we can use in requests.

First, let's build our login flow and change the behavior of our app so that users can't complete todos unless they have an authentication token.

When we navigate to Login.js, we see that there's a basic setup built for us, we have a <form> with an onSubmit, and an <input> controlling a variable called name.

We'll use the useMutation hook, which we discussed in the previous post, to log in and get a token.

import { useMutation } from 'urql';

export const Login = ({ setIsAuthenticated }) => {
  const [name, setName] = React.useState("");

  const [data, login] = useMutation(`
      mutation ($name: String!) {
          login (name: $name)
      }
  `);

  const handleSubmit = (e) => {
    e.preventDefault(); // no page reload due to submit
    login({ name }).then(({ data }) => {
      if (data.login) {
        setToken(data.login);
        setIsAuthenticated(true);
      }
    })
  }

  return (
    <form onSubmit={handleSubmit}>
      <h2>Login</h2>
      <input value={name} onChange={e => setName(e.currentTarget.value)} />
      <button disabled={data.fetching} type="sumbit">Log in!</button>
    </form>
  )
}

Once we have our token, the setToken method stores it in localStorage, and we notify the parent that we are authenticated with the setIsAuthenticated method.

After logging in we can see our todos, but we are no yet able to toggle the state of a todo. We still need to tell urql to send our authentication token to our server. The urql client has a property called fetchOptions that can be used to add data to our fetch request. This property can be set when we create the client. Let's go back to App.js and add the fetchOptions property so we can send the authentication token along with the toggleTodo request.

const client = createClient({
  ...
  fetchOptions: () => {
    const token = getToken();
    return token ? { headers: { Authorization: `Bearer ${token}` } } : {};
  },
});

The fetchOptions method can accept a function or an object. We will use a function so it will be executed every time we make a fetch request, and will always send an up-to-date authentication token to the server.

Consistent data

What if we want to build a shared todo app, and keep track of the last person to toggle each todo by means of an updatedBy field? How can we make sure our data gets updated correctly and keep our UI from getting outdated when multiple people are interacting with the same data?

A simple solution would be to add polling to our useQuery hook. Polling involves repeatedly dispatching the same query at a regular interval (specified by pollInterval). With this solution, we need to be aware of caching. If our requestPolicy is cache-first or cache-only then we'll keep hitting the cache and we won't actually refetch the data. cache-and-network is an appropriate requestPolicy for a polling solution.

Let's look at how our query looks after adding a pollInterval — let's say we want to refetch our todos every second.

const [data] = useQuery({
  query: `...`,
  requestPolicy: 'cache-and-network',
  pollInterval: 1000,
});

While refetching, data.stale will be true since we are serving a cached result while a refetch is happening.

We can test this by opening a new browser window and toggling a todo. We'll see that after the polled request completes the data will be in sync again. We can increase the pollInterval to see this more clearly.

Polling is a straight-forward solution, but dispatching network requests every second, regardless of whether anything has changed, is inefficient. Polling can also be problematic in situations where data is changing rapidly since there's still a time-window between requests where data can get out of sync. Let's remove the pollInterval and look at another option.

GraphQL contains another root field, the two we know now are query and mutation but we also have subscription, which builds on websockets. Instead of polling for changes, we can subscribe to events, like toggling the state of a todo.

In the last post, we touched on the concept of exchanges. Now we're going to add one of these exchanges to make our client support subscriptions. urql exposes the subscriptionExchange for this purpose, this is a factory function that returns an exchange.

Let's start by adding a transport-layer for our subscriptions.

npm i --save subscriptions-transport-ws
# or 
yarn add subscriptions-transport-ws

Now we can add the subscriptionExchange to the exchanges of our client!

import {
  cacheExchange,
  createClient,
  dedupExchange,
  fetchExchange,
  subscriptionExchange,
} from 'urql';
import { SubscriptionClient } from 'subscriptions-transport-ws';

const subscriptionClient = new SubscriptionClient(
  'wss://k1ths.sse.codesandbox.io/graphql',
  {},
);

const subscriptions = subscriptionExchange({
  forwardSubscription: operation => subscriptionClient.request(operation), 
});

const client = createClient({
  ...
  exchanges: [
    dedupExchange,
    cacheExchange,
    fetchExchange,
    subscriptions,
  ],
});

The ordering of exchanges is important: We want to first deduplicate our requests, then look into the cache, fetch it when it's not there, and run a subscription if it can't be fetched.

Now we are ready to alter the way we currently handle our todos data. Because we don't want to mutate the array of todos we get returned from urql we will introduce a mechanism based on useState and useEffect to save them in our own state.

This way we can have the useSubscription alter our state instead of keeping its own internal state.

import { useQuery, useSubscription } from 'urql';

const Todos = () => {
  const [todos, setTodos] = React.useState([]);
  const [todosResult] = useQuery({ query: TodosQuery }));

  // We're making a mutable reference where we'll keep the value
  // for fetching from the previous render.
  const previousFetching = React.useRef(todosResult.fetching);

  useSubscription(
    {
      query: `
        subscription {
          updateTodo {
            id
            text
            complete
            updatedBy
          }
        }
      `
    },
    // This callback will be invoked every time the subscription
    // gets notified of an updated todo.
    (_, result) => {
      const todo = todos.find(({ id }) => id === result.updateTodo.id);
      if (todo) {
        const newTodos = [...todos];
        newTodos[todos.indexOf(todo)] = result.updateTodo;
        setTodos(newTodos);
      }
    }
  );

  React.useEffect(() => {
    // When we transition from fetching to not fetching and we have
    // data we'll set these todos as our current set.
    if (previousFetching.current && !todosResult.fetching && todosResult.data) {
      setTodos(todosResult.data.todos);
    }
    // set the fetching on the mutable ref
    previousFetching.current = todosResult.fetching;
  }, [todosResult]); // When our result changes trigger this.

  return todos.map(...)
}

We use a little trick to see if we transition from fetching in the previous render to having data in the next. When a subscription triggers, we find the old todo and update state to include its new value.

Now we have introduced a consistent UI that can be used by multiple users simultaneously!

Note that we'll see a more elegant way of updating this todo when we reach the normalized caching post!

Conclusion

We've now learned how to handle authentication and keep our data consistent when there are multiple users interacting with it.

Next up we will be learning how to make our application more performant by using a normalized cache to avoid having to refetch on every mutation.

How to urql, basics

Jovi De Croock — Tue, 03 Mar 2020 15:43:41 +0000

When picking a GraphQL client for React, many default to using Apollo or Relay, but now there’s a new kid on the block rising in popularity over the last year: Its name is urql. It's not as packed with features as other GraphQL clients. Instead, urql aims to be minimal and highly customizable. This blog post series will start by walking you through getting started with urql, and then move on to more advanced topics like subscriptions, normalised caching, etc.

Concepts

This blog series assumes a basic understanding of GraphQL. The following basic urql concepts will also be referenced throughout the series.

Operations

In urql all operations are controlled by a central client. This client is responsible for managing GraphQL operations and sending requests. This includes things like queries, mutations, and subscriptions.

A typical Request Operation looks like this:

{
  key: 'hash',
  operationName: 'query | mutation | subscription | teardown',
  variables: {},
  context: {
        fetchOptions: 'function | object',
        requestPolicy: 'cache-first | cache-only | network-only | cache-and-network',
        url: 'string'
  }
}

The most important properties are listed in the above example; more properties can be found here.

The above key property is a hash of the querystring + variables used for this operation. This key uniquely identifies every operation, so, if we have two components dispatching the same query with the same variables, we can purposely ignore one of them to avoid duplicate requests.

With the requestPolicy we can dictate whether or not we want to use our cache, and whether or not we want to fetch even if there is a cache-hit.fetchOptions allows us to dictate what headers and other options to use with the fetch action.

When an Operation comes back as a cache-hit or as a fetched result we start calling it an OperationResult. This will typically look like this:

{
  operation, // the operationRequest mentioned earlier
  errors, // our possible server response errors
  data, // the data received
  extensions // possible extensions attached to the response by your backend
}

An OperationResult will then be handled by exchanges before reaching the client.

Exchanges

Exchanges are middleware-like extensions that handle how operations flow through the client and how they're fulfilled. Multiple exchanges may handle each operation.

You can pass in these exchanges to the client like this:

createClient({ exchanges: [exchange1, exchange2, ...] });

The exchanges will be executed in the order provided to the client. This means that when an operation comes in, exchange1 will be called. When exchange1 is done, the operation gets forwarded to exchange2 and so on. When the last exchange completes, we get an OperationResult. This OperationResult is then sent back through the chain of exchanges in the reverse direction, and finally reaches the client.

More info around exchanges can be found here.

__Typename

Every type we make in our graphql-server will have a name and send it back when we query the __typename field. For example, the entity below will implicitly have an additional __typename: 'Todo' field.

type Todo {
  id: ID!
  text: String
  completed: Boolean
}

The __typename field is useful for identifying the queries affected by a certain mutation. When a mutation receives a response with a __typename we're currently watching with a query, then we can assume this watched query should be invalidated.

Getting started

If you want to follow along you can use this template.

For this walkthrough we'll be using React.js but note that urql can be used outside of React.

Starting out with urql is pretty convenient. First, we create our client. This client will process the operations and their results.

// App.js
import { createClient } from 'urql';

const client = createClient({
  // This url can be used in your sandbox as well.
  url: 'https://0ufyz.sse.codesandbox.io',
});

The client has more options, but the url is the only mandatory one. A few exchanges are included by default:

Find more client-options here.

Next, set up a Provider to allow our React-tree to access the client.

import { createClient, Provider } from 'urql';

const client = createClient(...);

export const App = () => (
  <Provider value={client}><Todos /></Provider>
);

At this point, our client is set up to handle incoming results, and our App has access to this client and can dispatch operations. The only thing we are still missing is actually dispatching operations, so let's make our first query:

import { useQuery } from 'urql';

const TodosQuery = `
  query {
    todos {
      id
      text
      complete
    }
  }
`;

export const Todos = () => {
  const [result] = useQuery({ query: TodosQuery });

  if (result.fetching) return <p>Loading...</p>;
  if (result.error) return <p>Oh no... {result.error.message}</p>;

  return (
    <ul>
      {result.data.todos.map(({ id, text, complete }) => (
        <Todo
          key={id}
          text={text}
          id={id}
          complete={complete}
          disabled={result.fetching}
        />)
      )}
    </ul>
  );
}

In the example above, if todo results are present in the cache they will be returned synchronously (no result.fetching) and if they're not they will be fetched.

More options for the useQuery hook can be found here.

You might worry that this architecture would result in unnecessary fetching, but the first default exchange included in your urql-client is the dedupExchange. Do you recall us talking about a unique key on each operation? We use that key to determine in that dedupExchange whether or not we already have an operation in progress for a given piece of data. When queries and variables are identical, a new fetch is not performed.

We are still missing one crucial part: we want to be able to mark a todo as completed. Let's refactor our application to allow each Todo item to toggle and persist its completed state.

import { useMutation } from 'urql';

const ToggleTodoMutation = `
  mutation($id: ID!) {
    toggleTodo(id: $id) {
      id
    }
  }
`;

export const Todo = ({ id, text, complete, disabled }) => {
  const [result, toggleTodo] = useMutation(ToggleTodoMutation);

  if (result.error) return <p>Something went wrong while toggling</p>;

  return (
    <li>
      <p onClick={() => toggleTodo({ id })}>
        {text}
      </p>
      <p>{complete ? 'Completed' : 'Todo'}</p>
      <button
        onClick={() => toggleTodo({ id })}
        disabled={disabled || result.fetching}
        type="button"
      > {complete ? 'Toggle todo' : 'Complete todo'}</button>
    </li>
  );
}

Notice the disabled={result.fetching} on our Todo component. Our example uses a document-based cache, so when we do a mutation on a certain __typename, queries associated with this type will be refetched. In our case, toggling the completed state of our Todo type will cause our todos query will be refetched, so we prevent additional toggles while the result is fetching.

Try opening the network-tab of your browser when this mutation completes. You'll see a query being triggered to refetch our todos. This is because our cacheExchange sees a mutation response with the typename "Todo"; it knows that we are currently watching an array of this type and invalidates it, triggering the refetch.

If you'd like to dig into exactly how caching and the dedupExchange is working, you can delay the mounting of this second component until the first has fetched. You will see the data for the query return synchronously, thanks to our cacheExchange. The default cache will save responses by their operation key.

You can also try altering the default caching behavior by changing the requestPolicy from the default cache-first to cache-and-network. This will force the query to refetch in the background.

More options for the useMutation hook can be found here.

Conclusion

This was an introduction to urql, the new kid on the block for GraphQL clients. In the future we'll cover how to setup subscriptions, server-side rendering, and more.

We hope you learned something and are as excited as we are about this new library!

This is a cross-post from Formidable

Hooked-Form v4

Jovi De Croock — Thu, 28 Nov 2019 11:07:34 +0000

This is a follow up to my last post

When coming up with version 4 of Hooked-Form I reminded myself what my goals were for Hooked-Form:

Low bundle size
High out of the box performance
Good Developer Experience

in version 3 these were achieved in one way or another but I knew this could be better, so I took a step back and looked at what the possibilities would be.

In the first part I'm going over how Hooked-Form works in a smaller example, in the following parts I'll discuss how I attempted improving the goals for this library.

How does it work

We don't have to reinvent the wheel, the Form-Field approach used in redux-form is a very good approach and scales well. The fundamentals of the approach have been kept preserved but with the mindset of reducing the bundle size as much as possible.

Let's make a minimal example with Hooked-Form. Let's assume we have a component where you can edit your name and your friends. Our form will have an initial set of values and we can submit it.

const Wrapper = ({ children, name, friends }) => {
  const initialValues = React.useMemo(() => ({
    name: props.name,
    friends: props.friends,
  }), [name, friends]);

  return (
    <HookedForm onSubmit={console.log} initialValues={initialValues}>
      {children}
    </HookedForm>
  )
}

That's all you need, all options can be found here. The <HookedForm> will make a form tag for you under the hood and bind the onSubmit on it. You might think but what if I want to pass in extra properties? Well any property passed that isn't an option for HookedForm will be bound to the form tag, this allows you to supply for instance a className.

Let's make a TextField so we can alter our name in the form.

const TextField = ({ fieldId }) => {
  const [{ onChange }, { value }] = useField(fieldId);
  return <input onChange={e => onChange(e.target.value)} value={value} />
}

useField contains more like onBlur, ... To manage the state of a field. The field does not make any assumptions whether you are on a web environment so it can be used in react-native, ...

If we want to hook up our name we just have to do <TextField fieldId="name" /> and we're good to go!

Developer Experience

We have a pretty well-known approach to this, the Form-Field method for controlled fields, this method works very well and feels very intuitive. We control our state in a central place Form and make it available for all others through a React.contextProvider. A field can opt-in to a certain field and hook in to the errors, ... for this specific field.

I realized that in some cases you would like to react to changes in another field and adapt the current or possible values to that. Before v4 this would have to be done by adding another useField that listened on that field or even a useFormConnect which listens to the whole form-state and manually check everything.
Thankfully in v4 we have a solution to that and it's called useSpy.

You can read more about useFormConnect here.

Let's look at an example:

import { useField, useSpy } from 'hooked-form';

const optionsForAMinor = [...];
const regularOptions = [...];

const MySelect = () => {
  const [options, setOptions] = useState(optionsForAMinor);
  const [{ setFieldValue }, { value }] = useField('selectField');

  useSpy('age', (newAge) => {
    if (newAge >= 18) {
      setOptions(regularOptions);
    } else {
      setOptions(optionsForAMinor);
    }
  });

  return <Select options={options} value={value} onChange={setFieldValue} />
}

Every time our age changes we can change the options without having to mix multiple useField hooks in one field.

You can read more about the hook here

Size + Performance

Before this when a value changed the Provider would check what hooks would need to be updated and did that from the Provider which in the newer React version will trigger a console.warn saying that a parent can't update a child.

This made me reconsider how we handle propagating updates to components, we use the calculateChangedBits provided in a React.createContext to say we never want to handle rerenders so the value for this becomes () => 0. If you are not familiar with this API read more here.

This means that an update to the context value would never trigger any renders, this is not yet what we want but it improves performance since in normal context cases it will trigger a render on every useContext even if the changed part is not relevant for them.

The next step here would be to make a small event-emitter that would register on every field. We have a "subject" we can listen to on every field in the form of a fieldId, this should be more than sufficient.
Every useField will register itself to the emitter with the fieldId provided in arguments. When a change is triggered in errors, ... It will look at the changed parts and emit the relevant fieldIds causing a render on those hooks.

This compact emitter resulted in a reduction of 200Bytes in size.

Concluding

I hope I succeeded at improving the Developer Experience, the performance and size parts seem to have improved to me.

If you like the library don't forget to ⭐️ the repository, that means a lot!

Let me know what you think in the comments or tweet me!

Bonus example with useSpy: https://codesandbox.io/s/admiring-vaughan-u2lzt

Quitting my first job

Jovi De Croock — Fri, 14 Jun 2019 15:32:25 +0000

The job

Recently I've quit my first job, I see this as a good time to reflect on my close to two years as a web- and mobile engineer. I've come quite far both in the hard- and soft skills department.
I hope this can be an insight to others and help identify thinking errors.

For two years I was a consultant developer, the main programming language was JavaScript and we used React.JS on the front-end and Node.JS on the backend.
I mainly resided at one client which was one of the best places for a person looking for challenges like myself. We've built a lot of awesome stuff but I'm not going to talk about that in this post.

Hard skills

Learnings that involve coding.

Clean coding

Giving functions and variables good and clear names can be one of the hardest tasks we deal with on a daily base. It all sounds really straight forward when we're writing a small application but after a certain time or in certain functions it can get really tedious.

Something I've definitely learned in this process is that when you're not sure about a certain name, ask it to the person sitting next to you. If that person doesn't understand it by glancing at your code someone else won't either. You can ask for advice and take your learnings. Next time someone reads it you'll be sure that you've chosen a better name than you initially would.

Comments are not everything

We can write a dozen of comments but come on... Who updates these things... I agree that a comment can help with implementing a certain function, you describe steps for yourself and the person after you. That way you share your thought process with the person that has to solve a bug or whatever, this however makes you trust the next person to update your comments to reflect the changes made. When this isn't done the person after that could get really confused.

I'm all for comments in hard functions don't get me wrong but that's two places you should maintain when altering that function instead of one.
The lesson I'm trying to express here is that you first have to see that everything has clear names and only when that is present and it's not clear you should start writing comments. Business logic is one of these things that can cause complexity and won't regularly change, this makes it worth commenting.

Co-programming

One of the things I've learned to enjoy most is co-programming, not in the most strict way. I like it when you can bounce idea's at each other, person 1 says x person 2 says y and try it out. You get a view of how people debug and perceive errors.

All people have diverse mindsets when it comes to problem solving, even something that is as logical as problem solving knows hundreds of solutions. This means that we will be able to learn more productive solutions from one another.

Another positive here is that you'll see parts of the codebase that you otherwise would not touch. I myself noticed this problem sometimes where people didn't know parts I'd written with extensive amounts of business logic, this leads to frustration when they have to work on that part.

Soft skills

Assessing knowledge

When I started out I was really chaotic when explaining something and always assumed a certain level of knowledge about the subject I was talking about. This is one of the worst assumptions a person can make, I don't know how I made a thinking mistake like that. There are so many subjects in technology I know nothing about, if someone would have to explain an advanced subject in these they'd lose me 100% as well.

However, this is no uncommon thinking error. One of the hardest things we have to do commonly is put ourselves as a third person in the conversation. Evaluate the conversation/mentoring you're giving and think about it as the person receiving it as well as think about it as an outsider listening in.

I think that this is one of the most valuable learnings I've had in a while. It enables me to write better documentation, formulate my answers to questions better and talk clearer.

Severity is a curse on oneself

I've always had high expectations of myself these often lead to their own issues, something I definitely learned is that these are self-imposed. You should not reflect your own expectations on another person just because they are superior to you.
Reflecting expectations that you impose on yourself on another can lead to frustration and fear of asking questions. When someone doesn't like asking you questions an alarm bell should start ringing so loud.
I'm not saying that if everyone keeps asking you questions that you shouldn't do something about it but that's something you should judge for yourself.

Technology is so much more broad than just performing in a skill-based profession, it's about communication and learning from each other. A lack of communication with your team can lead to others working on the same bug, ... as you are working on. A lack of communication with the business side leads to non-concrete features and often need a lot of changes when released.

Agile work

During college I've always been sceptical about agile and the overhead it brings. This is something I've completely grown out of, agile is a wondrous working method to ensure the client gets what the client wants.

Agile work can be quite opinionated so I'll shortly describe how we worked. Our sprints lasted two weeks, once every two weeks we had a ceremony day this consisted of our demo to the clients, a retrospective and planning the next sprint. I've always enjoyed these ceremonies since the demo is a little pat on the back for the whole team and the retrospective allows you to vent things that are taking their toll on you.

I do think that story points in general are a non-optimal measuring unit, I know that we need a way to tell the business what feature holds what value but... It's not fair in the case where we judge a ticket on complexity we effectively say hey this is not complex or hey this is complex. Someone new in the team could take said ticket and feel inferior. The new team member should've been involved in the process of measuring this ticket but most newer people get overruled by the mass.

Comfort zone

A lot of companies seem to reside in some kind of comfort zone, they're open for new things but won't introduce the new things themselves. It should be a careful evaluation of pro's and cons. I myself am someone who likes new things that improve in some aspects, most of the time I have already evaluated these myself and see potential or don't see potential.

Let's approach this by example, I am heavily in favour of MobX due to its performant nature I thought why let new people worry about performance when they can first learn everything else? This seemed to be a bad decision since people had no idea how to efficiently scale MobX. This could be devoted to me being too little involved in their first project but that's the nature of consultancy I suppose.

I've learned that when you want to bring forth something new it should be a clear cut, one of the things I introduced that went smooth for example was TypeScript (yes before the hype.) it does not force the dev to alter thinking processes. It just helps the dev out.

In no way was this meant to come of as belittling or whatever, it's meant to shed some light on how hard it can be to decide what is worth introducing and what is not.
The Development-cycle has to be able to stay consistent for the clients, the quality of the software should remain and the quality of the code should remain.

General learnings

Performance

Not everyone is concerned with it, I know that this is a commonly discussed topic but I genuinely believe that if some companies would be able to see their bailout numbers of people on phones/bad internet countries they'd be shocked.

I know that you need measurements to effectively tell the business we need to do something about it but people that stop loading the website because it's several MiB of JS coming in on their slow connection aren't accounted for by Google Analytics and others. You need to effectively be present on the website for these to properly display solid information.

There are solutions for this but I think it's problematic thinking, global applications should be globally accessible. This is not applicable for inhouse business applications.

Conclusion

Work is a learning process and I as a developer have evolved tremendously in the last two years. I'm happy about the experiences I had and the people I met, now I'm looking at what the future holds for me.

React Hooks summarized

Jovi De Croock — Fri, 15 Mar 2019 14:54:53 +0000

Introduction

In React we have two types of components, a class and a function.
A class was almost always the choice when we needed logic and/or state, since this was not possible in the component functions (widely called stateless functional components up to the arrival hooks).

These times have changed since now we have Hooks!

What are hooks

It is not only meant to introduce state into our functional components but also ways to:

replace lifecycles to handle side effects
introduce mutable refs
compose logic

We are dealing with something that can help us improve our abstractions and use them without having to make a higher order component or render props component for it.

Hooks can only be called inside functional components (so not in classes) and should be declared on the top-level.

Higher order components

A higher order component makes it possible to reuse component logic. This is not some magical thing provided by React but more of a design pattern (just like regular high order functions, think of debounce).

Most libraries export a HOC, classically starting with "with", that injects the specific props for that library, like react-router's withRouter. In the withRouter case when you wrap it around your component withRouter(myComponent) then your component will have the history, match, ... injected into its properties.

Lifecycles

A lifecycle is a way to react to renders in a class component, these are (most important ones):

componentDidMount (after the first time this component is mounted into the dom)
componentDidUpdate (after the component updates due to props changing)
componentWillUnmount (before the component is unmounted)

Why not use a class

Well classes have historically proven to be more complex than regular functions, the big part here being played by our mysterious this.

When using a class we have to polyfill that if we want to support younger browsers which automatically makes our application heavier than with just regular functions.

The hooks

In this part I'll elaborate on the hooks I consider to be most useful in day-to-day development. In here I'll also include some of my pointers.

useState

This is the same as the this.state on a class, it holds a value which you can alter with a function.

Basic usage:

const Post = ({ title }) => {
  const [likes, setLikes] = React.useState(0);
  const like = () => setLikes(likes + 1);
  return (
    <div>
      <p>{title} {likes}</p>
      <button onClick={like}>Like!</button>
    </div>
  )
}

The argument we pass to useState is the initial value, this returns us an array of [value, alterValue]. This might not be a common sight but this is array destructuring. The good thing about this is that you can freely name your variable.

You can also lazily initialise your initialise your initialState, let's evaluate this statement a bit.
Example, our initialState is this: users.filter(({ age }) => age > 40).
Every time we come across this function it will be evaluated but if we write () => users.filter(({ age }) => age > 40). It will only be executed once.

The setter, in this case setLikes, can be used in two different ways:

setLikes(value)
setLikes((currentValue) => newValue)

The second grants you the most certainty about altering the most recent value.

Me personally I only write useState when it's a single value, for example a number, boolean,... For arrays and Objects i tend to use the next one useReducer.

useReducer

This hook is very alike to the reducers from redux, so useReducer accepts a first argument which is a function (the reducer function) and the second an initialState.

Example reducer function:

function reducer(state, action) {
  switch (action.type) {
    case 'LIKE': {
      return { ...state, likes: state.likes + 1 }
    }
    default: throw new Error('Unknown action received')
  }
}

Personally I really like to make the default throw an error since these reducers are isolated. This hook returns again an array with the first argument being the current state and the second a function that is often called dispatch. This because you can give this an object with a certain type. This object will be passed to the reducer function (you can see this function above) as the second argument and will trigger a certain state transformation depending on what type this action is.

const Post = ({ title }) => {
  const [state, dispatch] = React.useReducer(reducer, { title, likes: 0 });
  const like = () => dispatch({ type: 'LIKE' });
  return (
    <div>
      <p>{state.title} {state.likes}</p>
      <button onClick={like}>Like!</button>
    </div>
  )
}

So everytime we click the button an action of type "LIKE" gets dispatched, which matches on the first case. Meaning our likes will be incremented by one.

useRef

It used to be so that when we wanted to have a ref on a component we had to make a class, now that has changed!
We now have React.useRef, this returns us a refObject which we can place on a component/html-element.

const Input = () => {
  const textInputRef = React.useRef();
  return <input ref={textInputRef} />
}

now the textInputRef.current will be the input-element meaning we can do things like textInputRef.current.focus() to focus it.

useRef can also be used to for example hold a previous version of a value or hold a variable like we used to on classes, this.hasMounted = true (not a good practice but it states a good example)

useCallback

In all my examples you see me binding the function in render, which makes a new function on every render.
This makes it so that a PureComponent can't ever have shallow equal props... React to the rescue with useCallback!

useCallback returns the same function aslong as the inputs are equal, let's improve the function "like" from the useState example:

const Post = ({ title }) => {
  const [likes, setLikes] = React.useState(0);
  const like = React.useCallback(() => setLikes(likes + 1), [setLikes, likes]);
  return (
    <div>
      <p>{title} {likes}</p>
      <button onClick={like}>Like!</button>
    </div>
  )
}

aslong as setLikes and likes don't change our like function will always have the same reference, meaning it is equal to the previous by reference.

useMemo

This allows us to memoize expensive calculations, this uses the same array inputs mechanism as useCallback.

Let's say we want to filter a list for people over age 40, we don't want to do this on every render, instead we would want this to only happen when our users array changes.

const Persons = ({ people }) => {
  const overForty = React.useMemo(() => people.filter(({ age }) => age > 40), [people]);
  return overForty.map(({ name }) => <p>{name}</p>)
}

useEffect

When we want to let's say dispatch a redux action to fetch data when our component mounts or when a variable changes we can now do so in functional components thanks to useEffect.

const PersonsContainer = ({ isLoading, fetchPersons, maxAge }) => {
  React.useEffect(() => {
    fetchPersons({ maxAge });
  }, [maxAge])
  return isLoading ? 'loading' : 'loaded';
}

In this example every time maxAge changes it will trigger a refetch.

You can also return a function to useEffect, this function will be executed when the effect gets cleaned up, this means that is very good to handle unsubscribing and things like that.

useLayoutEffect

This alike to useEffect only that it is meant for side effects on the layout, so let's say you want to focus an input on mount and blur it on unmount (this is a pretty useless example but let's go with it).

const Input = () => {
  const textInputRef = React.useRef();
  useLayoutEffect(() => {
    textInputRef.current.focus();
    return () => textInputRef.current.blur();
  }, [])
  return <input ref={textInputRef } />
}

An empty inputs array never changes so it will only run on the first function execution and the cleanup only when it is not mounted anymore.

Custom hooks

Hooks are ideal to replace render props/high order components, this means that it is a really good way to compose logic.

Let's say we want to set the document title and make it listen to changes, then we can make a simple custom hook:

export default function useTitle(title) {
  useEffect(() => { document.title = title }, [title])
}

Some conversions

Let's see how classes translate to hooks with a few common scenario's.

ScrollToTop

A common component used to make the user always start at the top of the page when navigating around.

Before

class ScrollToTop extends React.Component {
  static propTypes = {
    children: PropTypes.node.isRequired,
    history: PropTypes.shape({
      listen: PropTypes.func.isRequired,
    }).isRequired,
  }

  componentDidMount() {
    const { history } = this.props;
    this.historyUnlisten = history.listen(() => window.scrollTo(0, 0));
  }

  componentWillUnmount() {
    this.historyUnlisten();
  }

  render() {
    const { children } = this.props;
    return children;
  }
}

After

const ScrollToTop = ({ children, history }) => {
  React.useLayoutEffect(() => {
    const unlisten = history.listen(() => window.scrollTo(0, 0));
    return () => { unlisten(); };
  }, []);
  return children;
};

ScrollToTop.propTypes = {
  children: PropTypes.node.isRequired,
  history: PropTypes.shape({
    listen: PropTypes.func.isRequired,
  }),
};

Note that the layoutEffect only triggers once to listen and the disposer to unlisten, this is a didMount and willUnmount all at once.

Datalist

Ah, the classic datalist with searches, pagination and fetching...

Before

const ComponentForX = ({ name }) => <p>{name}</p>;

const LIMITS = [10, 20, 50];

class DataList extends PureComponent {
  state = {
    page: 0,
    limit: 10,
    search: '',
  }

  componentDidMount() {
    const { fetchData } = this.props;
    const { limit, page, search } = this.state;
    fetchData({ limit, page, search });
  }

  componentDidUpdate(prevProps, prevState) {
    const { fetchData } = this.props;
    const { limit, page, search } = this.state;
    if (
      limit !== prevState.limit
      || page !== prevState.page
      || search !== prevState.search
    ) {
      fetchData({ limit, page, search });
    }
  }

  changeLimit = (newLimit) => {
    this.setState({ limit: newLimit });
  }

  onChangeSearch = (e) => {
    this.setState({ search: e.currentTarget.value });
  }

  nextPage = () => {
    const { page } = this.state;
    this.setState({ page: page + 1 });
  }

  prevPage = () => {
    const { page } = this.state;
    this.setState({ page: page - 1 });
  }

  render() {
    const { limit: currentLimit, search } = this.state;
    const { data } = this.props;
    return (
      <div>
        <input
          placeholder="search"
          onChange={this.onChangeSearch}
          value={search}
          type="text" />
        {LIMITS.map(limit => (
          <button
            key={limit}
            className={currentLimit === limit ? 'selected' : null}
            type="button"
            onClick={this.changeLimit.bind(this, limit)}>
            {limit}
          </button>
        ))}
        {data.map(x => <ComponentForX key={x.id} {...x} />)}
        <button type="button" onClick={this.prevPage}>Previous page</button>
        <button type="button" onClick={this.nextPage}>Next page</button>
      </div>
    );
  }
}

After

const ComponentForX = ({ name }) => <p>{name}</p>;

const LIMITS = [10, 20, 50];

const DataList = ({ data, fetchData }) => {
  const [currentPage, setCurrentPage] = React.useState(0);
  const [currentLimit, setCurrentLimit] = React.useState(10);
  const [currentSearch, setCurrentSearch] = React.useState('');

  React.useEffect(() => {
    fetchData({ limit: currentLimit, page: currentPage, search: currentSearch });
  }, [currentPage, currentLimit, currentSearch]);

  const changeLimit = React.useCallback((newLimit) => {
    setCurrentLimit(() => newLimit);
  }, []);

  const onChangeSearch = React.useCallback((e) => {
    setCurrentSearch(() => e.currentTarget.value);
  }, []);

  const nextPage = React.useCallback(() => {
    setCurrentPage(p => p + 1);
  }, []);

  const prevPage = React.useCallback(() => {
    setCurrentPage(p => p - 1);
  }, []);

  return (
    <div>
      <input
        placeholder="search"
        onChange={onChangeSearch}
        value={currentSearch}
        type="text" />
      {LIMITS.map(limit => (
        <button
          key={limit}
          className={currentLimit === limit ? 'selected' : null}
          type="button"
          onClick={changeLimit.bind(undefined, limit)}>
          {limit}
        </button>
      ))}
      {data.map(x => <ComponentForX key={x.id} {...x} />)}
      <button type="button" onClick={prevPage}>Previous page</button>
      <button type="button" onClick={nextPage}>Next page</button>
    </div>
  );
};

Note that in our setters we aren't rebinding the function when the state setter changes, this is because when you give a function as argument you are working with a non-stale reference.

Pitfalls

not having enough variables in your inputs array, meaning that it could be using stale references
over abstraction, it's better to compose several hooks than to make one big abstraction
conditional hooks or hooks in loops, conditions can be made with the array operator when needed, see useEffect, ...

Best practices

start your custom hooks with use and camel case it, example: useToggle, useReduxModule, ...
discuss an order of hooks this way you always have a consistent overview on your components

ESLint plugin

It would not be a React release if it wasn't accompanied by a great way to help us developers understand the quirks of these hooks.

That's why the React team made an ESLint plugin to help avoid these pitfalls and enforce the best practices.

Concluding

Hooks are an excellent way to improve on the abstractions we have without always having to make wrapper components/functions to inject the abstracted logic. Now we can use them inside the render of our functional components.

Note that the documentation about this topic is top-notch and goes into even more depth and use cases than covered in this post.

I think there are many great things to come in the React world and this new concept is a great one at that.

Modular redux architecture

Jovi De Croock — Thu, 28 Feb 2019 14:59:04 +0000

Introduction

I have been working on a pretty big application for the last year, I'll mainly talk about the frontend side in this post.
The essential to know is that the state management stack consists of redux and redux-saga.

This application keeps on growing and we tried lazily loading some pages and this seemed to work fine but well we knew it could be done better.

In this post I'll elaborate on the concept used to achieve the architecture we are building towards and I'll close off with a minimal codesandbox showcasing this.

Cohesion vs Coupling

One certain day we had the idea to look at our folder structure and evaluate it with these terms.

Cohesion indicates the relation of a certain part to the module. Example: grouping all actions under /actions is a form of low cohesion, while grouping all projectActions under a module named project is a form of high cohesion.

Coupling can be seen as when you change something in module x, will it affect module y. To clarify this has nothing to do with your abstractions, changing abstractions like for example a Button will most commonly affect a multitude of modules.

Good software has high cohesion within modules and low coupling between modules.
This is how we started thinking about a modular architecture for our application, spoiler alert we found it as well.

Problem

When lazy loading we found that we introduced additional loading time, the chunk loads and only after the chunk had loaded we could start fetching our data.
This introduced an overhead we did not want, this made for a new hurdle we had to overcome before we could implement a new architecture.

We did not want for our new architecture to impose new constraints on UX.

Architecture

Now for the final part the architecture we arrived at after some research and work.

The folder structure looks like this:

/common
/reducers --> static reducers
/sagas --> static sagas
/modules
  /module1
    /submodule1
    actions.js
    sagas.js
    reducers.js
    index.js
...

So every module contains its own submodules and redux logic, these will be injected when the module gets loaded.

When we have submodules for example when we are looking at a certain user we can control the appointments of that user then we can also make this a lazy module that only gets loaded on demand.

When we evaluated this approach within our team this seemed to scale elegantly.

Reducers

After reading the redux documentation we found a way to dynamically inject reducers.
Note that we make a distinction between state that is always relevant like for example application metadata or a logged in user.

We alter our store as followed:

function createReducer(asyncReducers) {
  return combineReducers({
    ...staticReducers,
    ...asyncReducers
  });
}

export const sagaMiddleware = createSagaMiddleware();

export default function configureStore() {
  const store = createStore(createReducer(), applyMiddleware(sagaMiddleware));

  store.asyncReducers = {};

  store.injectReducer = (key, asyncReducer) => {
    store.asyncReducers[key] = asyncReducer;
    store.replaceReducer(createReducer(store.asyncReducers));
  };

  store.removeReducer = key => {
    delete store.asyncReducers[key];
    delete store.getState()[key];
  };

  return store;
}

The introduction of asyncReducers allows us to always keep track of what dynamic reducers are loaded in at any given time.

The helper methods make it really easy to dynamically add and remove reducers when relevant.

Sagas

This was a bit tricker but after some careful research we found out that when you export the sagaMiddleware you can actually just dynamically run saga's.

This seemed so easy but after some testing it turned out that you really have to remove the saga when unmounting since you can keep on adding a saga by accident. This made for some funny situation where five network requests got dispatched at the same time and no one even knew how.

That's why we made a little helper that makes use of forking the saga and cancelling when it's needed.

function runSaga(key, saga) {
  const runnableSaga = function* main() {
    const sagaTask = yield fork(saga); // Forks the saga returning a task
    const { payload } = yield take(CANCEL_SAGA); // We listen for this action.

    if (payload === key) { // If the action is dispatched with our key cancel it.
      yield cancel(sagaTask);
    }
  };

  sagaMiddleware.run(runnableSaga); // sagaMiddleware exported from above.
}

function cancelSaga(key) {
  store.dispatch({
    type: CANCEL_SAGA,
    payload: key,
  });
}

For those of you who are not familiar with redux-saga fork, take and cancel all are helpers exposed by the library.

UX-problem

The solution to this was actually quite simple, we load in the module/index normally so this is a static import and when it's called it will inject the saga and reducer.
After this happens it dispatches an initial action to start fetching the data, meanwhile your UI chunk is being loaded. This makes it so that the two loading parts happen at the same time, one can take longer than the other but that does not make for much difference.

The cool part is that this introduced us to a new way of loading, just like how facebook renders a seemingly empty timeline while loading the data we could do this as well while our data and UI loaded.

When the module gets unmounted it cancels the saga and removes the reducer and we can move on to the newly opened module.

React

To achieve this we actually leverage the power of hooks, we have a useEffect in the module index that only runs on initial and cleans the work up when it's unmounted.
We could also do this with a componentDidMount and a componentWillUnmount but it feels really clean to be able to do this in one function.

The only thing we have to pass is a set of saga's, a set of reducers and an initialAction.

For the lazy loading we use React.Suspense and React.lazy, this feels really intuitive just provide a fallback while it's loading.

Concluding

This approach feels quite good to me since when we unmount a module we also remove the saga, reducer and the state. This makes it that we can't add a saga double (yes this is possible) and that we can't have any stale state.
This in turn also reduces the memory consumption your webpage has at any given point.

This approach limits itself in no way only to redux-saga, this can linearly be applied to redux-thunk and many more.

Note that the approach for us had to be incrementally adoptable since we still have to be able to develop features while transitioning to the new architecture.

Feel free to give your opinion on this, I would love to hear it!

Demo

sources

Reducer splitting
Code splitting

Modern bundling

Jovi De Croock — Sun, 24 Feb 2019 13:05:03 +0000

Some people might call this title confusing, I am not talking about how we bundle but rather about what we bundle.

You might think (or not) another post about bundling, well this topic just feels really good to me. I hope that I can start this train of thought and help make this step.

Introduction

We are seeing more and more browsers fully comply to the ES2015 standards, this makes one wonder why everything is still transpiled down to ES5.

Well most of us know the answer, IE11 is a reasonable chunk of the web usage, in this proposal I won't be telling you to drop support for IE11 but rather move this responsibility to the developer using bundlers, transpilers, ...

We don't really know for how long we'll be seeing the use case to support IE11, on the bright side Microsoft has started discouraging the use of it.

Features

Let's talk features, the main features to support in ES2015 for me are, in no
particular order (feel free to ping me if I forget some):

arrow func: 87% source
async/await: 85% source
classes: 87% source
constants: 94% source
generators: 88% source
Promise: 89% source
proxy: 87% source
rest: 87% source
template literals: 88% source

A little extra, javascript modules are already 80% supported in the HTML script tag.
source

Note that it is safe to assume that every browser supporting module, supports the modern syntax.

Advantages

Shipping ES2015 offers two net positives, one being that it takes less time to parse for your browser.
Secondly it reduces the bundle size a significant amount, this makes for less code to download AND less code to parse.

This makes the argument that CSR applications are bad for first-paint etc a bit less present.

Problem

Maybe after reading all this you think to yourself well we don't even have IE11 users,let's just ship the modern bundle.

You could do this but all your dependencies you are using are still transpiled down to ES5 (and adding them to the babel-loader/... won't "transpile it up to es2015").

This means even if you as a developer want to ship your product in ES2015 it will only be your code combined with your dependencies in the older syntax.
Since these dependencies probably make up more than half of your code at this point in time there's not much benefit to be gained from shipping your own code as modern.

Package fields

We could introduce a new field in package.json to enable authors to ship ES2015 code but do we really want to add yet another level of complexity to the package.json?

In essence this would be the most "backwards compatible" solution for documentation and tutorials.

Doing this would in my opinion start an endless spiral, where in theory a field could be added for every new ES version. This is something I would really want to stay away from.

Libraries

When we're looking at libraries we see that it is commonly accepted that the author decides on how far the bundle is transpiled down.
Developers exclude node_modules from their loader and just assume it will all be okay.

An interesting idea I have been playing with is just shipping ES2015 in the module field.
If your target audience is smaller the developer using the library can add it to their loader and noone complains (more about this later).

The biggest problem I see here is that the transition of so many libraries would take a HUGE amount of time.

An added complexity of this could be when library authors are making use of things that need polyfills, they could specify it somewhere in for example a pkg.json.
I know this contributes to an extra complexity again but I want a starting point for all these things.

Note that with this mindset library authors can easily transition to higher targets should the need arise.

Consumer mindset

This is what troubles me the most, we would have to signify to library consumers that the browsers they support should be part of the build step, which in theory is already the case but not for thirth party dependencies.

This adds a significant amount of complexity to the initial setup of an application, ofcourse library authors can disclose that they are shipping ES2015/ES5 and include what should be added to the bundler config, but do we really want to go this far?
We take away the ease of mind of the consumer that thinks it will just work and add this extra on top of it all. Allthough, in my opinion most people who just want it to work aren't heavily into optimising their app and could use the browser or mainfield instead. Which in turn opts them out of tree-shaking, so that's not really what we want.

You could argue we need a step back to move forward but I am afraid things could just stay this way (with the added complexity on loaders etc) when the "nevergreen" browsers dissapear.
However this change enables us to rapidly move forward when they really do dissapear, by then most libraries will be shipping ES2015 and the need to disclose the level of transpilation will have dropped.

Polyfilling

For this part I'll refer to babel a lot but this also goes for TS, bublé,...

General

When using our transpiler we add a polyfill to support older browsers e.g.
@babel/polyfill, corejs,... This is a polyfill that will get downloaded even when your browser supports these features AND when you are not using these features.

Something that could be introduced is smart-detection, which would detect what is used in your codebase and polyfill for that or polyfill by looking at your browserslist in the preset-env.

Polyfilling at runtime, for example when IE11 is your browser and send other polyfills is not doable. Making a seperate bundle with polyfills for nevergreen/evergreen is doable.

Libraries

Remember me saying library authors can disclose what polyfills are needed? Well this revolves around that part.

If we'd have a plugin that would traverse our code and tell us what polyfills are needed when it is ES5 or when it is ES2015 would enable more fine-grained polyfilling.

You would disclose your lowest target and it could accurately include/exclude certain polyfills, which in turn reduces your bundle size again.

POC

In my spare time I made a proof of concept where it's possible to provide two bundles one legacy and one modern. This is based on a gist found on GitHub where the modern bundles are included in a script type="module" and the legacy in a script nomodule.

POC

Personally, my two cents after making the above work is that we have endless possibilities in terms of supporting legacy browsers aswell as ship ES2015 to the evergreen browsers.

Closing thoughts

If i forgot to mention any problems that could arise feel free to ping me.

I would really like to propose this as an RFC on a few repositories but it is such a huge change to our current way of working that I really don't know where to start.

Essentially I would have no issue working together with OSS repositories on this and help implement it.

A good point of entry for libraries would be microbundle, a lot of libraries use this to bundle their code.

For the polyfilling part I think we'll have to be at the TypeScript and Babel repo.

This idea initially started thanks to benjamn in the apollo repositories.

original

Sources

Hooked-Form

Jovi De Croock — Sun, 03 Feb 2019 10:34:32 +0000

A short introduction, hey my name is Jovi I am a web and mobile Engineer in a Belgian company and this is my first dev.to post, in light of the upcoming React-hooks release I decided to give it a shot.

The first time I heard about hooks, I quickly realized this would be a good way of reducing the bundle size needed for specific libraries as well as improve the overall readability of code.
Classes imply an overhead when they are transpiled down and at this point in time, library authors always transpile the library down for almost all browsers to be supported. In essence we could move away from this but that's a discussion for another time.

That's why I felt the need to make two libraries one toolbelt with hooks and a form library.

The form library will be the only one talked about in this post, it follows the Form/Field method. This method is used by popular libraries like redux-form.

I'm quite happy with the result since it ended up being a 2.8KB minified gzipped bundle, this is significantly less than other popular variants.

Hooks

The library exposes a set of hooks:

useField
useError
useFieldArray

These hooks can be used in your components to construct components, these will automatically fetch the methods, values and meta information when passed a fieldId.

Components

The library also exposes a set of Components, one might ask why was this choice made when we already have the hooks to make these ourselves.

Well with the components I opted to make a more optimised version, these memoize the component they have to render and only recalculate upon changes in their value, error, ...

So for every hook there's a component:

Field
Error
FieldArray

But there's one more and that is the Form component. I opted to keep the container as a HOC since a lot of hooks are used in it to preform validation,...

Example

I made a small example in a codesandbox of a basic working form: https://codesandbox.io/s/k8mylo9lo

This example showcases the basic usage of a Field and a FieldArray. The fun thing about hooks is that when you want to override the existing Field implementation you are free to do so just by grabbing useField. It will return the values/methods for the field you are passing and you can implement it yourself.

Concluding

I use hooked-form actively in one of my side-projects and I'm really happy about how it's turning out.

You can always read more in the documentation

I hope you've enjoyed the post and feedback about it is always welcome!

If you want to learn more about forms and the reasoning behind my choices you can read more here:

Field-Form method
Hooked-Form choices