DEV Community: Phong Nguyen

Serverless at the Edge: A Quick Overview

Phong Nguyen — Tue, 26 Jul 2022 15:17:30 +0000

One of the most exciting topics in frontend development recently is edge computing. Being able to run code at the edge is a new capability that will radically change how we write applications. This article aims to provide a brief overview of serverless edge computing, why it is beneficial, and how you can use it.

What is Serverless Edge Computing?

Until recently, when we talked about the edge, we usually thought about content delivery networks (CDNs), which cache static assets such as HTML, CSS files, images, videos, etc. across hundreds of servers around the world. Because the contents are close to users, access is very fast. Serverless edge computing extends this idea by allowing developers to run code at the edge without having to manage any server. Edge computing gives developers a new location for their code along with the two traditional options, namely on the backend and on the device.

What Are the Most Notable Edge Computing Platforms?

The two platforms that are most talked about these days are Cloudflare Workers and Deno Deploy. At the high level, they have many similarities:

Both are JavaScript runtimes that use the V8 engine. Deno has a built-in compiler that allows it to treat TypeScript as a first language. With Cloudflare Workers, you can also write code in TypeScript or any other language that compiles to JavaScript such as Python, PHP, Dart, or Scala.
Both support WebAssembly which means you can run code written in compiled languages such as C, C++, or Rust at near-native speed.
Both runtimes rely on V8 isolates for multi-tenancy.
Both implement web standards such as Fetch API, Streams API and so on.
Similar API in which you need to write a handler function that takes a request and returns a response asynchronously.
Both support streaming and WebSockets.

On the other hand, the most apparent difference between the two platforms is that Deno Deploy doesn’t offer any storage solution while Cloudflare Workers has Durable Objects for consistent storage and Workers KV for low-latency storage with eventual consistency.

Why Serverless Edge Computing?

Edge computing is most often used for implementing middleware which is simple scripts that rewrite URLs, redirect requests, or manipulate cookies and headers. For example, you can perform A/B testing by serving different versions of a page depending on a cookie’s value. You can support localization, which means users from different countries get to see different content. You can also grant or block access to certain pages based on user authentication status.

While the above use cases could be handled by the backend and/or the client, using edge computing is much more optimal in terms of performance and simplicity. If you implement A/B testing or localization on the client, you might have a large-sized bundle and a flickering UI. On the other hand, implementing this functionality at the backend usually requires server configuration and results in slow responses.

Edge computing is so much more than middleware though. In fact, you can even use edge computing to replace your backend altogether. Many full-stack frameworks, for example, Remix and Fresh, now allow you to write functions that access databases directly and render HTML at the edge. By doing so, you probably won’t need to develop an API like you usually did in the past. (But should you want to serve a RESTful API or even a GraphQL API at the edge, you could do that as well.)

But why should you consider replacing your backend with serverless edge computing? There are several reasons for that. First, because it’s serverless, there is no server maintenance nor autoscaling to worry about. Second, it’s much faster than traditional backends because it runs very close to users and, compared to normal Function-as-a-Service platforms, edge computing has little or no cold starts. And third, it is cheaper than conventional serverless options because edge computing platforms use lighter-weight technologies, such as V8 isolates (as opposed to virtual machines or containers) for multi-tenancy, which allows them to utilize resources more efficiently and handle a lot more requests.

How to Use Edge Computing?

If you are using a platform such as Netlify or Vercel to deploy web applications, it’s very simple to opt-in to edge computing. For example, you can use Netlify’s Edge Functions (which is built on Deno Deploy) or Vercel’s Edge Middleware (which probably runs atop Cloudflare Workers). When you deploy a Next.js application (since version 12.2) to either Vercel or Netlify, you can configure some or all pages to use the edge runtime for server rendering (this capability is called Edge SSR).

If you don’t deploy to Netlify, Vercel, or a similar platform, it is advisable that you use an edge-native full stack framework and deploy your application directly to the edge computing service of choice. For example, you can develop your app with the Fresh framework and publish it to Deno Deploy. Another example is the Remix framework which provides adapters for both Cloudflare Workers and Deno Deploy (together with many other deployment targets).

If you don’t want to use a full stack framework, you can develop your frontend and backend separately. With Cloudflare, you can serve your frontend and static assets with Pages or Workers Sites. With Deno Deploy, you can serve static assets from the filesystem. As for the backend, you probably want to use an HTTP framework such as Sunder (if you target Cloudflare Workers), oak, Router, or Sift (if you target Deno Deploy).

