Forem: Marvin

[Boost]

Marvin — Thu, 10 Apr 2025 18:52:42 +0000

Shane Thomas for Mastra AI

Apr 10 '25

Build your first agent in 5 minutes with Mastra

#ai #javascript #typescript #tutorial

Comments 3

8 min read

Astro: progressively enhanced forms

Marvin — Thu, 09 Nov 2023 15:56:33 +0000

If you want to read the full article with code snippet highlighted correctly on the author's blog, follow this link

From MDN documentation:

Progressive enhancement is a design philosophy that provides a baseline of essential content and functionality to as many users as possible, while delivering the best possible experience only to users of the most modern browsers that can run all the required code.

One great example of progressive enhancement is form handling in Remix.

In Remix, you can create an almost regular HTML form, a function called action, and there you go: the form works with and without JavaScript.
It means that people disabling JavaScript in their browsers, or under specific constraints regarding their devices (or browsers, or low-connectivity regions) can still use the form and benefit from the feature.

Some people can stand that it's probably not necessary, and I agree. The thing is: it's free. It's baked in Remix and works using the same API.

// Copy/pasted from the Remix doc
// about action https://remix.run/docs/en/main/route/action
export async function action({ request }: ActionFunctionArgs) {
  const body = await request.formData();
  const title = body.get("title");
  const todo = await fakeCreateTodo({ title });

  return redirect(`/todos/${todo.id}`);
}

export default function AddTodo() {
  return (
    <Form method="post">
      <input type="text" name="title" />
      <button type="submit">Create Todo</button>
    </Form>
  );
}

It's a minimal API that provides a great experience to the users.

Remix is great, but what about Astro?

As you may already know, Astro is a framework for server side rendering that provides the ability to integrate frontend frameworks to get interactivity in the client. It is not the same kind of (meta) framework than Remix or Nextjs.
And as pointed on their homepage, the framework focuses on content websites for now.

Basically, regarding froms, it means: use regular HTML forms or the things you have available on your client side framework (e.g: formik on React, or whatever alternative) or build something yourself.

We are going to try building something as close to what Remix provides as possible knowing that we have the following constraint: we only build user-lands. We can't tweak the inner framework implementations to accomodate our needs.

It's important to have that in mind. We'll be forced to add a bit of verbosity along the way.

Let's get into it

I assume you already have an Astro project running locally. If that's not the case, you can create one from the get started page.

Create an HTML form

The first step is to create a regular HTML form that we will enhance later:

---
// index.astro
---
<main>
  <h1>Welcome</h1>
  <form method="post">
    <label>
      Email
      <input type="email" name="email" />
    </label>

    <label>
      Password
      <input type="password" name="password" />
    </label>

    <button>Sign in</button>
  </form>
</main>

Handle the form on the backend

This will be the progressive enhancement "baseline": a form that works with regular HTML, validated and handled in the backend so that as many users as possible can use it.

Additional note: this works without JavaScript on the client.

---
// index.astro

let error: string | undefined;

if (Astro.request.method === "POST") {
  // process form handling
  const data = await Astro.request.formData();
  const email = data.get("email")?.toString() || "";
  const password = data.get("email")?.toString() || "";

  // basic email verifications
  if (!email.includes("@domain.com")) {
    error = "Invalid email. It should contain @domain.com";
  }
}
---
<main>
  <h1>Welcome</h1>
  {error && <span>{error}</span>}
  <!-- HTML markup for the form -->
</main>

Enhancing the form client side

The form works great but the page is flashing: when we submit the form, we make an HTTP POST request and get back an HTTP response which is basically a new, whole, document. The browser refreshes to display that new document and it creates an effect of flickering.
This is the default behaviour when using HTML form and used to work that way for decades now.

There is one thing that we can do: when JavaScript is activated and loaded on the page, instead of making a regular HTML form request, we can use the fetch function to submit the form. That way, we avoid the page refresh and create a feeling of interactivity.

---
// index.astro
// The POST handling server side
---
<main>
  <h1>Welcome</h1>
  {error && <span>{error}</span>}
  <!-- HTML markup for the form -->
</main>

<script>
  // Get the form reference
  const form = document.querySelector("form");

  if (form) {
    // listen to the submit event of the form
    form.addEventListener("submit", function (e) {
      // Avoid to page flickering and deal with the form client side
      e.preventDefault();

      // fetch the current route instead of using the HTML form submission
      fetch(form.action, {
        method: form.method,
        body: new FormData(form),
        headers: {
          accept: "application/json",
        },
      }).then((res) => res.json());
    });
  }
</script>

At this point, if you try to submit the form, the page does not refresh anymore. If you check the network tab of your browsers devtools, you should see a POST request hitting your current route but it resolves a whole a document.

The reason is that our Astro backend only knows how to deal with regular HTML form. It doesn't know yet how to return either a whole document when the request comes from a regular HTML form or a simple JSON object when it receives a fetch request.

Let's modify the backend code so that it can deal with both types of requests:

---
let error: string | undefined;

if (Astro.request.method === "POST") {
  const data = await Astro.request.formData();
  const email = data.get("email")?.toString() || "";
  const password = data.get("email")?.toString() || "";

  if (!email.includes("@domain.com")) {
    error = "Invalid email. It should contain @domain.com";
  }

  // Verify if the request comes from the client or the server
  const isClientRequest =
    Astro.request.headers.get("accept") === "application/json";

  // If it comes from the client, return a JSON response with the data
  if (isClientRequest) {
    const response = new Response(JSON.stringify({ error }));

    return response;
  }
}
---

If you now try to submit the form again with JavaScript enabled, with your devtools opened, you can see that the fetch request now returns a JSON object with the error. It means that we can deal with this object to update the UI.

Cleaning up the ground and abstracting

It's already a bunch of code. Let's try to abstract the code from both the client and the server so that we can use it in different places easily.

On the client

We only want the most necessary code to enhance the form submission with as less code as possible. We can, as one example, end up with something like the following:

<script>
  import { handleClientForm } from "./handleClientForm";

  handleClientForm(document.querySelector("form"));
</script>

Let's move the content of the previous <script> tag into a dedicated handleClientForm function:

export const handleClientForm = (form?: HTMLFormElement | null) => {
  if (!form) return;

  // listen to the submit event of the form
  form.addEventListener("submit", function (e) {
    // Avoid to page flickering and deal with the form client side
    e.preventDefault();

    // fetch the current route instead of using the HTML form submission
    fetch(form.action, {
      method: form.method,
      body: new FormData(form),
      headers: {
        accept: "application/json",
      },
    }).then((res) => res.json());
  });
};

On the server

Same goes for the server: the idea is to move things in a dedicated action function to try getting as close as possible to what Remix does:

import type { AstroGlobal } from "astro";

export type ActionReturnType<T> = Promise<{
  response?: Response;
  data?: T;
}>;

export type CallbackAction<T> = () => Promise<T>;

