DEV Community: David Morrow

Use Next.js to create a blog from Dev.to API

David Morrow — Mon, 24 Mar 2025 00:40:40 +0000

So if you have written a few articles on Dev.to, you may want to have your own site with your articles. I had previously just copied and pasted the markdown, but I recently discovered that there is a simple public API for Dev.to. So this article is about how I used the API to leverage Dev.to as a CMS for my personal site.

I am using this for my site NewFinds.com, you can find the full source here on GitHub

Getting started

There are a ton of great articles, and the docs for Next.js are fantastic. So I am not going to go too deep into the usage of Next.js, but I will touch on a few things that are relevant to static site generation from dynamic content.

The API endpoints we will be using for our data.

There are only three endpoints that we need to list posts for a user, post details (which contains the markdown), and the comments for a post. They are as follows.

The list of Posts: https://dev.to/api/articles?username=${username}&page=1&per_page=100
The comments for a Post: https://dev.to/api/comments?a_id=${postId}
The post details: https://dev.to/api/articles/${username}/${slug}

I am using Typescript, which I find really useful when dealing with APIs. The types for the responses from the API are as such.

// lib/types.ts
export type User = {
  name: string;
  username: string;
  twitter_username: string;
  github_username: string;
  user_id: number;
  website_url: string;
  profile_image: string;
  profile_image_90: string;
};

export type Post = {
  type_of: string;
  id: number;
  title: string;
  description: string;
  readable_publish_date: string;
  slug: string;
  path: string;
  url: string;
  comments_count: number;
  public_reactions_count: number;
  positive_reactions_count: number;
  collection_id: number | null;
  published_timestamp: string;
  language: string;
  subforem_id: number | null;
  cover_image: string | null;
  social_image: string;
  canonical_url: string;
  created_at: string;
  edited_at: null;
  crossposted_at: string;
  published_at: string;
  last_comment_at: string;
  reading_time_minutes: number;
  tag_list: string[];
  tags: string;
  user: User;
};

export type PostDetails = {
  body_html: string;
  body_markdown: string;
} & Post;

export type Comment = {
  type_of: string;
  id_code: string;
  created_at: string;
  body_html: string;
  user: User;
  children: Comment[];
};

The only difference between Post and PostDetails is body_html and body_markdown. The body_markdown is what we will use for rendering our post.

Getting setup to statically render the site

The great thing about Next.js is that it can be whatever you need. An API with a database, a frontend SPA, an entirely static site, a static site built from dynamic content. This last one is our use case.

In order to let Next.js pre-render everything on build, (generate html files for every page) we have to setup our next.config.ts file. The output = "export" tells Next.js that we want to pre-render everything.

// next.config.ts
const nextConfig: NextConfig = {
  output: "export",
  //...
}

So now, when we run npm run build our site will be pre built to a folder called out, which we can host anywhere statically, its just HTML files and client side Javascript now.

Calling the API

Ill put our API calls into a separate file where we will make our API calls. I pulled this out, so that it can be shared with a few of our pages/components.

// app/lib/api.ts
import { Post, PostDetails, Comment } from "./types";
import { username } from "./consts";

export async function getAllPosts(): Promise<Post[]> {
  const res: Response = await fetch(
    `https://dev.to/api/articles?username=${username}&page=1&per_page=100`,
  );
  return await res.json();
}

export async function getPostBySlug(slug: string): Promise<PostDetails> {
  const res: Response = await fetch(
    `https://dev.to/api/articles/${username}/${slug}`,
  );
  return res.json();
}

export async function getComments(postId: number): Promise<Comment[]> {
  const res: Response = await fetch(
    `https://dev.to/api/comments?a_id=${postId}`,
  );
  return res.json();
}

The dynamic article page `app/articles/[slug]/page.tsx`

Ok so now that we have the ability to load data from dev.to, lets use it to create all the static pages generated from all our articles that come on the API.

Next.js uses the file and folder name to generate params, and determine if a page is dynamic. For more info: dynamic routes

// app/articles/[slug]page.tsx
import type { Post, PostDetails } from "@/app/lib/types";
import type { Metadata } from "next";
import type { JSX } from "react";

import Markdown from "react-markdown";
import rehypeHighlight from "rehype-highlight";

import { getAllPosts, getComments, getPostBySlug } from "@/app/lib/api";
import Comments from "@/app/components/comments";

type Params = {
  slug: string;
};

type DynamicArgs = {
  params: Promise<Params>;
};

export async function generateStaticParams(): Promise<Params[]> {
  const posts: Post[] = await getAllPosts();
  return posts.map((post: Post) => ({ slug: post.slug }));
}

export async function generateMetadata({ params }: DynamicArgs): Promise<Metadata> {
  const { slug } = await params;
  const post: PostDetails = await getPostBySlug(slug);

  return {
    title: post.title,
    description: post.description,
  };
}

export default async function Page({ params }: DynamicArgs): Promise<JSX.Element> {
  const { slug } = await params;
  const post: PostDetails = await getPostBySlug(slug);
  const comments = await getComments(post.id);

  return (
    <>
      <article className="md">
        <h1>{post.title}</h1>
        <Markdown rehypePlugins={[rehypeHighlight]}>
          {post.body_markdown}
        </Markdown>
      </article>

      <footer>
        <div className="comments md">
          <h2>Comments ({comments.length})</h2>
          <Comments comments={comments} />
        </div>
      </footer>
    </>
  );
}

Generating the Static Params

The generateStaticParams function tells Next.js how many pages to generate, and supplies the params, (in our case the slug) to the routes.

It is an async function, we load all the posts from our api, and then return an array of Objects, with a key of slug in each.

export async function generateStaticParams(): Promise<Params[]> {
  const posts: Post[] = await getAllPosts();
  return posts.map((post: Post) => ({ slug: post.slug }));
}

Generating the Metadata

Similar to above, generateMetadata function tells Next.js what metadata is for each page. We load the post for the page by slug using our API, and then return title, and description which Next.js will use to populate our <head> on the page.

export async function generateMetadata({ params }: DynamicArgs): Promise<Metadata> {
  const { slug } = await params;
  const post: PostDetails = await getPostBySlug(slug);

  return {
    title: post.title,
    description: post.description,
  };
}

Rendering the Markdown to HTML

First we load react-markdown and rehype-highlight plugin which we will use to syntax highlight code examples in our markdown.

I think being able to render the syntax highlighting (at compile time), rather than on the client at run-time is a pretty neat benefit of pre-rendering our pages.

import Markdown from "react-markdown";
import rehypeHighlight from "rehype-highlight";

<Markdown rehypePlugins={[rehypeHighlight]}>
  {post.body_markdown}
</Markdown>

Rendering our comments

I chose to render the comments, and its pretty simple with the data structure that is returned on the API. We simply render the <Comments> component and pass in the comments for our article that we loaded.

// app/articles/[slug]/page.tsx
<h2>Comments ({comments.length})</h2>
<Comments comments={comments} />

Now if you remember the schema for comments, it supports children. Like responses to a comment and so forth. In order to support that, we can simply recursivly render the <Comments> component, passing children as the comments prop.

I am stripping the HTML here, I assume Dev.to sanitizes user input, but its always a good idea to be careful with displaying user supplied content.