What Are the Drawbacks of Edge Computing?

While edge computing is perfect for implementing middleware scripts, if you want to implement the whole backend with it, you should be aware of the target platform’s limits on CPU runtime, memory, package size and so on. You can find detailed information on Cloudflare Workers’ limits here, and Deno Deploy here.

Conclusion

In summary, with edge computing platforms such as Cloudflare Workers and Deno Deploy, developers can write middleware and backends that are both fast and cheap. Edge computing is a game changer which has enabled a new generation of full-stack frameworks such as Remix and Fresh. You can use these frameworks to develop and deploy applications directly to the edge. Additionally, edge computing can be used indirectly through platforms like Netlify and Vercel.

It's just the beginning. In the near future, we can expect a lot more frameworks, libraries, and tools to be developed for the edge. Hopefully, this article has piqued your interest and given you some high-level information on edge computing so you can get started exploring its potential.

Remix Framework Review

Phong Nguyen — Fri, 15 Jul 2022 06:24:30 +0000

Remix is a full stack JavaScript framework for building modern web apps. It is classified as a meta-framework alongside Next.js, Nuxt, SvelteKit, etc. which means they rely on a single-page application (SPA) framework for rendering HTML markup on the server and for rehydrating the app on the client. At the moment Remix only supports React officially, but with adapters being developed, we should be able to use Remix with other SPA frameworks such as Vue or Svelte in a near future. This article discusses what makes Remix different from other React meta-frameworks, the benefits to using Remix, and the drawbacks of doing so.

What makes Remix different?

Remix is markedly different from other React meta-frameworks such as Next.js and Gatsby. This section is not going to elaborate on all the detailed dissimilarities such as route definition, data fetching, error handling and so on. Instead, we are going to cover three major characteristics that set Remix apart:

SSR only
Nested routes
No client-side state

SSR only

In a Remix application, all pages are rendered dynamically on request (server side rendering or SSR). Remix doesn’t supports static site generation (SSG), which means generating pages at build time, nor does it support incremental static regeneration (ISR), which is similar to SSG but deferred until the page is first requested.

Data fetching happens only on the server by running a loader() function and the result is made available to the route’s component through the useLoaderData hook:

export const loader: LoaderFunction = async () => {
  const data: LoaderData = {
    users: await db.user.findMany(),
  };
  return json(data);
};

export default function Users() {
  const data = useLoaderData<LoaderData>();
  return (
    <ul>
      {data.users.map((user) => (
        <li key={user.id}>{user.name}</li>
      ))}
    </ul>
  );
}

Being able to serve dynamic contents is a good thing but does it make Remix apps slower than Gatsby or Next.js SSG apps? Usually not. If you deploy your Remix app at the edge (on a platform such as Cloudflare Workers or Deno Deploy) and also cache data there, you can achieve similar speed as serving static assets from a CDN. In case of cache miss, however, the request could take longer than a statically generated page (especially if you need to fetch a lot of data from a backend server far away from the edge).

Nested routes

Another great idea of Remix is nested routes, which allow the framework to fetch data for multiple routes in parallel. For example, let’s say our application has a page with the URL /jokes/:id to display a joke as follows:

This page needs to fetch three pieces of data: the currently logged in user (for the top bar), a list of jokes (for the right-hand side menu), and the selected joke’s content. We can define three routes that nest one another inside an Outlet component like so:

// root.tsx

export const loader: LoaderFunction = async ({ request }) => {
  const data: LoaderData = {
    user: await getUser(request),
  };
  return json(data);
};

export default function App() {
  const data = useLoaderData<LoaderData>();

  return (
    {/* ...more stuff... */}
    <div className="jokes-layout">
      <header className="jokes-header">
        <span>{`Hi ${data.user.username}`}</span>
      </header>
      <main className="jokes-main">
    <Outlet />
      </main>
    </div>
    {/* ...more stuff... */}
  );
}

// routes/jokes.tsx

export const loader: LoaderFunction = async () => {
  const data: LoaderData = {
    jokeListItems: await db.joke.findMany(),
  };
  return json(data);
};

export default function JokesRoute() {
  return (
    <div className="container">
      <div className="jokes-list">
        <ul>
          {data.jokeListItems.map((joke) => (
            <li key={joke.id}>
              <Link to={joke.id}>{joke.name}</Link>
            </li>
          ))}
        </ul>
      </div>
      <div className="jokes-outlet">
        <Outlet />
      </div>
    </div>
  );
}