export const action = async <T>(
  Astro: AstroGlobal,
  actionFn: CallbackAction<T>
): ActionReturnType<T> => {
  if (Astro.request.method === "POST") {
    const isClientRequest =
      Astro.request.headers.get("accept") === "application/json";

    // We have moved the Astro.request.formData() computations
    // outside this action function. This form checking
    // should now be done in the callback
    const data: T = await actionFn({ request: Astro.request });

    if (isClientRequest) {
      const response = new Response(JSON.stringify(data));

      return { response, data };
    }

    return { data };
  }

  return { data: undefined };
};

Here is how we would use it into the page module:

const { data, response } = await action(Astro, async () => {
  const data = await Astro.request.formData();
  const email = data.get("email")?.toString() || "";
  const password = data.get("email")?.toString() || "";

  if (!email.includes("@domain.com")) {
    return { error: "Invalid email. It should contain @domain.com" };
  }
});

if (response) return response;

The action function returns two objects: a data one and a response one.

When we submit the form using the regular HTTP way, we got back an entire document that is computed by astro with the available variables: in this case, it will use data to populate the template and since data.error might be filled, the template is generated accordingly.
When we submit the form using JavaScript on the client, we want to get back a JSON object. We don't want Astro to generate a whole HTML document. In this case, we wrap the JSON object into a response and early return it so that Astro does not try to generate a new HTML document.

Make the client code update the UI

From the previous sections about client side code, we sent a fetch request, but the UI was not updated. The reason is because the variable used in the Astro page are only available when building the page server side. Since we have shortcut this mechanism with the JSON response, we need to update the DOM manually when JavaScript kicks in.

This is the limitation I was referring too at the beginning of this article.

Remix wraps the whole page with a React context. In React, context is known to work both client AND server side:

if we submit the form without JavaScript, the action function will be executed and its returned value will be passed to the React context on the server. Then Remix will render the whole React tree (on the server again) and send it back as a document with the updated content.
if we submit the form with JavaScript, the action function is called as a fetch endpoint. Remix has now access to the data on the client and can pass it down via context. It re-renders the React tree (on the client again) and the content is updated.

Beautiful trick.

In our case, we can't do that: we don't have context in Astro. And even if we use React for our islands, the context provider should still be in our page, written by us. Plus, because of islands, the context might not work as you may think it would.

With that in mind, we have different solutions and it's up to you to chose one depending on your context. They are less elegant than the Remix one.

I will go with a framework agnostic one, without leveraging React or anything but instead I will rely on data-* attribute to update text nodes that need to be updated:

<main>
  <h1>Welcome</h1>
  <!--  Let's add the data-form-id attribute so that our script can updated it -->
  <span data-form-id="error">{data?.error}</span>
  <form method="post">
    <label>
      Email
      <input type="email" name="email" />
    </label>

    <label>
      Password
      <input type="password" name="password" />
    </label>

    <button>Sign in</button>
  </form>
</main>

And then adjust the handleClientForm function to update these node when we got an answer from the backend:

export const handleClientForm = (form?: HTMLFormElement | null) => {
  if (!form) return;

  form.addEventListener("submit", function (e) {
    e.preventDefault();

    fetch(form.action, {
      method: form.method,
      body: new FormData(form),
      headers: {
        accept: "application/json",
      },
    })
      .then((res) => res.json())
      .then((data) => {
        // Get all the dom node with a data-form-id attribute
        const allSlots = document.querySelectorAll("[data-form-id]");
        allSlots.forEach((slot) => {
          // For each of them get their value, which is basically the key of the data we get from the server,
          // in our case `error`
          const dataName = slot.getAttribute("data-form-id");
          const datum = data[dataName!];

          // update the according DOM node with the value received from the fetch call
          slot.textContent = datum;
        });
      });
  });
};

With this code, the UI will update after the fetch request is made.

Of course, this blog post does not cover every single bit of form handling. It aims to be an experiment to achieve something that I find very beautiful in another framework.

If you want to play with it in Stackblitz, give it a look:

https://stackblitz.com/edit/withastro-astro-lgq9es?embed=1&file=src%2Fpages%2Findex.astro

10 things about feature flags that will speed-up your workflow

Marvin — Wed, 26 Jul 2023 08:33:10 +0000

I used to work painfully with Gitflow and feature branches until I realised that what I really needed was Trunk based Development and feature flags.

Don't forget that the goal of a developer is to ship value and Gitflow/feature branches were slowing me down in this regard.

With trunk based development, I create very small branches that lives for a few hours, and each time I merge one in the main branch, the code is deployed to production. To protect users from accessing unfinished features, I use feature flags: each time I want to activate a feature, I just press a button.

How fast is that?

Here are 10 things about feature flags that will speed-up your workflow.

1. Separate code deployment from feature releases

You can deploy code 20 times a day, and all this code may not act as a fully polished feature. And it's okay because with feature flags, activating a feature to the audience is not tightly bound to your code deployment process: it's just a toggle button that you click in a dashboard to make the feature available to the users.

if (flags.newFeature) {
  return <NewFeature />
}

return <OldFeature />

2. Rollbacks are easy

Almost the same point as above: since the code deployed and the feature are not strictly bound, you can deactivate the feature with just one click and not go through your whole CI/CD pipelines to get back to a valid and running state.

3. Test directly in production

In most of the feature flags tools available in the market, you can decide which users can see the new feature and which users can't. It means that you can activate the feature only for your QA team and they will be able to play directly in production.

Side effect: no discrepancies between environment anymore, it's always the same servers configurations.

4. Unlock Canary and Beta releases

Using the same targeting tooling as previously explained, you can create a Canary users group and a Beta users group and activate the feature very early for them.

5. Gradual rollout

Let's say you've built a brand new feature, and you don't feel very confident about what you've created. With feature flagging tools, you can increasingly rollout your feature to 1%, 2%, 3%...100% of your audience.

Funny thing is that you can correlate the percentage of rollout with your error tracking tool (such as Sentry) and check if your new feature has increased your error rates.

6. The A/B testing side effect

Feature flags are generally used with "true" and "false" values: is the feature activated or not?

By pushing the concept one step further, we can give feature flags multiple values "A", "B", "C" (or whatever) and display different UI/UX of a given feature to a percentage of the audience. You can then measure the amount of actions taken on each of these different views and see which one converts the most.

7. Time based rollout

You have something to deploy on Monday at 9am? With feature flagging tools, you can automate that. Since, again, the feature and the code are not tightly bound, the code already exists in production: all you need to do is to create a rule in the dashboard of your tool and at 9am Monday, you'll see your new feature live.

8. No impact on web performance with Progressively

Progressively is a feature flagging tool and in contrary to other solutions, the client side SDK, that works in real-time, is only 1.3kB.

Stop fearing the slow page loading because of third party tools anymore.

9. Progressively with SSR and Edge Runtimes

The tool works with SSR frameworks such as Svelte, Qwik, Astro, Nextjs, Remix etc... You don't need to wait for the client side of your app to load and the page to flicker to benefit from a great experience with feature flags.

And if you want to work at an even bigger scale, try to use Progressively inside an Edge Middleware in Vercel ;).