// app/components/comments.tsx

import type { JSX } from "react";
import type { Comment } from "@/app/lib/types";
import { stripHtml } from "string-strip-html";
import Image from "next/image";

type Props = {
  comments: Comment[];
};

export default function Comments({ comments }: Props): JSX.Element {
  return (
    <ul>
      {comments.map((comment) => (
        <li key={comment.id_code}>
          <h4>
            <Image
              src={comment.user.profile_image_90}
              alt={comment.user.name}
              width={48}
              height={48}
            />
            {comment.user.name}
          </h4>
          <p>{stripHtml(comment.body_html).result}</p>
          {comment.children.length ? (
            <Comments comments={comment.children} />
          ) : null}
        </li>
      ))}
    </ul>
  );
}

Updating the site

Since the site is completely static, you will need to npm run build the site each time you want to pull down more article, or comments ect. But if you are using Github pages like I am, it is as simple as running build and then pushing your changes.

You don't need a CSS pre-processor

David Morrow — Thu, 31 Oct 2024 21:49:29 +0000

Native CSS has come a long way in recent months/years. In this post I am going to go over the major reasons that folks have used css pre-processors such as SASS, LESS, and Stylus, and show you how you can accomplish these same things with native CSS.

Separating files

Separating files is one main reason folks reach for a pre-processor. For quite some time now though you have been able to import another file into a CSS file. It looks like this.

@import url("./utils.css");

You can use a relative or an absolute path, the same way you would for an href on an anchor tag, or any other resource.

The main difference between this an a pre-processor would be that while a pre-processor would combine then at compile, CSS is going to make an http request at runtime.

Nesting rules

Ok this is the main reason for using a pre-processor. At least it's my main reason for using one in the past.

But CSS now supports nesting, and it works mostly how you are used to from using pre-processors.

header {
  h1 {
    font-weight: bold;
  }

  h2 {
    font-weight: normal;
  }
}

Pretty awesome, what a huge advantage to writing CSS like we have for decades.

header h1 {
  font-weight: bold;
}

header h2 {
  font-weight: normal;
}

Sudo selectors

Sudo selectors work the same way in native css that you may be accustomed to from pre-processors as well.

button {
  color: blue;

  &:hover {
    color: purple;
  }
}

You can read more about nesting at MDN.

Variables

A long time reason for pre-processors was variables. You can have all your colors, spacing ect in one file and globally update it everywhere.

Well you can do that in native CSS now, for some time. In fact in several ways it's better than the pre-processors.

Global variables

Global variables are enclosed in a :root rule. These can be referenced anywhere.

:root {
  --bg-color: #333;
}

To use a variable, it must be referenced with the var tag

button {
  background-color: var(--bg-color);
}

Scoped variables

You can also scope variables on selectors, for example...

header {
  --bg-color: #999;
}

So in this case, referencing var(--bg-color); within the header selector will result in #999;

Re-assigning values at runtime

So the main advantage with css variables over a pre-processor, is that they can be overrode at runtime, where a pre-processor once its compiled, it's permanent.

So for example if you have a website that you want to support light and dark modes. This can be achieved very easily using css vars.

:root {
  --bg-color: white;
}

body {
  background-color: var(--bg-color);
}

@media (prefers-color-scheme: dark) {
  :root {
    --bg-color: black;
  }
}

To achieve something like this with a pre-processor, you would need to toggle a class on the body using Javascript, and override all the rules with a .dark class or something of the sort.

Computation

Most pre-processors such as LESS, Stylus, or SASS let you do math on things. Like if you want to divide a variable in half ect.

You can do that in native css using the calc function.

:root {
  --spacing: 2em;
}

header {
  margin-top: calc(var(--spacing) / 2);
}

how cool is that?

Transforming colors

So another popular feature (at least to me) is to lighten and darken colors in a css pre-processor. You can do this in native css now as well using color-mix.

header {
  background-color: color-mix(in oklab, red 50%, white);
}

The above would be the equivalent to what you are used to doing with a lighten(red, 50%) in a preprocessor.

To darken just mix with black instead of white

header {
  background-color: color-mix(in oklab, red 50%, black);
}

I hope next time you are choosing what tools to use on a project, you will give native css a try. It has come a long way.

A Simple, mostly CSS code editor

David Morrow — Wed, 30 Oct 2024 19:39:38 +0000

In this article, I'm going to talk about how to make a very simple, browser based code editor using mostly CSS. I originally built this when I needed to let users edit JSON in a CMS that I was building.

If you just want to jump to the code and the working example, here you go. The code can be found here and the working example here

Contenteditable sucks...

So if you were ever pondered building your own code editor, you have probably looked at contenteditable. While contenteditable is great for many situations, but there is one huge problem. It is nearly impossible to place the cursor back where it was after you syntax highlight the code in the editor as it changes.

In my case, I wanted something very minimal without reaching for some huge, heavy handed library for this. I set out to see if I could build a very simple editor using mostly CSS, just using Javascript to create the syntax highlighted output, and update the preview.

I wanted to type in a normal <textarea> and just update the preview of the syntax highlighted code in another element.

How the illusion works

The HTML code

<div id="editor">
  <div class="preview"></div>
  <textarea class="code" spellcheck="false"></textarea>
</div>

A regular <textarea> with transparent text
A <div> populated with your syntax highlighted code.
A container wrapping your <textarea> and your preview <div> so that they can scroll together and remain lined up.

The CSS

Here is the entire CSS that I used for the editor.

html,
body {
  height: 100vh;
  width: 100vw;
  padding: 0;
  margin: 0;
}

#editor {
  height: 100%;
  width: 100%;
  box-sizing: border-box;
  display: grid;
  grid-template: 1fr / 1fr;
  place-items: top;
  overflow: auto;
  padding: 2rem;
  background-color: #1a1723;
}

#editor .code,
#editor .preview {
  all: unset;
}

#editor .code,
#editor .preview {
  height: auto;
  grid-column: 1 / 1;
  grid-row: 1 / 1;
  font-family: Monaco, monospace;
  font-size: 16px;
  resize: none;
  line-height: 24px;
  white-space: pre-wrap;
  overflow: hidden;
}

#editor .preview {
  pointer-events: none;
  color: #ccc;
}

#editor .code {
  color: rgba(255, 255, 255, 0);
  caret-color: magenta;
}

Overlapping the elements

One of the key parts here is using display grid to overlay the textarea and the preview

#editor {
  ...
  display: grid;
  grid-template: 1fr / 1fr;
  place-items: top;
  overflow: auto;
  ...
}

I am using the fr unit to overlap the two elements inside the container. You can read more about fr at CSSTricks here.

Stying the textarea and preview identically

You may notice that I apply the same rules to the preview and the textarea. This ensures that they overlap precisely.

#editor .code,
#editor .preview {
  height: auto;
  grid-column: 1 / 1;
  grid-row: 1 / 1;
  font-family: Monaco, monospace;
  font-size: 16px;
  resize: none;
  line-height: 24px;
  white-space: pre-wrap;
  overflow: hidden;
}

Make the textarea transparent

Using rgba for the text color allows me to have the text entirely transparent, so it seems like you are selecting and editing the preview.

#editor .code {
  color: rgba(255, 255, 255, 0);
  caret-color: magenta;
}