// routes/jokes/$id.tsx

export const loader: LoaderFunction = async ({ params }) => {
  const data: LoaderData = { 
    joke: await db.joke.findUnique({
      where: { id: params.jokeId },
    })
  };
  return json(data);
};

export default function JokeRoute() {
  const data = useLoaderData<LoaderData>();

  return (
    <div>
      <p>{data.joke.content}</p>
      <Link to=".">{data.joke.name} Permalink</Link>
    </div>
  );
}

In this example, Remix can run all the three loaders at the same time to fetch data in parallel. Doing so greatly mitigates the waterfall problem where you can only start fetching data for an inner component once the outer component has finished fetching data and rendering the UI. Nested routes is a powerful idea and has been adopted by other frameworks (such as Next.js with their recent Layout RFC).

No client-side state

This is Remix's most radical difference in my opinion. Unlike normal single-page apps, a Remix app doesn’t usually have client-side state. Every time you navigate to a page, Remix will request for data from server - somewhat similar to the old days when we developed web apps with Java Servlets, ASP.NET, or PHP. With Remix, however, application state now lives at the edge - very close to end users - so such requests are very fast.

So how would we mutate data? Again, just like in the old days, we submit forms. More specifically, you would use Remix’s Form component to render the UI, and write an action() function to handle submitted data:

export const action: ActionFunction = async ({ request }) => {
  const form = await request.formData();
  const name = form.get("name");
  const content = form.get("content");

  const joke = await db.joke.create({ data: { name, content} });
  return redirect(`/jokes/${joke.id}`);
};

export default function NewJokeRoute() {
  return (
    <Form method="post">
      <div>
        <label>
          Name: <input type="text" name="name" />
        </label>
      </div>
      <div>
        <label>
          Content: <textarea name="content" />
        </label>
      </div>
      <div>
        <button type="submit" className="button">
          Add
        </button>
      </div>
    </Form>
  );
}

Actions have exactly the same API as loaders and, like loaders, they also run only on the server. Note that, should JavaScript become unavailable, mutations still work but form submission results in a full page reload (as opposed to a fetch request when JavaScript is used).

Benefits to using Remix?

Now that we've seen Remix’s major differences, let’s discuss the main benefits to using this meta-framework.

Dynamic contents:

With Remix, you no longer have to make the tradeoff between performance and dynamic contents. By taking advantage of edge computing, your apps can be dynamic and fast at the same time.

Faster data fetching:

Thanks to nested routes, Remix can fetch data in parallel which alleviates waterfall problems and greatly improves performance.

Simpler code:

There is no decision to make between SSG, SSR, or ISR. Only one single way to fetch data (that is by calling a loader function). More importantly, by getting rid of client-side state management altogether (which is normally a large part of any non-trivial app), Remix significantly reduces the complexity of your apps.

More resilient apps:

With Remix, links and mutations still work without JavaScript. That’s great because sometimes users may have a spotty connection and JavaScript may fail to load. Furthermore, with Remix’s built-in support for mutations, error handling is simpler and better with error boundaries and catch boundaries. Race conditions are handled automatically by the framework, for example when a user clicks on a button multiple times in quick succession.

Smaller bundle size:

As mutations happen only on the server, you can reduce a large amount of code that needs to be downloaded and parsed by the browser.

Drawbacks of using Remix?

With the numerous benefits mentioned above, Remix is clearly an awesome framework. But, of course, it’s not perfect. Below are a few potential drawbacks that I could think of.

Responsiveness:

Remix apps are fast when deployed to the edge and with data cached. In case of cache miss, however, it may take a while to fetch data and render the UI, that means users might experience some level of unresponsiveness. You can mitigate this issue by enabling prefetching, meaning that Remix will instruct the browser to eagerly fetch a link when the mouse is over it.

Nested routes’ nuisances:

While nested routes are great for data fetching, there are times they are not convenient to use. For example, you may want to have a breadcrumb that requires data from multiple descendant routes. To implement it, each route needs to expose a handle which then becomes available through the useMatches hook at the top level. Another example is when you have a protected page. In this case, you need to perform user authentication in every loader, not only the top-level one.

Problems with not having client-side state:

The most notable drawbacks of Remix arise from the fact that you no longer have client-side state to tap into.

First, real-time applications (web whiteboard, chat and so on). Remix can gracefully handle mutations initiated inside the browser, but in a realtime application, changes also come from outside. In a normal single-page app, you can simply update the application state and the changes will automatically reflect in the UI. But in a Remix app you don’t have client-side state, so what would you do?

Second, sharing data across routes. In a single-page app with client-side state, it's very straightforward for UI components to share data. But in a Remix app, if it takes a while for the server to process a mutation and you want to implement optimistic UI involving two or more routes, how would you share data? Remix does provide a useFetchers hook for this purpose but using it is rather cumbersome and apparently not declarative.

Third, number of requests to database/cache. Because there is no client-side state, almost every time you go to a link or perform a mutation, Remix needs to fetch data again for all the visible routes (except when you visit a child route). This results in a much higher number of requests to the server and a larger number of reads to your database and/or cache which could probably increase your project’s cost. Remix has a shouldReload API to help avoid unnecessary reloads but it complicates your code and won’t totally eradicate this problem.

Finally, automated tests are harder because without client-side state you must write more end-to-end tests which are slower and more difficult to set up and tear down.

Conclusion

In summary, Remix is markedly different from other React meta-frameworks in that pages are always rendered dynamically, it uses nested routes for fetching data in parallel, and that it moves application state to the edge. With these characteristics, Remix makes it simpler to build web apps that are dynamic, fast, small, and resilient. However, Remix may not be best suited for building real-time applications or for applications in which you often need to share data across routes. In any case, Remix is a truly great framework and I would highly recommend that you give Remix a try if you haven’t already done so.

Concurrent Rendering in SolidJS

Phong Nguyen — Wed, 11 May 2022 14:25:19 +0000

Concurrent rendering is a capability which allows a UI library to prepare a new version of the UI in the background while keeping the current version interactive. React introduced concurrent rendering a few years ago but until now some of the features are still at the experimental stage. Since then, SolidJS and some other libraries have borrowed the ideas and implemented similar concurrent features.

In this article, we will study concurrent rendering in SolidJS, which is a library for building web applications that are small and extremely fast. If you are new to Solid but already familiar with React you may want to read an introduction to SolidJS first.

Why concurrent rendering?

Before learning how to use concurrent rendering, you need to understand why such a capability is beneficial.

By default, rendering happens synchronously. When the user performs a certain action, say clicking on a button, an event handler will run which usually involves some computation and changing something in the application state which, in turn, causes the UI to update. This is great when everything within the event handler happens quickly, since the user can instantly see the result of their action.

But sometimes an event is inherently slow. For example, we may need to load a module because of code splitting. We may have to fetch some data from the backend. Or we may have a lot of expensive computations to execute. What would happen in these situations? With synchronous rendering, there would be a period of time during which the "old" UI is no longer available but the "new" UI is not yet ready and thus not interactive. By contrast, concurrent rendering can greatly improve the user experience because it allows the user to continue using the current version of the UI as usual while a new version is being prepared behind the scenes.

Concurrent rendering in SolidJS

Generally speaking, you can take advantage of concurrent rendering in two kinds of situations:

You need to wait for something such as a dynamically imported module or some data being fetched from the backend. In this case, you can create a resource to handle the loading of the dependency and use a Suspense component to specify the boundary of the part of the UI to be rendered asynchronously.
You have a lot of computations to run, for example your application may contain thousands of fine-grained components and everyone of them needs to recalculate a computed value. In this case, you can opt for Solid's time slicing feature which breaks down the computation workload into small chunks and executes them in the background.

In the subsequent sections, we will study these use cases one by one through some examples.

Code splitting

First, let's see an example of code splitting without using Suspense.

In this example, we have a Counter component that is lazily loaded when the user clicks on the Start button for the first time. To do that, we use Solid's lazy() function to wrap the dynamic import statement. Here we create a promise to simulate a two-second delay when loading the module. The first time you click on the Start button, you would notice that nothing seems to happen for a few seconds while the module is being loaded.

We can make the user experience a bit better by wrapping our lazily loaded Counter inside a Suspense component and specifying a fallback UI to render as the module is being imported:

<Suspense fallback={<p>Loading...</p>}>
    <Counter />
</Suspense>

Try on CodeSandbox

What happens here is that the lazy() function internally creates a resource to manage the dynamic import. The resource informs the Suspense component to render the fallback UI, and later notifies it to render the expected UI when loading finishes.