10. Progressively is FREE

It's open source, and you can self-host it on your own servers. Go to https://github.com/progressively-crew/progressively, follow the instruction and spawn your instance on your own machine, for free.

And if you're not so much on self-hosting, there is a SaaS solution that you can pay to play with.

The page flickering when using feature flags and A/B testing tools

Marvin — Mon, 12 Dec 2022 14:01:06 +0000

As developers, we constantly strive to improve our applications. We fix bugs, implement new features, and prioritize user experience. These updates and enhancements are critical for the success of our applications and need to be rolled out in a timely manner.

Feature flags are an effective tool for minimizing risk and reducing lead time. By creating code behind a flag, we can seamlessly deploy updates and toggle the flag when the new feature is ready for release. This allows us to quickly and easily make changes to our applications without disrupting the user experience.

As with any technology, there are limitations to using feature flags (or A/B testing) in JavaScript applications, including those built with the JAMStack. One common issue that can arise is “page flickering,” which can be frustrating for both developers and users.

The “Page Flickering Problem”

Let me illustrate what is the “page flickering” problem:

The previous picture illustrates what happens when using feature flags (or A/B tests) in a classical JavaScript application, including JAMStack ones. Here are some explanations:

A user makes a request to a website
They get back the /index.html file of it (empty for client only application, and already filled for JAMStack applications)
The browser parses the HTML file and prepares every scripts it has inside
The website is now visible (empty or filled)
The frontend application kicks in and the site is interactive
The JavaScript application fetches the feature flags from the according (remote) service
It gets back the flags and updates the application, showing the new version with / without the flag.

In the previous picture, two bold-ish red squares are highlighted. Their written equivalences, which are also highlighted in bold, are explained in the text above.

My question is: For the end user, what happens between the moment the page is displayed and the moment when the flag resolves?

The answer: The old version, UI is moving, the new version, in that order.

How people generally mitigate this behaviour?

Hopefully, there are multiple solutions available on the internet to deal with feature flags so that you don’t have to (such as Progressively).

Spinners, loading indicators

To address the problem illustrated in the previous picture, one solution is to hide all the website’s content during the flag resolution and display a spinner or loading indicator. On subsequent page loads, the browser storage can be used to quickly show the correct variation and adjust over time.

While this solution may be suitable for applications and dashboards, it may not be the best approach for marketing websites where we want the pages to load instantly. In these cases, hiding the website’s content and displaying a spinner or loading indicator may not be acceptable.

Shifting resolution to the infrastructure layer

Upon closer examination, we can see that the problem stems from the fact that applications only run after the browser has already displayed the page to the user. Specifically, the script tags in the HTML document are only executed when the HTML document is loaded in the browser. This results in a delay between the time the user sees the page and the time the flag resolves.

However, there are things that run before, even if we don’t rely on a dedicated server that renders pages (think server side rendering).

The infrastructure layer is a place where we can do things, ahead of time.

I’ve written a post, some time ago, about A/B testing with the JAMStack and how we can achieve this at the infrastructure layer.

Using Server Side Rendering

By recognizing that the problem is caused by running the flag resolution in the browser, we can instead move this resolution back to the server.

With tools like Next.js, Remix, or any other framework that supports it, you can generate the valid HTML document for each request, with the content behind a flag variant already resolved.

Progressively can also assist in this situation.

What would be the best way to fix this issue?

This is subjective, and my personal opinion. It mostly target situations with high traffic where hitting the server hosting the application might cost a bunch of money.

Just as I design APIs by first defining the desired outcome and then implementing the details, I will first specify what I want and how to achieve it, keeping in mind that client-side only and JAMStack applications may not behave as desired. This approach allows me to design the solution before diving into the details.

What I want:

A website that does not blink
A website that does not cost a lot of money
A fast website

A website that does not blink

One solution to this problem is to use a technology that employs Server Side Rendering. With this approach, the page is generated on the server and delivered to the user in its completed form, allowing for instant display in the browser. This can greatly improve the loading speed and overall performance of the site.

My preferences for my ideal world would be Next.js, I will explain why, but you can use any tool that supports SSR, it will work great.

A website that does not cost a lot of money

The JAMStack is truly amazing, especially when paired with a free CDN like Github Pages. Plus, it won’t cost a dime!

But on the other hand, the use of a Server Side Rendering tool would require some expenditure. However, with the help of a CDN and aggressive caching of requests to reduce the load on the origin server, which is the costly part, it can be made affordable.

1, 2, 3…

The introduction of the CDN has just broken the feature flags functionality. This is because the CDN caching is applied at the URL level, so when requesting https://website.com/, all the audience will receive the last version cached by the CDN.

However, it exists solutions such as Edge Middlewares in Vercel that allow to run code before reaching the CDN cache, at the edge. And this is a perfect place to resolve the feature flag (and A/B tests) variants.

If you are interested, this blog post shows how to use Progressively and Vercel Edge Middleware together.

A fast website

A Server Side application is now being run at the edge on Vercel, with feature flags being handled at the edge using Edge Middleware and cached by a CDN.

This technology stack is known for its speed.

The last mile

Remember my decision to use Next.js earlier? The reason is because, as mentioned earlier, CDN caching can only work at the URL level, and the same is true for edge middlewares. You can’t modify the internal of the document in edge middlewares since they run before the CDN cache.

But one interesting thing that came in Next.js 13, are the support of React Server Components (RSCs). As the name suggests, RSCs run on a server, somewhere, and are probably available through a URL.

What if, in the future, Edge Middlewares were able to process only requests that would aim to resolve RSCs?

Feature flags at the edge with Progressively and Vercel (recipe)

Marvin — Wed, 23 Nov 2022 06:59:07 +0000

There is a glossary at the end of the article if you are not used to these terms.

If you don't want to set up the whole thing, a Nextjs application showcasing this is available on https://github.com/mfrachet/progressively-edge-middleware

Summary

🧀 Ingredients
👨‍🍳 Directions
- 1. Create a feature flag in Progressively
- 2. Create feature flag variants
- 3. Create a Nextjs project
- 4. Create pages matching the previously created variants
- 5. Install Progressively sdk
- 6. Create the middleware file
- 7. Push the code on GitHub
- 8. Run the project on Vercel
📚 Glossary
- Feature flags
- Progressively
- Vercel Edge Middleware

🧀 Ingredients

A running instance of Progressively
A personal Github account on Vercel
Node.js > 16

👨‍🍳 Directions

1. Create a feature flag in Progressively

Create a new project in the dashboard of Progressively (/dashboard/projects/create)
Click on the Production environment that has been created
Keep the environment key close, we'll need it in the next step.
Click the Create a feature flag button and fill out the form

2. Create feature flag variants

Once the flag is created, click on its name in the table
On the feature flags page, Click on Variants
Add 3 variants named A, B, and C, and adjust the percentage to your taste

3. Create a Nextjs project

Run the following command somewhere on your computer:

$ npx create-next-app@latest

4. Create pages matching the previously created variants

In the ./pages folder, create three files called index.ts, b.ts, and c.ts with different content inside.