A small bit of Javascript

We do need a small amount of Javascript to tie this all together. Let's take a look at what we need.

const $preview = document.querySelector("#editor .preview");
const $code = document.querySelector("#editor .code");

function mirror() {
  // make textarea grow to height of content so we can scroll together
  $code.style.height = $code.scrollHeight;
  // update the preview underlay with the syntax highlight
  $preview.innerHTML = Prism.highlight(
    $code.value,
    Prism.languages.javascript,
    "javascript",
  );
}
// insert two spaces on tab
$code.addEventListener("keydown", (ev) => {
  if (ev.code === "Tab") {
    ev.preventDefault();
    $code.setRangeText("  ", $code.selectionStart, $code.selectionStart, "end");
    mirror();
  }
});

$code.addEventListener("input", mirror);
mirror();

We will be using Prism for this, but you could use anything you like.

The `mirror()` function is doing a couple of things here.

$code.style.height = $code.scrollHeight;

This ensures that as you type, the height of the <textarea> grows, so that the container will scroll instead of the <textarea> itself. You have probably seen this used to make "auto-growing" textareas before.

$preview.innerHTML = Prism.highlight(
    $code.value,
    Prism.languages.javascript,
    "javascript",
  );

Then we are using Prism to take the code from the <textarea> syntax highlight it and place the result in the preview <div>

Supporting tab indentation

Anytime you are editing code, you need to be able to indent, and this bit of code allows us to add in spaces when someone hits tab, and then call mirror() again to update the preview.

$code.addEventListener("keydown", (ev) => {
  if (ev.code === "Tab") {
    ev.preventDefault();
    $code.setRangeText("  ", $code.selectionStart, $code.selectionStart, "end");
    mirror();
  }
});

Finally, we add an eventListener for input on the <textarea> and update the preview with mirror() on each change. Then we call mirror() initially, in case there is already code in the <textarea> at page load.

That's it! Obviously, if you were be editing thousands and thousands of lines of code, you might hit performance issues updating all that syntax highlighted code. One way to improve on this idea would be to create a "virtual" scroller, and only highlight the code that is visible in the containers view. This is how VsCode does their editor.

If you would like to play around with this, you can find the
code and a working example on GitHub

You don't need Vuex / Pinia for shared state in Vue.

David Morrow — Fri, 24 May 2024 20:48:58 +0000

Since Vue.js 3.x, you no longer need to use Vuex to share a centralized state with all your application's components.

A brief history of shared state in Vue.js

If you have been using Vue.js before 3.x you are probably familiar with Vuex now renamed Pinia. It allows you to have a centralized state that is shared across all your application components. If you have ever found yourself in situations where you are passing data/props between components and things are getting complicated, a centralized state is the answer.

Flux libraries are like glasses: you’ll know when you need them.

The simplest way to share the state between components.

Since Vue.js 3.x reactive and computed are exported directly from the library and can be used outside of components. This is the exact same functionality that you are using when you have data or computed inside of one of your Vue.js components.

import { reactive, computed } from 'vue';

This is great because it means that we can create our own reactive data, and even computed properties outside of Vue components, in plain Javascript files!

Example of shared state

import { reactive, computed } from "vue";

const state = reactive({
  hobby: "Hike",
  fruit: "Apple",
  fruitOptions: ["Banana", "Apple", "Pear", "Watermelon"],

  description: computed(() => {
    return `I like eating ${state.fruit}s & ${state.hobby}`;
  }),
});

export default state;

Here we have an Object with properties, which is wrapped in reactive this gives Vue the ability to trigger change, and re-render your components.

Computed

We are also wrapping a function in computed which gives us a computed property based on the the other fields in the state.

It is important to note, that we invoke the reactive function, and THEN export the resulting state, otherwise we would create a new state each time we imported the file.

Usage in your components

Great, we have a reactive store, but how do we leverage this in our components, and will they all stay in sync?

<template>
  <main class="container">
    <article>
      <header>
        Your description: <code>{{ state.description }}</code>
      </header>
      <survey-form />
      <footer>
        <results />
      </footer>
    </article>
  </main>
</template>

<script>
import Results from "./Results.vue";
import SurveyForm from "./SurveyForm.vue";
import state from "./state.js";

export default {
  components: { SurveyForm, Results },
  data() {
    return { state };
  },
};
</script>

It's as simple as importing the state, and referencing it in your component's data method so it can be accessed in your template.

You can even v-model items in your store the same as you would with any data property in your component.

<template>
  <form>
    <label>
      Favorite Hobby?
      <input placeholder="Favorite Hobby" v-model="state.hobby" />
    </label>

    <label>
      Favorite Fruit?
      <select v-model="state.fruit">
        <option v-for="fruit in state.fruitOptions" :key="fruit">{{ fruit }}</option>
      </select>
    </label>
  </form>
</template>

<script>
import state from "./state.js";

export default {
  name: "SurveyForm",
  data() {
    return { state };
  },
};
</script>

You can see the full example on Github and view the code here

I hope you find this pattern as useful as I have. Happy developing!

Using React without JSX == no build

David Morrow — Wed, 04 Jan 2023 23:09:27 +0000

Removing the build step unleashes React to situations where it would ordinarily be too heavy-handed.

Have you ever wanted to use React without a build step? Ever find yourself in a situation where you would love to use React, but you are not building a single-page application with routes and so forth? Do you just need a component/widget on a page with a high level of interactivity?

So why does React need a build step/transpiler in the first place? Can't you just load React off a CDN and be up and running? Well, yes but you are usually going to use templates, and that is where JSX comes in which does need a compiler.

React without JSX

As it states on the React docs site,

JSX is not a requirement for using React. Using React without JSX is especially convenient when you don’t want to set up compilation in your build environment.

The linked page above goes on to show the following examples of JSX,

class Hello extends React.Component {
  render() {
    return <div>Hello {this.props.toWhat}</div>;
  }
}

const root = ReactDOM.createRoot(document.getElementById("root"));
root.render(<Hello toWhat="World" />);

and what the compiled output would look like

class Hello extends React.Component {
  render() {
    return React.createElement("div", null, `Hello ${this.props.toWhat}`);
  }
}

const root = ReactDOM.createRoot(document.getElementById("root"));
root.render(React.createElement(Hello, { toWhat: "World" }, null));

It even provides a playground for writing JSX and seeing what the resulting Javascript output would be. Pretty neat.

That's great, we don't need a build step. But for me, that's not going to be super practical to work with. The great thing about modern Javascript frameworks is that they let you dynamically work with HTML. Going bare metal on React.createElement does not feel like a great developer experience for me.

There are a few choices of libraries that ease the use of React.createElement such as react-hyperscript. It provides some shorthands for creating elements, but for me it just feels a little too abstracted from the HTML your will be outputting.

var h = require("react-hyperscript");
var React = require("react");

var AnotherComponent = require("./another-component");

module.exports = React.createClass({
  render: function render() {
    return h("div.example", [
      h("h1#heading", "This is hyperscript"),
      h("h2", "creating React.js markup"),
      h(AnotherComponent, { foo: "bar" }, [
        h("li", [h("a", { href: "http://whatever.com" }, "One list item")]),
        h("li", "Another list item"),
      ]),
    ]);
  },
});