Data fetching

This is by far the most important use case of concurrent rendering. In the following example, we have a view that shows a list of items. Clicking on an item brings the user to another view which fetches the item's details and displays it. The traditional approach, as shown here, offers a poor user experience when the network connection is slow because the user only sees a loading indicator and is unable to use the app when loading is in progress.

Let's now use concurrent rendering to allow the user to "stay in the past" by making a couple of changes as follows:

Firstly, we need a Suspense component that encompasses both the item view and the list view so that it can retain the list view in the UI when the item view is being prepared.

<Suspense>
  <Show
    when={selectedItem()}
    fallback={<ListView items={ITEMS} onSelect={setSelectedItem} />}
  >
    <ItemView item={selectedItem} />
  </Show>
</Suspense>

Secondly, we need to inform Solid that rendering the item view is not the highest priority so it should not render it immediately but should have a transition period until the resource resolves. To do so, we can call Solid's useTransition() which returns a signal indicating whether the resource is still pending and a function to kickstart the transition.

function ListView(props) {
  const [loading, setLoading] = createSignal<string>();
  const [pending, start] = useTransition();
  const handleClick = (item: string) => {
    setLoading(item);
    start(() => props.onSelect(item));
  };

  return (
    <ul>
      <For each={props.items}>
        {(item: string) => (
          <li onClick={() => handleClick(item)}>
            {item} {pending() && loading() === item ? "(loading...)" : ""}
          </li>
        )}
      </For>
    </ul>
  );
}

Try on CodeSandbox

In the click event handler above, it is important to note that we don't want Solid to immediately render the item view but we do want an immediate indicator of which item being loaded. That's why only the second statement is wrapped in the transition.

Time slicing

Time slicing in Solid could be helpful when your application has a large number of reactive primitives to compute before rerendering the UI. However, I couldn't think of any application like that in the real world. I suppose most users wouldn't need this feature, and that's why Solid doesn't enable scheduling by default. To use time slicing, you need to explicitly call enableScheduling(), otherwise the scheduler will be tree shaken from the application bundle.

However, let's still look into a contrived example to understand how to use time slicing. In this example, we have a range input that controls the number of items to render. Each item has a memo with a simulated long calculation time. When you use the input to increase the number of items, you should notice that the input becomes unresponsive for a while until all items have been rendered.

Time slicing breaks down the computation workload into small chunks and executes them only when the browser isn't busy with higher priority updates such as user inputs. As mentioned, we need to call enableScheduling() first. After that, use startTransition() to wrap low priority updates. In this case, we need to inform Solid that the creation of the items is of lower priority and thus should be interruptible. Now you should see that, as the user moves the slider, its value changes immediately and the input stays responsive even though it still takes a long while to render the list.

Conclusion

In this article, we have learned about concurrent rendering and why you may want to use Solid's concurrent features. In summary, there are three main scenarios for concurrent rendering. For code splitting, use a Suspense component to render a fallback UI while loading a module. For data fetching, use Suspense and transition to retain the current UI while the new UI is being prepared. Finally, you can consider enabling time slicing if you ever need a large number of reactive primitives to compute in your app.

State management in SolidJS applications

Phong Nguyen — Mon, 02 May 2022 16:27:13 +0000

State management is usually one of the most important problems that you need to tackle when developing a frontend application. This article discusses state management for SolidJS, which is a library for building web applications that are small and extremely fast. If you are new to Solid but already familiar with React you may want to read an introduction to SolidJS first.

Let's start with the most fundamental building blocks of Solid's reactivity system: signals.

Signals

A signal represents an observable piece of data that automatically tracks computations that depend on it. When a computation such as an effect or a memo calls the signal's getter function, it will be added to the signal's subscription list. Whenever the data changes, the signal will notify all of its subscribers.

Below is a simple example using a signal. Note that we don't update a signal's data directly but need to call its setter function.

import { render } from "solid-js/web";
import { createSignal } from "solid-js";

function Counter() {
  const [count, setCount] = createSignal(0);

  return (
    <div>
      <button onClick={() => setCount((c) => c - 1)}> - </button>
      {count()}
      <button onClick={() => setCount((c) => c + 1)}> + </button>
    </div>
  );
}

render(() => <Counter />, document.getElementById("app"));

Try on CodeSandbox