5. Install Progressively sdk

Run the following command at the root of your Nextjs project:

$ npm install @progressively/server-side

6. Create the middleware file

At the root of your Nextjs project, create a middleware.ts (or .js, depending on your preferences) and copy the following code in it:

import { NextResponse } from "next/server";
import { getProgressivelyData } from "@progressively/server-side";

const PROGRESSIVELY_URL = "PUT YOUR SERVER URL HERE";
const PROGRESSIVELY_ENV = "PUT THE ENVIRONMENT KEY HERE";
const ExperimentRoutes = {
  A: "/",
  B: "/b",
  C: "/c",
};

type ExperimentRoutesKeys = keyof typeof ExperimentRoutes;

export default async function middleware(request) {
  // Get the user ID from cookies in order to always show them the same variant
  // If showing the same variant to the same user every time is not a concern for you, you can remove this line
  const id = request.cookies.get("progressively-id");

  // Get the feature flags from Progressively
  const { data, response } = await getProgressivelyData(PROGRESSIVELY_ENV, {
    apiUrl: PROGRESSIVELY_URL,
    fields: {
      id: id?.value || "",
    },
  });

  // Checking that the progressively servers brings us a valid first user id
  // If showing the same variant to the same user every time is not a concern for you, you can remove this line
  const progressivelyId = response.headers.get("x-progressively-id");
  if (!progressivelyId) return;

  let nextRawUrl =
    ExperimentRoutes[data.initialFlags.newHero] || ExperimentRoutes.A;

  const nextUrl = NextResponse.rewrite(new URL(nextRawUrl, request.url));

  // Stick the user ID to the cookies in order to always show them the same variant
  // If showing the same variant to the same user every time is not a concern for you, you can remove this line
  nextUrl.cookies.set("progressively-id", progressivelyId);

  return nextUrl;
}

export const config = {
  matcher: ["/"],
};

7. Push the code on GitHub

Create a repository on GitHub and push the project.

8. Run the project on Vercel

Connect to your Vercel account using GitHub
Select Add a new... and then Project
Click on Continue with Github
Select your repository and click Import at the end of the line
Fill out the form and click Deploy

You now have a Nextjs application, working on the edge using feature flags in Progressively.

NB: if you want to see the different variants when refreshing, make sure to clean your cookies 😉

📚 Glossary

Feature flags

Feature flags are a technic allowing to progressively rollout features without modifying code at the moment of the release.
They generally take the form of a switch button that you can toggle on and off.

For instance, you may have created a new fancy UI for your login page, but you want to make sure you don't have errors on it that could block your users from accessing your platform. With a feature flagging tool, you can show this new page to N% of your audience, and augment this percentage while you acquire confidence until everybody sees the new page.

Progressively

Progressively is a free, simple, accessible, lightweight, self-hosted and Open Source feature flagging tool that you can use to rollout features to your users.

Vercel Edge Middleware

Vercel Edge Middleware is code that executes before a request is processed on a site, and before the CDN cache is hit.

They are a very conveniant place to handle A/B testing and feature flagging using page redirections, without content flashes.

A/B tests & feature flags, what do you love and what do you hate?

Marvin — Tue, 22 Nov 2022 15:04:11 +0000

Hey folks,

I m a huge fan of feature flags and technics allowing to ship features more efficiently to the users.

And I m very interested to hear your stories on how you use these tools to ship better features for your audience.

What is the most interesting metric that you rely on and that tells you "hey, this is what we should provide to the users"

Let me know everything about your experiences!

A/B testing with the JAMstack

Marvin — Tue, 28 Dec 2021 08:03:45 +0000

The JAMstack has been talked about in recent years like a way to create static websites that scales very well in many different ways.
Since it becomes more and more mainstream, it made sense to people to think about how to apply older patterns that we like in this
quite particular context.

In this post, I will share with you my vision of A/B testing (or feature flagging, everything written below may apply to both) using the JAMstack.

But first, why do we use the JAMstack?

According to jamstack.org, we use it because:

it's about building simple static pages (HTML files)
most of the job is made at build-time, no potential leak at runtime, it's more secured
static pages are basically HTML files and thus load very fast
we benefit from cheap hosting (putting files on a server and there we go)
it's highly scalable, just put the files on another machine and scaling is done
it already exists great tools to create amazing sites (Gatsbyjs, Nextjs, 11ty, etc...)

Why do we use A/B testing?

People use A/B testing to measure which variant of a website is more appreciated by their users. The idea is simply to provide different visual representations of some data and check which one attracts more people.

If the visitors of the variant A come more often than the visitors of the variant B, then we can assume that variant A is a more viable solution to represent the data on the page.

How do we use A/B testing in non JAMstack applications?

In applications that are not built on top of the JAMstack, the idea is quite straightforward.

When opening the application, it will make a request to a remote server to get the different available variants. Then, based on some conditions in the codebase, we are able to display the good variant to the good user.

The following is an example of a client-side A/B test written with Reactjs:

const App = () => {
  const { variant, isLoading } = useABVariant();

  if (isLoading) {
    return <p>Preparing the application...</p>;
  }

  if (variant === "A") {
    return <div>Here's the A variant!</div>;
  }

  return <div>Here's the B variant!</div>;
};

As we see in the snippet, the code is executed in the user's browser. Also notice the loading information while the request is pending before being able to display the variant content.

The following is a tiny sandbox allowing to switch on and off a feature flag to display a new variant of a homepage. When using services like LaunchDarkly, this is exactly the kind of actions you're provided with.

Why A/B testing on the JAMstack is different?

Remember one of the main arguments of building on top of the JAMstack is fast page loading (performance).

When dealing with A/B tests the "standard way", we need to make an HTTP request to get the different variants. Making an HTTP request means that there is a delay between the moment we ask for the variants and the moment we get them back from the server.

The problem is that making the HTTP request is so critical that we can't show anything else than a loading information to the user before resolving the variants and being able to show them the good content.

In a static environment, we are waiting for a dynamic information to display meaningful information.

When A/B testing the "standard way", using runtime information will make the application performances worse by increasing the time for displaying the first meaningful content. Loading static pages should be "instant" but relying on an HTTP request and an intermediate loading state before displaying the content will take extra time and decrease the experience.