But for me, (and I think many React developers), writing HTML feels most natural. Your component ultimately renders HTML, so it just makes sense that your template is written in an HTML-like structure, thus the popularity of JSX.

HTM Templates

There is however a library that is closer to JSX (HTML-like feel) but yet does not require a build step. htm. HTM uses tagged templates to leverage template literal as native Javascript template strings. If you have not played with tagged templates, I encourage you to check this out, it's a quite powerful feature, that has recently become a part of Javascript.

If you are planning on using HTM for any length of time, I highly encourage the VSCode extension to highlight your HTML strings as HTML. Not only does it give you syntax highlighting for HTML inside your javascript, but it also formats it on save just as you would expect.

Tagged templates allow you to send a template literal string to a function to run additional processing/actions on the string. You can read more about tagged templates here. But the important thing to know is that they are supported in all major browsers.

Let's see some examples

Ok, let's take a look at what a super simple app would look like using HTM instead of JSX. In this example component, we are simply going to have a header with a name and hobbies, and then the ability to update those values.

To get started let's first load what Javascript we need off CDN into our HTML file, and then start our application.

<head>
  <body>
    <div id="app">
      <!-- the application will be rendered here -->
    </div>

    <script
      crossorigin
      src="https://unpkg.com/react@18/umd/react.production.min.js"
    ></script>
    <script
      crossorigin
      src="https://unpkg.com/react-dom@18/umd/react-dom.production.min.js"
    ></script>

    <script type="module">
      import htm from "https://unpkg.com/htm?module";
      const html = htm.bind(React.createElement);

      import App from "./App.js";
      ReactDOM.render(html`<${App} />`, document.getElementById("app"));
    </script>
  </body>
</head>

So we have loaded React and ReactDOM into our HTML file, and then loaded HTM and our <App/> component as modules.
(React unfortunately does not have esm versions available to load from CDNs) so we will just load them in separate script tags on the page and reference them off the window object where they assign themselves.

Binding html to `React.createElement`

HTM is a generic library, so to get it working with React, we have to bind it to React.createElement. This essentially sets createElement as the tagged template function for our HTML string.

import htm from "https://unpkg.com/htm?module";
const html = htm.bind(React.createElement);

We then render our App component

ReactDOM.render(html`<${App} />`, document.getElementById("app"));

Let's look at our App component. You will notice how similar this is to what you would have written using JSX.

import { useState, createElement } from "react";
import htm from "htm";
import Hobbies from "./Hobbies.js";
import "../index.css";

const html = htm.bind(createElement);

function App() {
  const [name, setName] = useState("Dave");
  const [hobbies, setHobbies] = useState("bonsai, sewing, running");

  return html`<div class="container">
    <article>
      <header>
        <hgroup>
          <h1>Hello there!</h1>
          <h2>
            My name is <mark>${name}</mark>, and my hobbies include
            <hr />
            ${hobbies
              .split(",")
              .map((hobby) => html`<kbd>${hobby.trim()}</kbd>`)}
          </h2>
        </hgroup>
      </header>
      <label>
        Name
        <input value=${name} onChange=${(ev) => setName(ev.target.value)} />
      </label>
      <label>
        Hobbies
        <${Hobbies} hobbies=${hobbies} setHobbies=${setHobbies} />
      </label>
    </article>
  </div>`;
}

export default App;

The app component in turn renders the Hobbies component which looks like this. I could have combined them together into just one component, but I wanted to give an example of loading a child component as we see with <${Hobbies}>

import { createElement } from "react";
import htm from "htm";

const html = htm.bind(createElement);

function Hobbies({ hobbies, setHobbies }) {
  return html`<textarea
    value=${hobbies}
    onChange=${(ev) => setHobbies(ev.target.value)}
  ></textarea>`;
}

export default Hobbies;

Differences between HTM and JSX

Although as we have discussed, it looks very similar to JSX, and in turn HTML. There are a few key differences that I would like to point out.

Interpolate Component Names

As you may have already seen, you have to "interpolate" component names when rendering them rather than just using them like a custom DOM element as in JSX.

In JSX

<label>
  Hobbies
  <Hobbies hobbies={hobbies} setHobbies={setHobbies}></Hobbies>
</label>

HTM equivalent

 <label>
  Hobbies
  <${Hobbies} hobbies=${hobbies} setHobbies=${setHobbies} />
</label>

You can use class instead of className for your classes!

This one is huge for me. It has always bothered me that you have to use className for the class attribute in JSX. I'm not sure why that bothers me as much as it does, but I think about it every time I add a class to an element in JSX.

<div className="my-class"></div>

<div class="my-class"></div>

You must Invoke the HTML method when returning HTML

For example, when we list our hobbies in a loop, we are returning HTML so we have to call the HTML method.

${hobbies.split(",")
  .map((hobby) => html`<kbd>${hobby.trim()}</kbd>`)}

Quotes are optional

Quotes around element attributes dynamic or static are entirely optional

<div class="foo"></div>

Self-Closing Tags

HTM will let you use self-closing tags on anything.

<div />

Closing Component tags

As HTM requires you to interpolate your component name when rendering, it has a handy feature that lets you close a component with <//> instead of having to redo the name again.

<${Footer}>footer content<//>

Spread Props

If you would like to assign a component's props as attributes to an element, usually the root, in JSX you would do so as such.

<div {...props}>

In HTM you would do the same, just the spread operator on the outside of the string interpolation.

<div ...${props}>

Boolean Attributes

I love this feature actually if you have ever struggled with boolean attributes such as checked or selected and so forth you might as well.

const checked = true;
return html`<input type="checkbox" checked=${checked} /> `;

Multiple Root elements

JSX does not allow you to have multiple root elements. HTM does! If you are ever found yourself wrapping your component in React.Fragment just so you can structure your DOM the way you want, you will love this.

In JSX

return <React.Fragment>
  <div>root item one</div>
  <div>root item two</div>
</React.Fragment>

In HTM

return html`<div>root item one</div>
  <div>root item two</div>`;

HTML Comments

You can leverage normal HTML comments in your templates. This is not possible in JSX

Pre-compiling setup

I know the huge reason you would choose HTM over JSX is to leave the build step behind. Having said that, I recently used HTM on a project that required a build step for other reasons. Having gotten comfortable with HTM on several small Preact (no build) projects, I wanted to keep using it.

One of the main things that I miss with a no-compile setup is the hot module reload. Once you have worked with HMR, it is quite addictive, and it's hard to go back to hitting reload 400 times an hour :)

I'll give a quick example of how to integrate HTM into a boilerplate create-react-app application.

npm i create-react-app react-htm
npm i htm --save-dev
npm serve

In your entry file index.js change the file to the following.

import { createRoot } from "react-dom/client";
import { createElement } from "react";
import htm from "htm";
import App from "./App.js";

const html = htm.bind(createElement);
const root = createRoot(document.getElementById("root"));
root.render(html`<${App} />`);

Then, in the App.js file, change the component to the following

import logo from "./logo.svg";
import "./App.css";
import { createElement } from "react";
import htm from "htm";
const html = htm.bind(createElement);