It's important to note that signals are the units of change. When you update a certain part of a signal's data, all of its subscribers are notified no matter if they use that particular part or not. Let's demonstrate this behavior with a contrived example:

In this example, we have a signal that is used by two effects: one renders and updates the UI, while the other prints the last name to the console. The second effect doesn't use the first name, but whenever the first name changes, it still reruns unnecessarily.

To avoid unnecessary computations, we could use one signal for the first name and another signal for the last name. In more complex cases, we could nest signals, for example, having a signal to contain a list whose items being signals as well. It works, but the code would be rather cumbersome. Fortunately, Solid has a built-in solution for nested reactivity: stores.

Stores

Let's use a store to replace the signal in the previous example. You should now see that the effect that prints to the console only reruns when the last name changes, not when the first name changes.

How does a store work? A store is a proxy object whose properties are automatically wrapped in proxies themselves. Behind the scenes, Solid lazily creates signals for properties that are accessed under tracking scopes. So basically, a store is a tree of signals that are independently tracked and modified.

As you probably have noticed from the example, the syntax for reading and writing data with stores is different from that with signals. To read data you don't need a getter function but can simply access properties as you would do with normal objects. To write data, you can use Solid store's path syntax. Below are some examples of the path syntax copied from Solid's documentation:

const [state, setState] = createStore({
  todos: [
    { task: 'Finish work', completed: false }
    { task: 'Go grocery shopping', completed: false }
    { task: 'Make dinner', completed: false }
  ]
});

setState('todos', [0, 2], 'completed', true);
// {
//   todos: [
//     { task: 'Finish work', completed: true }
//     { task: 'Go grocery shopping', completed: false }
//     { task: 'Make dinner', completed: true }
//   ]
// }

setState('todos', { from: 0, to: 1 }, 'completed', c => !c);
// {
//   todos: [
//     { task: 'Finish work', completed: false }
//     { task: 'Go grocery shopping', completed: true }
//     { task: 'Make dinner', completed: true }
//   ]
// }

setState('todos', todo => todo.completed, 'task', t => t + '!')
// {
//   todos: [
//     { task: 'Finish work', completed: false }
//     { task: 'Go grocery shopping!', completed: true }
//     { task: 'Make dinner!', completed: true }
//   ]
// }

setState('todos', {}, todo => ({ marked: true, completed: !todo.completed }))
// {
//   todos: [
//     { task: 'Finish work', completed: true, marked: true }
//     { task: 'Go grocery shopping!', completed: false, marked: true }
//     { task: 'Make dinner!', completed: false, marked: true }
//   ]
// }

While I can see that the syntax is powerful, it doesn't seem very intuitive. Luckily, Solid also provides a couple of alternatives for updating stores. The first alternative is using a mutable store by calling createMutable() instead of createStore(). This way, you can update the store like you would do with a normal JavaScript object:

const store = createMutable({ firstName: "John", lastName: "Doe" });

// read value
store.firstName

// set value
store.firstName = anotherValue

Try on CodeSandbox

While using a mutable store is very simple, it could be hard to reason about when changes are made from many places in the application. Thus I would recommend the second alternative, which is to use an Immer inspired utility function called produce(). This utility allows us to write code that mutates data in the normal way but automatically creates immutable copies behind the scenes.

const store = createStore({ firstName: "John", lastName: "Doe" });

// read value
store.firstName
store.lastName

// set value
setState(produce(s => {
    s.firstName = anotherFirstName
    s.lastName = anotherLastName
}))

Try on CodeSandbox

State libraries

Now that we've got a basic understanding of Solid's built-in options for state management, there is an interesting question to ask: do we need an external state container similar to Redux or MobX for Solid applications?

To answer that question, we should first understand the reasons why we need state libraries for React applications. In my opinion, there are two main reasons: to separate state management from presentation logic and to make it easier to share state among components in different parts of the UI.

Neither reason is applicable for Solid. Solid stores are usually created outside the component tree, so there is no mixing with presentation logic. And you can import and use a store from any components, so state sharing is not a problem either.

That means there is usually no reason to use an external state container in a Solid application. However, I think that a state library that also handles data fetching (similar to React Query or SWR) could still be useful because you would not have to concern yourself with the structure of the application state, plus the library can keep cached data fresh automatically.

Conclusion