In some scenarios, Lighthouse performance score can drop by around 25 points (up to you to determine if it's significant or not).

Also note that some tools helping building applications using the JAMstack don't even run JavaScript at all, meaning that it's not possible to rely on HTTP requests to access remote data at runtime.

How to make A/B testing in a JAMstack fashion?

The JAMstack is about building static pages. Taking this notion to the extreme, we can imagine creating a dedicated set of static pages for different variants and host them in different places, like for example, different machines.

The machine 1 owns all the statically generated HTML pages impacted by the variant A and the machine 2 owns all of the statically generated HTML pages of the variant B.

Since pages are statically generated at build time, we can rely on environment variables to display the good variant content:

const AB_EXPERIMENT_VARIANT = process.env.AB_EXPERIMENT_VARIANTS;

const App = () => {
  if (AB_EXPERIMENT_VARIANT === "A") {
    return <div>Here's the A variant!</div>;
  }

  return <div>Here's the B variant!</div>;
};

The next step is to rely on some kind of proxy to route the different users to one of the two variants and make sure they always see that variant.

Remember, we can't rely on runtime information to store the variant, like an authenticated user id for example. We need to rely on something else. Hopefully, HTTP Cookies exist that allow for a client-server kind of data sharing. We can benefit from them to store the actual variant requested by the user and make sure that they will always get routed to that variant.

Observations on this approach

The first observations to push upfront is that we have kept the page loading performances provided by default by the JAMstack. We don't have to wait for runtime computations to display content on the page.

The second observation is about the tradeoffs we decided to make: we shifted the A/B testing responsibility closer to the infrastructure layer. The proxy has an important role to play in this scenario.

Also note that we need more "places" to put the different variants: 1 variant corresponds to 1 website that corresponds to 1 set of static pages that should entirely be hosted. The more we have variants, the more we may pay for hosting:

There's also one side effect that I find positive (but it can feel negative) is that it can be hard to combine multiple A/B experiments.

Let's say that we have 2 pages and that we want to run an experiment on both the pages:

What can be a visual representation of these scenarios at the hosting level?
Should we create 4 different websites, one for each variant?
Should we create N different websites with combinations of variants?

My expectations is that there will be solutions allowing to make A/B testing at the file level itself, and not at that site level.

References

If you're using Netlify for hosting your websites, they have a feature called Split-testing that allows for these kind of testing using a branch based approach.

If you have any other references in mind concerning A/B testing or Split Testing on top of the JAMstack, feel free to drop them on Twitter.

Right in my dev shoes

Marvin — Thu, 22 Apr 2021 08:10:28 +0000

Working in the web industry is like a gift and a curse to me. On one side, I'm increasing my situation and making money doing something that I love and on the other side, I'm seeing an increasing amount of things that I don't agree with but that becomes quite the norm — and it feels bad to be part of that without doing anything.

Why am I feeling that way?

Earning money when running a business is, hopefully, normal and evident. Earning more money every year is a sign of good health for a company. Problems arise when, to make money, people cross the ethical frontiers.

The following is a non-exhaustive list of questions that raises ethical problems to me and that I would like to share with you.

How many companies gather personal information about people to compute them and make money from them?
How many of those companies are considered examples for younger developers?
How many women are less paid than their men peers?
How many people don't have valid experience on the web because of inaccessible content?
How much energy do we spend running all those services in the cloud?

Every single question in this list deserves an entire book to get proper answers.

Keep in mind that this post is not about blaming people that are not aware of the problems. It aims to make them realize that these things are not okay per se and that they should be addressed.

How to fix that?

The answer is simple on the paper, but very hard in practice: we have to care. It's not about just knowing and putting the problems somewhere in our heads and "remembering to tackle them later". We have to be aware and act concretely.

Choosing tools and services that respect people's privacy

For instance, if we need to get audience information about our websites, what about using tools that respect people's privacy? Plausible.io is one of them and it allows to get that information without the need for private data (there are others, it's just the one that I use, I don't have any bindings with the company).

On the consumer side, if you don't agree with some companies' policies (you may have heard of some kind of new tracking technics recently), Privacy Tools is a great website giving practical advice, suggesting services and tools to reduce your privacy exposure.

We're not forced to use (or to be the victims of) tools from mastodons that keep track of users' moves, through our websites, making us at least, partially responsible.

Equity

The second point is about gender equity — and I should say equity in general.

If by any means, we spot a salary discrepancy between two people doing the same job, discrimination, or even harassment, we have to bring the problem up. We're not forced to react intensely, we can gently raise the flag and create a discussion. But it's important to raise that flag. We have to communicate, try to understand and find a way to fix the problem.

We should not hesitate to be vocal and to support our colleagues when they need us, let's offer them our help, and manifest ourselves to improve the situation. Multiple voices have more impact than a single one from a person that faces professional difficulties.

Hiding and keeping information because we don't feel concerned (or not comfortable) is selfish and unethical. It contributes somehow to keeping this problem real but also hidden.

Embracing Accessibility

The third point is about accessibility. I can't say how grateful I am to have been introduced to it by Amberley and Madalyn.

One amazing effect of accessibility is that when you learn enough of it, you immediately become an advocate and can't do without it. Accessibility is an ethical topic where everybody should be provided with a frictionless user experience when using a service or a tool — and it does not only apply to people that can see what's happening on a screen.

The biggest problem with accessibility, to me, is that the number of people who have already built a truly accessible website is very low. I don't blame anyone for not having this knowledge, I have personally never heard of it in school nor during my first 6 years working in the industry. But it's important to be aware of it, to educate ourselves, and to learn more about it.

If you're not familiar with accessibility, I suggest reading Accessibility is a priority published by one of my colleagues that provides practical wins to make your website more accessible. Also, I highly recommend spending time on A11y Coffee to completely dive into the topic.

We have to keep in mind that making our websites more accessible is a game-changer for more people than we think, we and our companies included. Not making this is, to me, as serious as discriminating a whole population.

Ecology, green IT

The last point of my bullet list is about energy consumption.

It's a very tough topic since our job is to build things running on electrical devices and so, our creations consume a certain amount of energy, often time 24/7. We live in an era of over-consumption and as technical people, we love innovation. The thing is, sometimes, innovation creates more indirect or invisible problems than it solves.

We obviously have to change the way we consume, reducing wasting, making sure our electronic devices (that are built using a gigantic amount of natural resources) reach their lifespan before getting new ones.

Concerning our web creations, two things can be done to reduce their footprints: hosting them on a "Green Hosting" provider that has a low PUE and using the right tools for the right job. What would be the real advantages of building a blog with a server-side technology on a whole Kubernetes cluster to only serve a few posts?

Also, if you come from the React ecosystem, I've written a post about the different rendering strategies I would adopt depending on the circumstances that help me avoiding server-side rendering when I don't need it. And for French people, Green It proposes workshops and books about improving website footprints at the code level.

On the auditing side, I've recently discovered two tools to measure, or at least to provide an order of growth, of the energy consumed by a website: WebsiteCarbon and Argos. I don't have that much feedback on them but the intent deserves at least respect and encouragement.

The internet accounts for around 4% of the greenhouse gas emissions which is the same amount as the whole airline industry.

Educating, teaching, learning

I voluntarily skipped the second point in the list and it's, for me, probably the most important.

Younger developers may dream of fame and be part of an elite, wanting to join big companies because "they are the place to be". There is nothing wrong with that but there are some correlations between some topics addressed in this post and some companies that people are dreaming to join.

To make sure we don't commit to the same errors as we did in the past such as encouraging innovation in potentially ethically discussable directions, I think it's our role, as more senior developers, mentors, and older adults to sensitize youngers and to educate them to reduce this kind of problems in the future, making them "exceptions" and not the norm.

And hopefully, we should educate ourselves, too, because, you know, it's not the fault of the others.

How do I choose which SSR strategy to adopt?

Marvin — Tue, 26 May 2020 13:27:18 +0000

This is crossed posted on my personal blog: https://mfrachet.github.io/how-do-i-choose-a-ssr-strategy

Also, this post is opinionated and based on my personal experience. It's not a source of truth, just the way I approach SSR on my daily job.

Server Side Rendering (or SSR) is a big trend. In the React ecosystem, we have plenty of tools that rely on it such as Gatsbyjs or Nextjs.

Before getting further, let's see what happens when a user makes a request on a site that is not built using SSR:

The browser makes a request on a specific endpoint
It downloads an empty HTML file that only owns a bunch of <script> tags to load some JavaScript code
It resolves / parses / compiles the JavaScript code
It executes the JavaScript code and only then the application can display the content

This is how the good old Angularjs or JQuery applications were working. And this is also what happens when we use create-react-app.
We say that these applications rely on "Client Side Rendering" (or CSR).

Why SSR has been invented?

When building an application using CSR, we always have to wait for the JavaScript code to be resolved / parsed / compiled / executed before displaying anything on the screen.
The JavaScript application is responsible for filling the HTML file dynamically in the browser.
And this can be problematic because:

CSR applications are not optimized for SEO (SEO works, but it's a bit more complicated)
We don't benefit from a good media sharing experience
Displaying the first meaningful content or wait for the application to be interactive can take time when the application is big

I remember having worked on Angularjs applications back in 2013 where it could take around 10 seconds to display the first content on the page.

How does it solve these problems?

The main idea behind SSR is to generate HTML content and display it to the user the sooner. HTML is easy to understand for browsers, they know how to execute it really fast.

This way, when a user navigates:

The browser makes a request on a specific endpoint
It downloads an already filled HTML content and can already display it to the user

Which is good enough to solve the 3 problems we had:

- CSR applications are not optimized for SEO
+ HTML is optimized for SEO

- We don't benefit from a good media sharing experience
+ Pre-filled HTML owns the necessary meta to have a good sharing experience

- Displaying the first meaningful content or wait for the application to be interactive can take time
+ Displaying HTML content is probably one of the fastest thing a browser can do

This is the most basic idea behind the term SSR and with this in mind, we can create complex and powerful mechanisms (non-exhaustive list):

Runtime SSR

Start a NodeJS server
When a request is made, render static HTML content (string format)
When the browser is ready, start a client side application for interactivity
Tools: Nextjs

The first way to rely on SSR we've seen in the React community. Can be complex to put in practice and costs money:
one or several NodeJS servers have to be running in production to manage the requests.

Static Generation

At build time (when running npm run build or yarn build)
Generate as many HTML files (.html) as necessary
When a request is made, render the associated .html file
Tools: Docusaurus, 11ty
Performance case study by Netflix on the landing page

Common in the documentation / blogging area where interactivity is not required. Tools take something like Markdown content in input and create
the associated .html files as output. Not too complex to use in practice, not expensive thanks to CDN hostings.

Build time SSR / Pre-rendering

At build time (when running npm run build or yarn build)
Generate as many HTML files (.html) as necessary
When a request is made, render the associated .html file
When the browser is ready, start a client side application for interactivity
Tools: Gatsby, Nextjs

Probably my favorite of all the listed solutions. Very scalable, highly interactive, not too complex to use in practice and not expensive thanks to CDN hostings.

How to choose?

This is where it gets tricky.

Choosing a strategy is not about finding the best solution. It's about evaluating trade offs and taking the
technic that provides the most benefit in our context than it provides drawbacks.

Also, I'm feeling that the last few years we tend to use SSR almost everywhere and as much as we can.
While it's an amazing tool that helps in many situations, I think
we should keep in mind that it's just a tool - not a silver bullet solution. If we don't face the problems it's supposed to solve, I'm not convinced we should introduce it in a project.
Remember that introducing SSR is not free, it has a technical cost and a potential infrastructure cost.

Finally we don't have to choose a single way of building an app: we can cross the ideas and create a system that provides the best user experience in our scenario.

The following diagram is one of the mental representations I'm using to determine when I would consider using a technic over another one in a given situation. It's not a source of truth at all.

A tale of bounded components

Marvin — Wed, 31 Jul 2019 18:18:02 +0000

Building reusable UI components is hard. I always rely on an iterative approach and write my component 2-3 times before getting something that I find useful and reusable across my applications. It's kind of a game to find the "good" abstraction and the "good" way to create them.

In A note on composing components with React, I've briefly talked about my conception of composition by taking the example of Google Material Design Cards and how I would have implemented such a thing. This post is an extension of the previous one so I recommend you take a look ☺️.

Today I want to share with you my experience while implementing a UI component library based on a design system and how my team and I have managed to build a bit more complex components.

Let's talk about components that share something.

Radio buttons

I'm going to take the example of radio buttons and this for two reasons.

The first one is that I'm building the UI component library with React Native and that it doesn't provide a built-in Radio component and the second one is because radio buttons are kind of special.

By definition, it's a group of selectable elements where only one element can be selected at a time. Here's a quick link to the MDN definition of radio and radio groups.

In HTML this link is represented by the input name attribute:

// this is from MDN

<input type="radio" name="contact" value="email">

<input type="radio" name="contact" value="phone">

<input type="radio" name="contact" value="mail">

I think that we can call these compound semantic elements

If we want to build React components that matches the previous definition of radio elements, these components have to share some information with some other ones.

In the React world, we can say that these components are sharing some state.

To manage this kind of shared state, we can rely on different approaches.

Through the parent state

The simplest thing to do in a React world is to rely on the parent component state.

Let's imagine the following snippet:

const Parent = () => {
  const [selectedRadio, selectRadio] = useState(0)

  return (
    <>
      <Radio onPress={() => selectRadio(0)} isSelected={selectedRadio === 0} />
      <Radio onPress={() => selectRadio(1)} isSelected={selectedRadio === 1} />

      <Text>The selected value is {selectedRadio}</Text>
    </>
  )
}

This is a fine approach and it works as long as we accept to manage the state of the <Radio /> components in every of their parents.

However, in this code, there is something that we lost: the linked nature of radio buttons. Or at least the family link of the radio elements.

Of course the selected value will be reflected thanks to the parent state. But the radio group is dependent on the parent and not only on itself. On the web platform for example, there are no parent to manage the link between the elements.

Using a global state management tool (let's say Redux)

We can also rely on a global state management tool that will store the actual selected value and provide it across the app:

const mapStateToProps = (state, ownProps) => ({
  isSelected: state.selectedRadio === ownProps.name,
})

const mapDispatchToProps = (dispatch, ownProps) => ({
  selectMe = () => dispatch({ type: 'SELECT_RADIO', payload: { newSelectedRadio: ownProps.name } })
})

const RadioEnhanced = connect(mapStateToProps, mapDispatchToProps)(Radio)

const Parent = ({ selectedRadio }) => (
  <>
    <RadioEnhanced />
    <RadioEnhanced />

    <Text>The selected value is {selectedRadio}</Text>
  </>
)

This is also a fine approach and it has the benefit of keeping the linked nature of the Radio element using the global state.

However, we have to define a new Redux key in the store for every different kind of Radio component. We also have to create a reducer for each kind of Radio groups and so forth. And this will be the same even if you don't use Redux but an other global state management system.

React's context API

I often hear that using the React context is a bad practice. I don't totally agree with this statement. I think that we have to understand when not to use it and to use it sparsely. The context is a feature that is built in in React, so they may probably be some good use-cases for it.

What I suggest before writing any component implementation is to imagine your ideal way to use that component. I often start by writing the shape I want it to have (its API), let's say:

const MyComponent = () => {
  const [selected, setSelected] = useState('first')

  return (
    <RadioGroup selected={selected} onChange={setSelected}>
      <Radio name="first">
        <Text>My first radio</Text>
      </Radio>

      <Radio name="second">
        <Text>My second radio</Text>
      </Radio>
    </RadioGroup>
  )
}

I like this kind of API because it's straightforward to read.

This code represents a group of radio components that act together. When the <Radio name="first" /> is selected, every other radio components in the RadioGroup children tree will be unselected.

The selected prop of the RadioGroup component corresponds to the name of the selected radio component. If I want to select the first radio then the code will look like <RadioGroup selected="first">...</RadioGroup>.

We can create this behavior and feeling of link using React's context API where the RadioGroup component owns the actual selected name in its context and share it across its different Radio children.

This technique of hiding the state management between components is called implicit state passing. We manage the state in a way the developer doesn't have to care about and does not have to implement multiple times.

Here's a running codesandbox of the Radio and RadioGroup implementation.

We now have a good understanding of the React context API. Let's explore another advanced function of React that also allows to pass some implicit states through another example: the Tabs one.

The `Tabs` example

In my posts, I'm talking a lot about the Tabs example that Ryan Florence has provided in this video. It's this video that made me realise that I was doing some things wrong and that I had to understand the "composition" concept.

Tabs are UI elements that define (UI) interfaces sharing a visual link. They have to be close to each other to provide a good user experience. It doesn't make sense to create a tab at the top left side of the device with another one at the bottom right side.

I like to put Tabs in the category of layout components: they are not really business oriented nor atomic UI components. They represent a way to display information and how to navigate between different types of information.

We can imagine this components using multiple approaches and one that often comes and that I used to work with was the data driven approach.

Data Driven approach

A data driven approach is a way to build components so that a component requires its props to have a specific shape to be used. For example:

const items = [
  { title: 'First', Component: () => <div>First</div> },
  { title: 'Second', Component: () => <div>Second</div> },
]

const Tabs = ({ items }) => {
  const [selected, setSelected] = useState()
  let SelectedComponent

  if (selected) {
    SelectedComponent = items[selected].Component
  }

  return (
    <div>
      {items.map((item, index) => (
        <div
          key={item.title}
          onClick={() => setSelected(index)}
          style={{ color: selected === index ? 'green' : 'black' }}
        >
          {item.title}
        </div>
      ))}

      {SelectedComponent && <SelectedComponent />}
    </div>
  )
}

// would be used <Tabs item={items} />

In this example, the Tabs component knows the shape of each of its item to be able to display them correctly. It's a contract between the object and the component.

While it's okay to work using this approach, I think that it's good to think of a way to avoid this kind of tight coupling. Composition can help to achieve this.

As I have mentioned before, let's image our perfect world API. Something like the following one looks great to me:

<Tabs>
  <TabsHeader>
    <TabHead>First button</TabHead>
    <TabHead>Second button</TabHead>
  </TabsHeader>

  <TabsBody>
    <Tab>
      <FirstComponent />
    </Tab>
    <Tab>
      <SecondComponent />
    </Tab>
  </TabsBody>
</Tabs>

Using React, how can we create the different TabXXX component so that it works this way?

We could have done this using the context API, but for now, I want to introduce the React.cloneElement function.

React.cloneElement

This function allows to clone a React element with its actual props with the possibility to override them or to add new ones.

It can be used as following:

const element = <div>Hello world</div>
const clone = React.cloneElement(element, {
  style: { backgroundColor: 'red' },
})

const App = () => (
  <>
    {element}
    {clone}
  </>
)

We will use this definition of the React.cloneElement function to provide some props to the children of a component, implicitly.

For example, we will add a props to the TabHead components so that they become clickable.
We will also add a selectIndex prop to the TabsBody component so that he knows which component has to be displayed or not.

Implementing the `Tabs` component

The Tabs component is the owner, the one that knows everything. It owns the actual selected index and knows how to modify that selected index:

const Tabs = ({ children }) => {
  const [selectedIndex, setSelectedIndex] = useState(0)

  return React.Children.toArray(children).map(child =>
    React.cloneElement(child, { selectedIndex, selectIndex: setSelectedIndex })
  )
}

In this case React.cloneElement enhances the child component by adding them two props: the actual selected index and a way to modify that selected index.

In fact, we'll pass down these two props respectively to the TabHeads and the Tabs.

The TabsHeader component will receive the selectIndex function and will pass it down to its TabHead children with a subtle variant: we'll scope the actual index of the TabHead component so that they can call the selectIndex function without passing their index explicitly:

const TabsHeader = ({ selectIndex, children }) =>
  React.Children.toArray(children).map((child, index) =>
    React.cloneElement(child, { selectIndex: () => selectIndex(index) })
  )

TabHead will simply look like this:

const TabHead = ({ selectIndex, ...props }) => (
  <button onClick={selectIndex} {...props} />
)

The TabsBody role is to display only the element that matches the selected index. This can be achieved using Array.prototype.find on the children:

const TabsBody = ({ selectedIndex, children }) =>
  React.Children.toArray(children).find((_, index) => selectedIndex === index)

Here's a link to a codesandbox of the previous snippets.

I suggest you take some times to analyse and get familiar with this kind of code. It's something that I wasn't used to before diving into it.

So there we are, these are examples with some explanations of more complex and linked components!

How is the React lazy function implemented? Suspense... It gonna be short 😉

Marvin — Tue, 30 Jul 2019 19:20:58 +0000

It's been a time since the React's team has introduced Suspense and concurrent rendering. With hooks, it's the new amazing feature that React is providing.

We are "able" (at least in dev-mode) to:

create applications that manage specific priorities over our asynchronous operations
manage asynchronous computations just like if they were synchronous
use functional components everywhere instead of classes

I'm really excited about the future of React!

And today, I wanted to talk about a Suspense specific feature which is the lazy function that was introduced in React v16.6.

This function aims to provide a simple way to rely on bundler's code splitting using some code like:

import React, { lazy, Suspense } from 'react';

const LazyComponent = lazy(() => import('./components/myComponent'));

const App = () => (
  <Suspense fallback={<div>Waiting...</div>}>
    <LazyComponent />
  </Suspense>
)

What the?..

It can be a bit disturbing at first, how can we:

code split our code, which is a build time feature
make an asychronous computation that creates a component
use an (async?) component in a render function which aims to be synchronous

using 2-3 lines?...!

Suspense...🤯

This is not that magic and can exist thanks to the Suspense component.

This component is a bit special and whenever you will throw a Promise in one of its children, it will catch that promise, resolve it and re-render its children.

Did you know that you were able to throw something else than errors in JavaScript?!

This is why it's called Suspense: it suspends the normal execution flow of your application thanks to the throw keyword, and make some specific computations before "resuming" it. It doesn't resume it at the exact position of your code, but at least, it re-renders its children which make you feel like you were getting back to the old execution position.

I tried to write about it in this Medium post but without success - my thoughts at that period were not that organised.

I won't keep the "suspense" for now, so let's check one implementation of the lazy function I've came across:

import React from "react";

let IDS = 0;
const loaded = {};

export const lazy = modulePathResolver => {
  const id = IDS++;

  return props => {
    const LoadedComponent = loaded[id];

    if (LoadedComponent) {
      return <LoadedComponent {...props} />;
    }

    throw modulePathResolver().then(lazyModule => {
      const Component = lazyModule.default;
      loaded[id] = Component;
    });
  };
};

It's available on github gist if you want to play with it.

Obviously, this snippet only works if the component is used inside a Suspense parent.

The lazy function accepts one argument modulePathResolver which is a Promise that resolved the module containing your lazy component.

The lazy function returns a function which is in fact a (functional) component. All the references to id exist only to make sure that the component has only loaded once.

If you take a closer look at the code, it really looks like a cache system, but instead of setting the cached value directly, it throws a promise that wraps the cache setting so that the Suspense parent can resolve it, lazily.

And you know what? Since it's an asynchronous operation, it can take some time to execute, milliseconds, seconds or even minutes. And what is displayed during the asynchronous resolution? The fallback prop of the Suspense component is displayed! Nothing more!

And now, what?

You have an idea of the way the lazy function is working but you also now know how Suspense is working. You can now imagine every kind of asynchronous resolution without creating isLoading states everywhere, every-time. What about lazy image loading with low-high quality pictures 😉?

Jared Palmer is really good advocate of this and has talked about it in multiple talks he has given like the one at Chain React 2019

My point on this feature is that it also pushes the side effect computations we use to make to the edge of our applications. We can make asynchronous stuff using synchronous APIs without headaches. It makes me think of monads and the capability to isolate and compose what causes (side) effects with trivial code.

Isn't this pretty cool?!

Happy coding everyone! React has some beautiful days to come! 🚀

Understanding the React Native bridge concept

Marvin — Fri, 28 Jun 2019 12:04:56 +0000

And why its architecture is awesome, at a top level.

React Native is often presented as a game changer that allows to run JavaScript code inside a mobile environment. Its main strength is that it doesn’t rely on webviews like other competitors (Phonegap, Ionic, Cordova…, but on the actual real materials provided by the different platforms. It has built-in access to all the native views and components, and to about 70 specific device APIs by default (you can extend it).

When writing React Native apps, we build native UIs. And that’s the key point, we create UIView instances just like we would have with platform specific languages:

My first assumption on this framework was something like:

They probably create an AST from the JS code and transform it to make it run on multiple devices.

That would make sense and that’s actually what Google/Flutter does while building apps (with Dartlang). But that’s not the React Native way.

The main problem with this approach is that targeting platforms for compilation based on JavaScript code would imply the creation of new compilers. I don’t know any existing tool accepting JavaScript as entry code that is able to produce code for every targeted platform (eventually see Jasonette).

But what currently exist are compilers that target their own specific platform. For example, we have compilers that accept Java / Kotlin code and target Android platform, or Obj-C / Swift targeting iOS platform. It exists many compilers for different languages and targets. They do their job well because they have been designed to create optimised artefacts for them.

React Native is built in such a way that it uses existing compilers:

It’s built with a really opened architecture that allows the code to be run, not only on mobile devices, but also on other platforms:

It can also be used with other frameworks:

Weex, a React Native port of Vuejs.
a custom Angular renderer that allows to run ng apps in devices, with React Native.

So how did the team build such a framework, that is platform and framework agnostic, by using the existing tools & compilers?

Multiple realms interacting, nothing else

Let’s take a step back and look at the big picture of React Native.

React Native deals with two realms, the JavaScript one and the Native one. Both of them are able to share information. They communicate using a “bridge”, which is definitely the very heart of the React Native architecture, the part that offers so much flexibility.

The bridge is the concept that provides a way for bidirectional and asynchronous communications between these two universes. What’s important here is that they are completely written in different technologies, but they are able to communicate.

Remember your backend side

Let’s remember when we were coding distributed backend applications with multi-service communications.

How do we manage communication between two services that are completely different at a language/platform level ?

We used interoperable languages, such as JSON or XML, and we relied on asynchronous protocols such as AMQP (or any other like Kafka).

If we want these two services to communicate, we rely on a message queue. The first service pushes some commands inside the queue and the other one has to execute these commands when possible.

React Native behaves the same way. The JavaScript realm sends asynchronous JSON messages describing the action the Native part is supposed to accomplish.

For example, the JavaScript side will send information concerning the views that must be created by the Native side. When the Native side is ready, it will effectively create the views:

In React Native, the bridge endorses the message broker role, handling asynchronous commands between the two different worlds.

It offers multiple possibilities:

since it’s asynchronous, it’s non blocking, and therefore allows for smooth view management on the screen (~6O fps is the React Native golden goal)
since it’s decoupled and based on interoperable languages, it’s wide open to other frameworks and rendering systems provided that they respect the React Native bridge command interface

The more the bridge’s language is ubiquitous and universal, the more the possibilities are… and it is indeed!

The bridge implementation

The bridge is built in C/C++ and thus, can be run on multiple platforms, OS etc...

It embeds the Apple JavaScriptCore framework in, which exposes APIs to access the actual JavacriptCore VM capabilities. Many people use these APIs on the Obj-C and Swift world. But there is a C API, and the Obj-C one is actually just a wrapper.

With this in mind, JavaScript code can be run inside a C/C++ program. It can inject variables, functions and declare globals to enhance the JavaScript existing code. React Native relies on this kind of magic to make JavaScript communicate with the native world and thus trigger actions in the C/C++ world.

Injecting stuff inside the JavaScript code also means that functions can be executed by the C/C++ code.

This diagram quickly sums up how the JavaScript world is able to deal with the C/C++ one:

The native side

The communication on the native side is “the easiest” part.

Let’s begin with the iOS platform. Since Obj-C is an extension of the C language, it can communicate with it natively. This way, exchanges between the bridge and the Swift / Obj-C world are easy and natural.

On Android, we need to rely on the Java Native Interface to dialog with the bridge.

Here’s an old but really awesome and deep post explaining how the bridge is implemented on iOS by Tadeu Zagallo.

Let me know if you have further questions regarding React Native internals. I’ll try to provide all that I know on the topic.

Thanks to my mates @Zenika and @M6Web for the reviews!