function App() {
  return html`<div class="App">
    <header class="App-header">
      <img src="${logo}" class="App-logo" alt="logo" />
      <p>Edit <code>src/App.js</code> and save to reload.</p>
      <a
        class="App-link"
        href="https://reactjs.org"
        target="_blank"
        rel="noopener noreferrer"
      >
        Learn React
      </a>
    </header>
  </div>`;
}

export default App;

You are now running your application with HTM for your templates. Your build and HMR will work exactly as you are accustomed to. I hope you have enjoyed delving into this alternative to JSX, and find it useful in a future situation you find yourself in.

Build an 80 line JS Framework

David Morrow — Thu, 22 Dec 2022 04:15:45 +0000

Before I get started, I want to share where the final code is, as well as a working example.

We have all used Reactive javascript frameworks, but have you ever tinkered with making your own, or have been curious whats going on under the hood?

By "reactive" I mean, you make a change to your data, and your template or DOM automatically update. No manual updating ect...

Well, this post is about my attempt to make the smallest possible component that does the following.

Lets get started

For our example, I'm going to build a Todo list, where we can add, delete and mark done a list of items to complete. We will also be able to update the title as we type.

Just an FYI, will be using native es modules, and no build steps in my examples for simplicity.

working app here

<div class="container" id="app">
  <!-- our app is rendered here -->
</div>

<script type="module">
  import App from "./Todos.js";

  const $root = document.getElementById("app");
  $root.innerHTML = new App($root).render();
</script>

So to start the application, we will render it to a DOM element in our HTML. We are also passing in the element to our class, we will need this later.

The Todos component

import Component from "./lib/Component.js";

export default class Todos extends Component {
  constructor() {
    super(...arguments);

    this.state = this.useState({
      title: "Things Todo",
      todos: [
        {
          done: true,
          title: "Walk the Dog",
        },
        {
          done: false,
          title: "Grocery Shop",
        },
        {
          done: false,
          title: "X-Mas Shop",
        },
      ],
    });
  }

  toggle({ target }, index) {
    this.state.todos[index].done = target.checked;
  }

  updateTitle({ target }) {
    this.state.title = target.value;
  }

  deleteTodo(ev, index) {
    ev.preventDefault();
    this.state.todos.splice(index, 1);
  }

  addTodo() {
    const $titleInput = this.$root.querySelector("[name=newTodo]");

    this.state.todos.push({
      title: $titleInput.value,
      done: false,
    });

    $titleInput.value = "";
    $titleInput.focus();
  }

  render() {
    return /*html*/ `<article>
      <header>
        <hgroup>
          <h1>${this.state.title}</h1>
          <h2>
            An example of a mini reactive component, make changes and watch the
            DOM update.
          </h2>
        </hgroup>
      </header>

      <input
        type="text"
        value="${this.state.title}"
        data-on="input->updateTitle"
        data-args="title"
        autofocus
      />

      <table role="grid">
        <thead>
          <tr>
            <th>Done</th>
            <th>Title</th>
            <th></th>
          </tr>
        </thead>
        <tbody>
          ${this.state.todos.reduce(
            (html, todo, index) =>
              (html += /*html*/ `<tr>
                <td>
                  <input
                    type="checkbox"
                    data-on="click->toggle"
                    data-args="${index}"
                    ${todo.done ? "checked" : null}
                  />
                </td>

                <td>${todo.done ? `<s>${todo.title}</s>` : todo.title}</td>

                <td>
                  <a href="#" data-on="click->deleteTodo" data-args="${index}">
                    Delete
                  </a>
                </td>
              </tr>`),
            ""
          )}
        </tbody>
      </table>

      <footer>
        <div class="grid">
          <input name="newTodo" placeholder="Todo title" type="text" />
          <button data-on="click->addTodo">Add</button>
        </div>
      </footer>
    </article>`;
  }
}

It may look like a lot, but keep in mind this is an entire todo app and template. I'll go over each piece in detail, I just wanted to show you the end result first.

The constructor

import Component from "./lib/Component.js";

export default class Todos extends Component {
  constructor() {
    super(...arguments);
    ...
  }

Here we are importing our Component class and extending it with our Todos class. We call super with any arguments passed into our class.

Component State

Next, also in the constructor, we setup the state. This is what will be observable, meaning every time something in here is changed, our component will re-render, and the DOM will be patched with the changes.

this.state = this.useState({
  title: "Things Todo",
  todos: [
    {
      done: true,
      title: "Walk the Dog",
    },
    {
      done: false,
      title: "Grocery Shop",
    },
    {
      done: false,
      title: "X-Mas Shop",
    },
  ],
});

The template

I just using generic template literals here, but we could return HTML however we wanted really, Mustache, JSX, HTM it doesn't really matter as far as our component is concerned. It just wants an HTML string returned.

Our template uses our state, and renders the HTML. For example our header displays the title.

<h1>${this.state.title}</h1>

Each time our render function is called, the HTML will be updated with the latest version of this.state

Event handling

We have data, and we have HTML. But that doesn't do us much good if we can't trigger changes to the data, so we need some event handling.

<a href="#" data-on="click->deleteTodo" data-args="${index}"> Delete </a>

I've chosen to just use data attributes as triggers here.
For example if you look at the delete todo link. On click trigger function deleteTodo. Simple enough.

You will notice I also have an data-args attribute. This will pass these values as parameters to the method. In this case, it is the index that will let our function know which todo we are wishing to delete.

But how does this work?

Yeah... remember the whole reason I started this post was to wanted to show some of the basic building blocks of a reactive framework.

We have seen it from our Todos class that has state, template and event handlers. Let's now take a look at the Component class.

Ok so here is the entire Component class which our Todos class extends.

import Morphdom from "https://unpkg.com/morphdom@2.6.1/dist/morphdom-esm.js";
import observer from "./observer.js";

export default class Component {
  handlers = ["click", "input"];
  observable;

  constructor($root) {
    this.$root = $root;
    this.handlers.forEach((type) =>
      this.$root.addEventListener(type, this.#handleEvent.bind(this))
    );
  }

  useState(value) {
    return observer(value, this.updateDom.bind(this));
  }

  #handleEvent(ev) {
    const { type, target } = ev;
    const on = target.dataset.on;

    if (!on) return;

    const args = target.dataset.args ? target.dataset.args.split(",") : [];
    const [eventType, method] = on.split("->");

    if (eventType !== type) return;

    if (!this[method]) {
      console.error(
        `${method} does not exist in component ${this.constructor.name}`,
        ev.target
      );
    } else this[method].call(this, ev, ...args);
  }

  updateDom() {
    Morphdom(this.$root.firstChild, this.render(), {
      onBeforeElUpdated: (fromEl, toEl) => !fromEl.isEqualNode(toEl),
    });
  }