This article has introduced the two built-in options for state management in a Solid application. Use signals for atomic pieces of data. Use a store if the state is a complex structure whose parts can be modified independently. Use the path syntax or the produce() utility for updating stores. You don't need a state library like Redux or MobX. For most applications, using one or more stores to manage the application state should be sufficient.

Introduction to SolidJS for React developers

Phong Nguyen — Wed, 20 Apr 2022 07:44:04 +0000

SolidJS has been gaining traction as a UI library for building web applications that are extremely fast and small. At the first glance, Solid doesn’t appear much different from React. Solid also uses JSX, it has an API that resembles React hooks, and it follows the same philosophy as React with unidirectional data flow, immutable interfaces and so on.

import { render } from "solid-js/web";
import { onCleanup, createSignal } from "solid-js";

function App() {
  const [count, setCount] = createSignal(0);
  const interval = setInterval(() => setCount((count) => count + 1), 1000);
  onCleanup(() => clearInterval(interval));

  return <div>Counter: {count()}</div>;
}

render(() => <App />, document.getElementById("app"));

But don’t let the look deceive you because Solid is fundamentally different. First of all, it doesn’t use Virtual DOM diffing to update the UI. Instead, Solid relies on reactive primitives that hold application state and automatically track dependencies, so when a piece of data changes, it knows immediately and exactly what needs to update. This fine-grained reactivity system allows Solid to consistently top speed and memory benchmarks for UI libraries.

Secondly, Solid takes a pre-compilation approach in which it uses a compiler to set up the reactive graph and handle treeshaking to reduce bundle size. Thanks to this compiler, Solid applications are among the smallest in comparison to other UI libraries.

This article aims to help React developers leverage their existing knowledge to learn the fundamentals of SolidJS. The article covers the following topics:

Defining components
Component state
Component lifecycle
Component communication
Event handling
Working with refs
Error handling
Code reuse

Defining components

In a Solid application, components are functions that return JSX elements. Class components are not supported. Note that JSX code is compiled into functions that directly update the DOM (since Solid doesn’t use a Virtual DOM). To avoid recreating DOM nodes on every update, Solid provides several components for conditional and looping that we should use instead of if/else, switch statements and Array.prototype.map. The most important components are Show, Switch and For:

<Show
  when={loggedIn()}
  fallback={<button onClick={toggle}>Log in</button>}
>
  <button onClick={toggle}>Log out</button>
</Show>

<Switch fallback={<p>Normal temperature</p>}>
  <Match when={temp() >= 40}>
    <p>Too hot</p>
  </Match>
  <Match when={temp() <= 10}>
    <p>Too cold</p>
  </Match>
</Switch>

<For each={articles()}>{(a, index) =>
  <li>{index() + 1}: {a.title}</li>
}</For>

Component state

The cornerstones of reactivity in Solid are signals and effects which look somewhat similar to React’s useState and useEffect hooks:

import { createSignal, createEffect } from "solid-js";

function App() {
  const [count, setCount] = createSignal(0);
  createEffect(() => {
    console.log("Count: ", count());
  });

  return <button onClick={() => setCount((c) => c + 1)}>{count}</button>;
}

However, signals are vastly different from the useState hook in the following aspects:

While you can only call useState() from within a function component or a custom hook, you can call createSignal() from anywhere. If called within a component, the signal represents that component’s local state. Otherwise, the signal represents an external state that any component can import and use to render their UI.
More importantly, signals automatically track functions that depend on its data and will invoke these functions whenever the data changes. Note that the first element in the tuple returned by createSignal() is not the data itself but a getter function. When the getter function is called, the calling function (obtained from a global stack) will be added to the signal’s subscribers list.

Similar to React's useEffect hook, createEffect() defines a side effect that should run whenever a signal it depends on changes. However, thanks to Solid’s automatic dependency tracking, you don’t have to explicitly provide a dependency list.

Component lifecycle

With React, your component function reruns whenever the component’s state changes. In contrast, Solid component functions never rerun. A component runs only once to create the necessary signals and effects (JSX code is compiled into an effect as well). After that the component vanishes. That means we don’t have access to component lifecycle events like we do with React or other libraries.

However, Solid does provide two special events called onMount and onCleanup. onMount can be considered a special effect that runs only once, after all initial rendering is done. The most common use case is fetching data when a screen is loaded.

import { createSignal, onMount } from "solid-js";

function App() {
  const [data, setData] = createSignal();

  onMount(async () => {
    const res = await fetch(`/path/to/your/api`);
    setData(await res.json());
  });

  return (/* JSX to render UI based on data */);
}