  render() {
    console.error(`${this.constructor.name} must provide a render function!`);
  }
}

Pretty tiny, just like I promised. It's really only a couple of methods.

The constructor

Let's start with the constructor

handlers = ["click", "input"];

constructor($root) {
  this.$root = $root;
  this.handlers.forEach((type) =>
    this.$root.addEventListener(type, this.#handleEvent.bind(this))
  );
}

We save a reference to the $root element, _we need this when we re-render, and add event handlers to the $root for each type of event we support.

We could easily add many more types of events to listen to, but for this example these were all we needed.

Notice that the addEventListener is added to the $root itself instead of on each element that has a data-on attribute. This allows us to just have one handler for each type of even, and also never have to add / remove event listeners ever again throughout the life of this component. Pretty handy. More on that in a second...

useState method

useState(value) {
  return observer(value, this.updateDom.bind(this));
}

As we saw earlier, our Todos component called useState with our data, then saved the return value as this.state.

But whats happening here? As discussed in the previous post Create an Observable Object using Proxy we have the ability to create an observable Proxy object. We create one here, and return it, while passing our updateDom as the callback function. This will fire each time our data is changed.

Handling events

#handleEvent(ev) {
  const { type, target } = ev;
  const on = target.dataset.on;

  if (!on) return;

  const args = target.dataset.args ? target.dataset.args.split(",") : [];
  const [eventType, method] = on.split("->");

  if (eventType !== type) return;

  if (!this[method]) {
    console.error(
      `${method} does not exist in component ${this.constructor.name}`,
      ev.target
    );
  } else this[method].call(this, ev, ...args);
}

In our constructor we added event listeners to our $root element. This is the handler we passed in.

const { type, target } = ev;
const on = target.dataset.on;

if (!on) return;

We check if the target has a data-on property, if not, no point in continuing further.

const args = target.dataset.args ? target.dataset.args.split(",") : [];
const [eventType, method] = on.split("->");

if (eventType !== type) return;

Next we gather any data-args values as an array that we can pass to our method, and then see if our eventType matches the type on our element, example click of click->deleteTodo

if (!this[method]) {
  console.error(
    `${method} does not exist in component ${this.constructor.name}`,
    ev.target
  );
} else this[method].call(this, ev, ...args);

Lastly, we make sure the method exists in our class, in this case Todos, if not console.error showing the element where the error came from helping us debug.

If the method exists, we call it invoking call providing the scope this so that our method has the correct this when invoked. can access this.state for example.

Call also gives us the ability to pass in arguments, we are passing in the ev event and then any data-args split into an array.

Updating the DOM

Ok the whole point of this thing is to automatically update the DOM to reflect our template as the data changes. So how does that happen? It takes place in the updateDom function that we sent as the callback to our observable. This function gets called each time there is a set on our data, at any level.

updateDom() {
  Morphdom(this.$root.firstChild, this.render(), {
    onBeforeElUpdated: (fromEl, toEl) => !fromEl.isEqualNode(toEl),
  });
}

It's super simple actually. And that is in large part to Morphdom which I'm using to compare the output of render() to what is already on the DOM. Morphdom will patch the differences.

The only extra thing I'm doing here is bailing on traversing further down the DOM if the nodes are equal, preventing some checking of children if the parents are already deemed to be equal.

Summary

And thats pretty much it. This little Component class certianly is not the next React killer, but it was a fun little experiment into some of the fundamental concepts of a front end framework which I would outline as follows.

A template that renders HTML with your data
Detecting when your data has changed
event handlers managed on our template without having to do it manually after each render
re-rendering your template with the new state of your data
comparing the current DOM with your re-rendered HTML and patching the differences

Next steps

So what if this was a real project, what would we be looking at building next? Whats missing? Here are some thoughts.

Instead of re-rendering the entire component, and patching the difference, a way to target only the portions of the template that reference data that was changed. Frameworks like Preact and Svelte do this very well, surgically targeting DOM element and attributes that reference certain pieces of data.

The ability to render sub components. Say we wanted to render a Todo component for each todo in our todos array.

Create an Observable Object using Proxy

David Morrow — Fri, 25 Nov 2022 02:53:46 +0000

Have you ever needed to "observe" an object for changes? If you have ever used Vuejs or React, this is what is happening under the hood. Data gets changed, something re-renders. It's the core building block of almost every front end framework.

React uses their own setState to understand when data is changing, but Vue and many others use Javascript's native Proxy which is what we will look at here. Proxy lets you interact with the object like you normal, which I highly prefer to calling setters like in React or Ember.

In this little excersize, we are going to build an "observable" library, that will make Javascript objects observable for change.

Ill take it step by step, but if you just wanna jump to the final code, here you go

How does Proxy work?

So proxy works by calling new Proxy() wich takes two arguments,

first argument: the plain object which you are going to be "observing" we will refer to this from here on as poj (Plain Javascript Object) to make things clearer.
second argument: the handler object aka "the trap" as we will refer to it.

The trap allows you to hook into when set, delete, get and other actions are taken on the object. The Reflect object lets you hook into the normal actions that would occur during the operations on the object. In this case, setting the value. More info here

const trap = {
  set(target, prop, value) {
    console.log(prop, "is being set to", value);
    return Reflect.set(...arguments);
  },
};

const poj = { name: "David" };
new Proxy(poj, trap);

Let's see it in action

So given the code above, lets see how we could observe changes to our object.

const data = new Proxy(poj, trap);
data.name = "fred";

"name is being set to fred"

Cool that worked! We can see when a change happens to our object.

What about nested Objects?

But what about if our POJ has nested objects?

const poj = {
  name: "David",
  children: [{ name: "Oliver" }],
};

const data = new Proxy(poj, trap);
data.children[0].name = "fred";

Nothing happens. Why? Well what's happening is that our object has child objects, which are not Proxys, they are Plain Old Javascript Objects. In order to listen for changes in nested objects, we would need to wrap those in new Proxy() as well. But how can we do that?

Add a get hook into our trap

The Proxy handler object, our trap provides a get function that can be used. This will trigger each time a value is retrieved, and we can hook into this and control what gets returned.

Instead of just returning the value, if we are working with an Object, we will wrap it in Proxy and then return it just like we did on the top level.

const trap = {
  ...

  get(target, prop) {
    const value = Reflect.get(...arguments);

    if (
      value &&
      typeof value === "object" &&
      ["Array", "Object"].includes(value.constructor.name)
    )
      return new Proxy(value, trap);

    return value;
  },
};

If we are going to return an Object or Array, we reutrn a wrapped Proxy instead.
We are checking that

have a value instead of null or undefined
is typeof object
and the constructor.name is either "Array" or "Object"

If we add the above method and run we now see

"name is being set to fred"

Capturing more useful output

Great, we are observing changes on nested objects, but it's hard to tell whats happening, we have a name property on the root and in each of the children. What would really be helpful is to know the path that was changed. Like children.0.name. Let's fix that.

function buildProxy(poj, tree = []) {
  const getPath = (prop) => tree.concat(prop).join(".");

  const trap = {
    set(target, prop, value) {
      console.log(getPath(prop), "is being set to", value);
      return Reflect.set(...arguments);
    },

    get(target, prop) {
      const value = Reflect.get(...arguments);

      if (
        value &&
        typeof value === "object" &&
        ["Array", "Object"].includes(value.constructor.name)
      )
        return buildProxy(value, tree.concat(prop));

      return value;
    },
  };

  return new Proxy(poj, trap);
}

So we have now wrapped the creation of our Proxies in a method called buildProxy wich will allow us to keep passing down the tree that we have traversed. Then when we have a change we can know the path to the item that has changed.

Each time we find a nested Object, we push on the current property to the tree and call the buildProxy method again. The concat method is similar to push, only it creates a new Array instead of effecting the original.

return buildProxy(value, tree.concat(prop));

Ok, lets try it now and see what happens.

const poj = {
  name: "David",
  children: [{ name: "Oliver" }],
};

const data = buildProxy(poj);
data.children[0].name = "fred";

"children.0.name is being set to fred"

Callback instead of logging

Great thats what we wanted. We have our path to what changed, and what it's being changed to. But the console.log is not really that useful. Like the example I gave up top, say we were trying to re-render based on changes. What we really need is a hook for the changes. Lets fix that.

function buildProxy(poj, callback, tree = []) {
  const getPath = (prop) => tree.concat(prop).join(".");

  const trap = {
    set(target, prop, value) {
      callback({
        action: "set",
        path: getPath(prop),
        target,
        newValue: value,
        previousValue: Reflect.get(...arguments),
      });
      return Reflect.set(...arguments);
    },

    get(target, prop) {
      const value = Reflect.get(...arguments);

      if (
        value &&
        typeof value === "object" &&
        ["Array", "Object"].includes(value.constructor.name)
      )
        return buildProxy(value, callback, tree.concat(prop));

      return value;
    },
  };

  return new Proxy(poj, trap);
}

So main things changed here are we are now passing a callback in addition to the tree. This will give us a method to call when something changes, rather than just logging it out which is not that useful.

function buildProxy(poj, callback, tree = []) {
  ...
}

And then we also need to pass that when we find nested Objects

return buildProxy(value, callback, tree.concat(prop));

Lastly, we are adding a couple more things to the return object we are sending to our callback.

callback({
  action: "set",
  path: getPath(prop),
  target,
  newValue: value,
  previousValue: Reflect.get(...arguments),
});
return Reflect.set(...arguments);

We added an action to the object, so the consumer of our callback will know what type of action took place on our Object.
we added previousValue so that you can compare the old value to the new value being changed.

We are doing this by using Reflect.get to capture the current value before we set the new value.

putting it all together, this is how you would use the little Observer library we just wrote.

const poj = {
  name: "David",
  children: [{ name: "Oliver" }],
};

const data = buildProxy(poj, (change) => {
  console.log(change);
});

data.children[0].name = "fred";

{
  action: 'set',
  path: 'children.0.name',
  target: { name: 'Oliver' },
  newValue: 'fred',
  previousValue: 'Oliver'
}

There are many other actions you can trap in the Proxy handler. You might want to add delete at least. But by just using set and get, we are able to observe most changes that could occur to our object.

Wrapping up

Here is the final "Observer Library" thanks for reading and I hope you find this useful.

function buildProxy(poj, callback, tree = []) {
  const getPath = (prop) => tree.concat(prop).join(".");

  return new Proxy(poj, {
    get(target, prop) {
      const value = Reflect.get(...arguments);

      if (
        value &&
        typeof value === "object" &&
        ["Array", "Object"].includes(value.constructor.name)
      )
        return buildProxy(value, callback, tree.concat(prop));

      return value;
    },

    set(target, prop, value) {
      callback({
        action: "set",
        path: getPath(prop),
        target,
        newValue: value,
        previousValue: Reflect.get(...arguments),
      });
      return Reflect.set(...arguments);
    },

    deleteProperty(target, prop) {
      callback({ action: "delete", path: getPath(prop), target });
      return Reflect.deleteProperty(...arguments);
    },
  });
}

export default buildProxy;

And how you would use this in your code

import Observer from "./observer.js";

const data = Observer(
  {
    name: "David",
    occupation: "freelancer",
    children: [{ name: "oliver" }, { name: "ruby" }],
  },
  console.log
);

data.name = "Mike";
data.children.push({ name: "baby" });
data.children[0].name = "fred";
delete data.occupation;

and you would see the following log output

{
  action: 'set',
  path: 'name',
  target: {
    name: 'David',
    occupation: 'freelancer',
    children: [ [Object], [Object] ]
  },
  newValue: 'Mike',
  previousValue: 'David'
}
{
  action: 'set',
  path: 'children.2',
  target: [ { name: 'oliver' }, { name: 'ruby' } ],
  newValue: { name: 'baby' },
  previousValue: undefined
}
{
  action: 'set',
  path: 'children.length',
  target: [ { name: 'oliver' }, { name: 'ruby' }, { name: 'baby' } ],
  newValue: 3,
  previousValue: 3
}
{
  action: 'set',
  path: 'children.0.name',
  target: { name: 'oliver' },
  newValue: 'fred',
  previousValue: 'oliver'
}
{
  action: 'delete',
  path: 'occupation',
  target: {
    name: 'Mike',
    occupation: 'freelancer',
    children: [ [Object], [Object], [Object] ]
  }
}

Speed up your code with Promise.all

David Morrow — Wed, 23 Nov 2022 21:15:15 +0000

So one of the things I see commented on all the time in Javascript code reviews.

Say you have some code as such...

async function myFunction() {
  await someThing();
  await someOtherThing();
  await yetAnotherThing();
}

Do we need to each of these one at a time? Cant we fork this and call them all together?

What being pointed out here is that we have to wait on each one of these Promises to return before the next one can start.

One of the most amazing things about working with Javascript is its concurrency. Meaning it can run your code in parallel instead of waiting for each Promise to finish before moving starting the next. Commonly referred to as "forking".

Using Promise.all vs await each

Since this ability is so powerful, lets make sure we are using it. Let's take a look at the example above and see how we can make that run in parallel.

function delayedResponse() {
  return new Promise((resolve, reject) => {
    setTimeout(resolve, 1000);
  });
}

async function time(label, fn) {
  const start = new Date();
  await fn();
  console.log(
    (new Date() - start) / 1000, `seconds to load ${label}`
  );
}

time("sequential", async () => {
  await delayedResponse();
  await delayedResponse();
  await delayedResponse();
});

time("parallel", async () => {
  await Promise.all([
    delayedResponse(), 
    delayedResponse(), 
    delayedResponse()
  ]);
});

Ok, here is some code that we can test this idea with. I have a function that returns a Promise that takes 1sec to resolve.

function delayedResponse() {
  return new Promise((resolve, reject) => {
    setTimeout(resolve, 1000);
  });
}

and a function that times how long a function passed to it takes to run.

async function time(label, fn) {
  const start = new Date();
  await fn();
  console.log(
    (new Date() - start) / 1000, `seconds to load ${label}`
  );
}

These are not important, I just wanted to explain what they were. The main thing that we are talking about here is the difference in speed with the two approaches we are timing here.

Ok lets run this code and see what happens.

1.002 seconds to load parallel
3.005 seconds to load sequential

Whoah... that's almost 3 times as fast for the parallel one. Makes sense, as there are three calls and each one takes a second. You can see how this would greatly effect your performance if you had many Promises to wait on.

Say for example we had 6 calls instead of 3. What would the timing on that look like?

1.002 seconds to load parallel
6.009 seconds to load sequential

You guessed it, twice as much on the difference.

Real world example

Say for example you have a front end app that makes a few API requests before it's ready to render and become interactive. This could make a HUGE difference to your users.

Capturing the responses

One of the common excuses I have seen for awaiting each Promise is that,

But I need to save each response from each Promise

async function () {
  const myData = await someApiCall();
  // do something with your data...
}

You can still do that with Promise.all. Promise.all returns the results in an Array in the order that the Promises were invoked, not in the order that they resolve. This is a common misconception.

Ok lets test this idea.

function randomDuration() {
  const min = 500;
  const max = 1000;
  return Math.random() * (max - min) + min;
}

function delayedResponse(msg) {
  return new Promise((resolve, reject) => {
    setTimeout(resolve, randomDuration(), msg + ": done");
  });
}

async function time(label, fn) {
  const start = new Date();
  await fn();
  console.log(
    (new Date() - start) / 1000, `seconds to load ${label}`
  );
}

// the code we are benchmarking

async function sequential() {
  const res1 = await delayedResponse("first");
  const res2 = await delayedResponse("second");
  const res3 = await delayedResponse("third");
  console.log([res1, res2, res3]);
}

async function parallel() {
  const results = await Promise.all([
    delayedResponse("first"),
    delayedResponse("second"),
    delayedResponse("third"),
  ]);
  console.log(results);
}

time("sequential", sequential);
time("parallel", parallel);

Ok the main difference here is that I am giving each Promise a random duration before it returns, between 1/2 and 1 second. That way I can show that they come back in the order invoked, not the order resolved.

[ 'first: done', 'second: done', 'third: done' ]
0.921 seconds to load parallel
[ 'first: done', 'second: done', 'third: done' ]
2.393 seconds to load sequential

Notice that even though I randomized how long each Promise will take to resolve, the results array is in the order that I called them in. Fantastic.

Example where this won't work

There are some cases where you cannot call all your promises at the same time. Take for example API calls like I mentioned above. Say you need part of the result from one, before you can call the next.

For example say you are using REST routes that are nested...

async function () {
  const user = await Api.getUser();
  const account = await Api.getAccount(user.id);
  const articles = await Api.getArticles(user.id);
}

Well, you cant call all these together, but you may be able to still group some. Just do the best you can :)

async function () {
  const user = await Api.getUser();
  const [account, articles] = await Promise.all([
    Api.getAccount(user.id),
    Api.getArticles(user.id)
  ]);
}

Promise.all vs Promise.allSettled

One very important thing to note, If ANY of the promises reject. Promise.all will reject at the first failure. Think of it as fail fast.

If you need to handle each rejection, and need a response for every Promise no matter what happens, use Promise.allSettled instead of Promise.all

Make hotwired/turbo patch vs replace

David Morrow — Wed, 23 Nov 2022 19:15:30 +0000

So if you have used hotwired/turbo you will get a pretty SPA like experience with very little work. Turbo goes a long way to make a traditional multi page application feel like a SPA (single page application).

Cool, but there is one main difference you may notice. While a SPA patches the DOM on change (usually using Virtual DOM), Turbo replaces the whole body, or the <turbo-frame> that you are targeting / navigating from.

This can be a little jarring, mess with css transitions, loose your focus / scroll position on the page ect. You can read more about the argument for patching vs replacing here

Fortunately, since this PR was merged, you now have access to the internal pageRenderer internal object from Turbo.

Instead of replacing the whole DOM (in most cases the body tag) lets patch the DOM comparing what has changes in the response vs what's currently on the page. This is going to give us a much more SPA like feel.