onCleanup can be called in a component (see the first example above), in an effect (example below), or at any scope that is part of the synchronous execution of the reactive system. onCleanup will run when that scope is disposed or re-evaluated.

import { createSignal, createEffect, onCleanup } from "solid-js";

function App() {
  const [counting, setCounting] = createSignal(false);
  const [count, setCount] = createSignal(0);

  createEffect(() => {
    if (counting()) {
      const c = setInterval(() => setCount((val) => val + 1), 300);
      onCleanup(() => clearInterval(c));
    }
  });

  return (
    <div>
      <button type="button" onClick={() => setCounting((val) => !val)}>
        {counting() ? "Stop" : "Start"}
      </button>
      <p>Counter: {count()}</p>
    </div>
  );
}

Component communication

In this regard, Solid is pretty much the same as React. You use props to pass data from a parent component to a child (or pass actions back to the parent). Use Context API to pass data to descendent components.

However, there is a caveat. Generally, you should not destructure props. By doing so you will loose reactivity, meaning that the child component’s UI will not update when prop values change. As compensation, Solid provides two helpers for working with props: mergeProps() and splitProps().

// DON'T do this
function Greeting({ name, greeting = "Hi" }) {
  return <h3>{greeting}, {name}!</h3>
}

// use mergeProps() to set default values
function Greeting(props) {
  const merged = mergeProps({ greeting: "Hi" }, props);
  return <h3>{merged.greeting}, {merged.name}!</h3>
}

// DON'T do this
export default function Greeting(props) {
  const { greeting, name, ...others } = props;
  return <h3 {...others}>{greeting}, {name}!</h3>
}

// use splitProps() instead of the rest syntax
function Greeting(props) {
  const [local, others] = splitProps(props, ["greeting", "name"]);
  return <h3 {...others}>{local.greeting}, {local.name}!</h3>
}

Event handling

Like React, Solid only supports unidirectional data flows. There is no builtin mechanism for input binding. Unlike React, however, Solid applications use DOM events directly rather than synthetic events.

function App() {
  const [name, setName] = createSignal("World");

  return (
    <div>
      <input
        type="text"
        value={name()}
        onInput={(evt) => setName(evt.currentTarget.value)}
      />
      <p>Hello, {name()}!</p>
    </div>
  );
}

Working with refs

Using refs in a Solid application is not much different from that with React. Basically, you can either declare a local variable and assign it to a prop named ref, or use a callback:

// local variable
function SimpleForm() {
  let ref;
  onMount(() => ref.focus());
  return (<input ref={ref} />);
}

// ref callback
function SimpleForm() {
  return (
    <input ref={el => {
      onMount(() => el.focus())
    }} />
  );
}

Error handling

Another idea that Solid borrows from React is error boundary components. However, you don’t have to implement it manually as ErrorBoundary is a builtin component in Solid:

import { ErrorBoundary } from "solid-js";

<ErrorBoundary fallback={err => {
  // report error
  console.log(err);

  // fallback UI
  return (/* JSX */)
}}>
  {/* your component tree */}
</ErrorBoundary>

Code reuse

In React, you have multiple techniques for code reuse with the most popular being higher-order components, render props, and custom hooks. You can use similar techniques with Solid as well. The examples below are three implementations for a reusable self-running clock that we can easily use with different UIs.

Higher-order component (HOC)

Render prop

React hook-like code reuse

In addition to these techniques, Solid allows you to define reusable behavior as custom directives. A directive is a function that gets called when the element it decorates is added to the DOM. The function takes two arguments: the DOM element, and a getter function to obtain the directive's parameter. Below is an example directive which detects if user clicks outside of the element's boundary:

Conclusion

SolidJS offers incredible performance and very small bundle size while being able to retain a simple programming model that we all love. As a relatively new library, Solid’s ecosystem and community are still small but that may change as more people get to know its potentials. As at this writing, Solid’s GitHub repo has got 16 thousand stars and the project is sponsored by reputable companies such as Cloudflare, Netlify, Vercel…

This article has covered only the fundamental topics on using SolidJS. I hope it can save you some time if you want to give Solid a try. The coming articles will address more in-depth topics such as state management, Suspense API, and server rendering. See you then!

Note: This article was first published to HackerNoon under a different title. Republished here with the original title and an additional part on custom directives.