I'm using morphdom to patch our DOM. Its a very simple library that compares two DOM elements and updates only the differences. It is extremely performant and does not even use a Virtual DOM, just the DOM you already have!

Ok so here we go, when you start up your Turbo application, simply override the pageRenderer.assignNewBody function to use Morphdom instead of just replacing the whole thing which is the default for Turbo.

npm i @hotwired/turbo morphdom --save-dev

import * as Turbo from "@hotwired/turbo";
import morphdom from "morphdom";
import { PageRenderer } from "@hotwired/turbo";

PageRenderer.prototype.assignNewBody = function () {
  if (document.body) {
    morphdom(document.body, this.newElement, {
      onBeforeElUpdated: (fromEl, toEl) => !fromEl.isEqualNode(toEl),
    });
  } else document.documentElement.appendChild(this.newElement);
};

Great, that was pretty easy and now the application feels a little more responsive, less like pJax. Ok so whats going on here?

We have redefined the assignNewBody function within @hotwired/turbo. Instead of replacing the existing <body> element with the new one, we are going to use Morphdom to patch it instead.

  if (document.body) {
    ...
  } else document.documentElement.appendChild(this.newElement);

First we make sure we have a body, if not just append it to the document.

Lastly, a little performance improvement suggested by the Morphdom library here.

 onBeforeElUpdated: (fromEl, toEl) => !fromEl.isEqualNode(toEl)

Make sure the two DOM nodes are not equal before attempting to patch them. This will save some comparison on nodes that you do not need to compare.

If you want to see visually the difference in your re-rendering before and after this modification, add this to your css.

body * {
  animation: highlight 0.2s ease;
}

@keyframes highlight {
  0% {
    outline: 1px solid lightyellow;
  }
  100% {
    outline: 0px solid lightyellow;
  }
}

This will give all your elements a border flash when they are added to the DOM, which gives an indication of what elements were replaced, and which were left alone on the re-render.

I hope you find this useful, and encourages you play with some of these low code solutions to interactivity like Turbo or Htmx before you reach for more heavy handed solutions like React or Vue.

DEV Community: David Morrow

Use Next.js to create a blog from Dev.to API

Getting started

The API endpoints we will be using for our data.

Getting setup to statically render the site

Calling the API

The dynamic article page app/articles/[slug]/page.tsx

Generating the Static Params

Generating the Metadata

Rendering the Markdown to HTML

Rendering our comments

Updating the site

You don't need a CSS pre-processor

Separating files

Nesting rules

Sudo selectors

Variables

Global variables

Scoped variables

Re-assigning values at runtime

Computation

Transforming colors

A Simple, mostly CSS code editor

Contenteditable sucks...

How the illusion works

The HTML code

The CSS

Overlapping the elements

Stying the textarea and preview identically

Make the textarea transparent

A small bit of Javascript

The mirror() function is doing a couple of things here.

Supporting tab indentation

You don't need Vuex / Pinia for shared state in Vue.

A brief history of shared state in Vue.js

The simplest way to share the state between components.

Example of shared state

Computed

Usage in your components

Using React without JSX == no build

Removing the build step unleashes React to situations where it would ordinarily be too heavy-handed.

React without JSX

HTM Templates

Let's see some examples

Binding html to React.createElement

Differences between HTM and JSX

Interpolate Component Names

You can use class instead of className for your classes!

You must Invoke the HTML method when returning HTML

Quotes are optional

Self-Closing Tags

Closing Component tags

Spread Props

Boolean Attributes

Multiple Root elements

HTML Comments

Pre-compiling setup

Build an 80 line JS Framework

Lets get started

The Todos component

The constructor

Component State

The template

Event handling

But how does this work?

The constructor

useState method

Handling events

Updating the DOM

Summary

Next steps

Create an Observable Object using Proxy

How does Proxy work?

Let's see it in action

What about nested Objects?

Add a get hook into our trap

Capturing more useful output

Callback instead of logging

Wrapping up

Speed up your code with Promise.all

The dynamic article page `app/articles/[slug]/page.tsx`

The `mirror()` function is doing a couple of things here.

Binding html to `React.createElement`