DEV Community: Hasani Rogers

Lit is better than React: Signals in Lit

Hasani Rogers — Thu, 19 Feb 2026 15:36:27 +0000

I once asked Gemini about the performance between React and Lit. It led me down a path to enlightenment. Here’s what it told me:

React	Lit
Generally slower (must build the VDOM)	Very fast (native browser templates)
Higher (stores two copies of the DOM tree)	Extremely low (no tree copies needed)
~30KB+ (requires the React runtime)	~5KB (uses native browser APIs)
Complexapps with assive state trees	Design system, micro-frontends, performance-critical UI

Lit is generally faster in raw benchmarks because it avoids the "diffing tax." It doesn't have to spend CPU cycles comparing two large JavaScript objects to find out what changed. React excels at developer ergonomics.

The gist of this is that while Lit performs better than React, React is familiar to devs and has a large ecosystem. That’s why it’s more popular. Gemini is not hallucinating here either. I asked Gemini to simplify data from Krausest Benchmark where you can verify its findings. Lit was the clear winner.

Category	Lit	React (v19+)	Winner
Duration (Weighted Mean)	~1.05 – 1.15	~1.6 – 1.8	Lit
Startup / Boot Time	Fastest	Moderate	Lit
Swap 2 Rows	Excellent	Slow (VDOM Overhead)	Lit
Memory usage	Minimal	High (~10MB+)	Lit

Funny enough my personal preference for Lit has more to do with me wanting to remain as close to web standards as possible. The benefit of that is performance because what utilizes the platform will always win. At the same time though vanilla Web Components are cumbersome to write in my opinion. Hardly any one who writes web components does it vanilla. Lit is a leader here so I stuck with it.

If you’re new to Lit you can check out my beginner level video on YouTube that shows you how to create a dark mode in it.

Moving on.

The VDOM Paradigm is on its way out

React relies on a VDOM and the VDOM is slow compared to the platform. That’s why Lit scores so well. But outside of that, the VDOM gets in the way in other cases as well. Mostly it gets in the way of the mental model many developers have about the code they write. The VDOM has 3 main reasons why it’s a problem that even React acknowledges:

Re-rendering
Bundle Size Bloat
Memory Usage

React deals with the entire dom tree, virtualizes it, does a diff then renders components that change. Bad React code can easily slow down an app fast as this process creates a lot of rendering overhead. Anyone who’s spent a good time with React professionally knows re-renders can become a pain. On top of that, React has to download the entire diff engine just to render one button. And this download is not cheap. It can be 30KB+. That's a considerable size bloat. Finally the VDOM keeps a copy of your UI in memory at all times, leading to considerable memory usage for larger applications.

React’s way of trying to solve these problems is the React compiler. But in my opinion that’s more like a band-aid because it still relies on the VDOM. The real solution is to avoid using the VDOM all together. It was good for its time but the web has evolved.

Enter Signals

Signals is the new kid on the block and is the real solution for these issues. A signal is a kind of graph that creates a direct link between a piece of data and piece of text on the screen. When the data changes so does the UI and without all the VDOM overhead. Many JavaScript libraries are beginning to adopt Signals or are entirely based on it, like SolidJS.

I’ll admit, when I first heard of SolidJS I went “oh great, yet another JavaScript library.” I never built anything in it but I did test integrating Web Components for some design systems with it. My experience was good. Later on I found out that you can actually create Web Components in SolidJS. This got my attention. I became more curious about Signals, something SolidJS implements, because of this. Turns out Signals are legit, so much so that there is a proposal to make Signals standard JavaScript.

So I definitely have an eye on SolidJS and I’ll be exploring it more in the future.

Whaaat, Signals in Lit?!

Did you know that you can use a signal in Lit now? That’s right, we can thank Lit Labs for this. Lit Labs is a collection of experimental tech that works with Lit. It’s experimental now, so you probably want to avoid using this to build a production app. But as the proposal for signals becomes standard expect this to grow with it.

Let's take a look at some code.

import { LitElement, html } from 'lit';
import { customElement } from 'lit/decorators.js';
import { signal, watch, SignalWatcher } from '@lit-labs/signals';

// definte a variable as a signal outside your class
const count = signal(0);

@customElement('my-element')
export class MyElement extends SignalWatcher(LitElement) { // use the SignalWatcher mixin
  render() {
    // use the watch function to subscribe to updates
    return html`
      <button class="counter" @click=${this._onClick} part="button">
        Count is ${watch(count)} 
      </button>
    `
  }

  private _onClick() {
    // use the set method to update the signal
    count.set(count.get() + 1)
  }
}

I recreated the count functionality on Stackblitz with signals. All you really need to do is use the Mixin to construct your element. Then instead of using a property decorator, use the signal function to create a const that you’ll get and set later. That’s it. Lit plays well with Signals. Checkout the @lit-labs/signals package docs for more details.

I’m excited to see what may come of the Signals proposals and how this may evolve with it. Right now though if you are building microfrontends, design systems, or content driven apps with an Island Architecture, then going with Lit over React is a no brainer.

It’s time to get comfortable with web standards again

Hasani Rogers — Mon, 08 Sep 2025 17:44:05 +0000

Originally posted on my blog.

Typescript is ok though.

The point of this blog is to highlight some mentalities I’ve noticed amongst developers. Especially React developers. React has become so ubiquitous that a lot of developers do not know how to think outside its model for developing components. Sometimes, developers are also wholly dependent on its eco system as well. I saw the term “React Brain” used the other day and it made me chuckle.

This reminds me of the days when jQuery was king. jQuery was great for its time but it solved a problem browsers eventually caught up with. It took 10 something years but eventually people realized they didn’t need jQuery anymore. Not only that, jQuery was actually bloated and convoluted compared to standard JavaScript. Browsers could eventually do the things we relied on jQuery to do. Querying the dom became easy with querySelector. Fetching data with ajax was replaced by the Fetch API. The cross browser issues it solved for were mostly hammered out by fairly consistent browser standards.

Now let's look at React. React was released by Facebook (now Meta) in 2013. Its goal was to reduce UI complexity. It did this by introducing a declarative UI based component architecture. This was revolutionary at the time. Nowadays a declarative component based architecture is the standard amongst UI libraries. So much so that many developers make the mistake of thinking of Web Component as “another UI library” with “extra flavors they aren’t used to or need to learn”. They do this because to them, React is the standard and “other” component architectures are just “alternatives” to them like Angular or Svelte or something.

This thinking behind UI development is as mistaken as thinking of jQuery as the “standard”. jQuery may have felt like the standard, because it was so common, but the reality is that in its time it had “alternatives” too like Prototype and MooTools. They all fell to something superior, browser standards. React will eventually do the same. At least when it comes to component architecture. Let me highlight a practical example of how the component architecture of Web Components is simpler to work with than React.

I was working with Swiper JS to display some real estate properties. I had a pagination component control the main swiper container from children nested multiple levels deep. Typically in React if you want communication between components nested deep in a component you use something like context or some state management tool to avoid prop drilling. With web components, you don’t need any of this. All I had to do was use .closest to find the closest swiper-container in the dom within my web component. I was then able to access the swiper instance in my component and control the pagination by this alone. This is one of many examples of how web component APIs make things in the React world non issues inherently.

Another thing is styling. Web Components have a shadow dom and thus your styles are scoped to that shadow dom by default. You can write simple contextual styles without the need of utility libs like tailwind, styled components, or css modules, etc. You don’t even need any JavaScript to use a custom element. Just write the custom html tag, it's ok to make up your own html now. This approach automatically creates a scope (like a block in bem), for you to select your styles against. For example, write the tag <blog-header> and then select it with:

blog-header {
  /* your styles */
}

The beauty of a custom element is that it’s like selecting a low specificity ID that supports multiple instances. It’s unique but safe from specificity problems. This approach to styling is so revolutionary that I’ve created my own styling methodology around it called CEA.

Web Components should be thought of in the context of standard JS with progressive enhancements. You can use any JavaScript lib that supports standard JS with Web Components. This includes state management tools like Zustand or animation libs like Motion. You don’t need a web component version of any of these libraries because Web Components is standard JavaScript.

With Web Components there’s another intrinsic advantage. A return to focusing on describing the document semantically. Like my <blog-header> example, a well described accessible UI can use any html you make up along with HTML5 semantics. The browsers will treat your custom elements generically like a div. Consider this, you have a structure that looks like something like:

<main>
  <header>
    <blog-header>…content</blog-header>
  </header>
  <article>…content<article>
</main>

This improves DX because the semantics alone describes exactly what you mean. You don’t need to write wrapper classes for <blog-header>, the element is your wrapper. Better yet you don’t need to write a bunch of utility classes either. Classes have semantic meaning and were never intended to be magic strings for just styling.

Because a web component’s architecture is bound to a custom element, they are also perfect for content management systems like AEM or WordPress. In AEM, simply write the HTML of your custom element in your AEM component’s HTL. There is no need for more complex archetypes with slow and problematic webpack configurations that try to marry React and AEM components. In WordPress just write your custom element as HTML in your Gutenberg blocks or templates in PHP, or both.

Since Web Components don’t use a virtual dom they are often faster. Take Lit for example, a library that makes writing Web Components simple, when it renders it only renders changes in the dom directly. You don’t need to think about component trees and re-rendering issues with things like context in React.

Finally, you don’t even have to completely ditch React. You can use web components with React. Doing this is pretty simple these days now that React 19 and Next 15 finally added support for custom elements. I’m on a project at my day job where we used web components in a Next JS app to write some custom animations with motion. We did this so that our web components could be reused in a variety of tech stacks.

Almost every complaint I have ever seen about web components comes from the dev having the wrong mental model of web components because they think of them as if they were components in one of their frameworks or libraries. It's either that or framework makers themselves complaining because their framework deviates from using the DOM as a model for a component.

All the typical complaints like “web components aren't composable” or “doesn’t support rich data as property values” or “you have to use shadow dom” are false. They come from people who are inexperienced with working with web components. As loud as this voice is, it's wrong.

As far as framework makers goes, how many devs are actually trying to create their own framework? A framework will never trump standards implemented in a browser. Your job is to serve the browser because that's what end users actually interact with. Not your framework. Why fight this?

Web Components are a return to basics and web standards. You should be thinking of the document semantically again and enhancing it with custom elements. Write a web component when you need to have some behavior around a custom element. Style them appropriately with CEA. Web components bring a clear and standards based component architecture to the front end when working with content management systems with little tooling outside of JS Module support.

Libraries and Frameworks like Next/React are great with handling data driven applications. However I’ve found that Libraries like Lit offer simple approaches to building data driven UIs with web components as well, especially when combined with tools like Zustand and Astro.

Web Components and SSR with Next.js

Hasani Rogers — Fri, 09 Aug 2024 02:57:50 +0000

Originally posted on my blog.

I'm an advocate of Web Components because I believe presentational components should be written once and used through any tech stack. This has been a dream of mine for years. Web Components achieve this but not without caveats. I've written about using Web Components in libraries like React and Angular before. The most complicated caveat tends to be React but React 19 is adding native support for them. One thing I have yet to write about is how to handle Web Components in an SSR framework like Next.js. This is a tricky subject because SSR support for a Web Components are weak at the moment.

The Problem

SSR has html rendered server side. That html is then served to the browser. Web Components typically make use of a custom Shadow Dom that's initialized by JavaScript. This is a process that takes place on the client. How does the server then know how to render the Shadow Dom of a component? The short answer is that it can't. The long answer is that there is an emerging technology called Declarative Shadow Dom that solves the problem. DSD is in its early stages and support for it is buggy at best in a real application. Definitely not ready for use in production applications in my opinion.

So how do we reliably use Web Components in an SSR framework now in 2024 then? The answer to that is that you need to avoid trying to render the Shadow Dom of a component on the server and have the client do the work. This is totally achievable. I found examples of doing this lacking though, hence why I'm writing this blog. In this article I'll be detailing how I did this with Next.js, but the principals here can be used theoretically in any SSR framework.

The Main Idea

The main idea is that we need to generate a JavaScript bundle that will execute only on the client so that the Shadow Dom of an Web Component will be hydrated on the client. We don't want the server trying to do it. It's not that complicated as we dive into it more. We'll need:

A bundler that takes components and bundle them into a JavaScript file used in our build
A way to load that bundle as a standard script rather than with the rest of the JavaScript modules that get executed server side
This is optional but if you're using TypeScript you'll need a way to tell your app to recognize the custom Web Components in JSX.

Breaking it down in Next.js

I put together a repo that demonstrates how to achieve the three steps in Next.js.

The Bundler

My bundler of choice is Rollup.js. It's the thing that powers Vite and I think it's great. So in my repo you'll find the following rollup.config.mjs file in the app root here.

import resolve from "@rollup/plugin-node-resolve";
import multi from "@rollup/plugin-multi-entry";
import commonjs from "@rollup/plugin-commonjs";
import terser from "@rollup/plugin-terser";

// You'll need to create an object per library bundle
const config = [
  {
    input: ["src/app/bundles/shoelace.ts"],
    output: [
      {
        file: "public/shoelace/shoelace.bundle.js",
        name: "shoelace-bundle",
        format: "umd",
        sourcemap: true,
      },
    ],
    plugins: [resolve(), commonjs(), multi(), terser()],
  },
  {
    input: ["src/app/bundles/kemet.ts"],
    output: [
      {
        file: "public/kemet/kemet.bundle.js",
        name: "kemet-bundle",
        format: "umd",
        sourcemap: true,
      },
    ],
    plugins: [resolve(), commonjs(), multi(), terser()],
  },
];

export default config;

This file creates two bundles. One is for the popular Shoelace component library. The other is for my design system Kemet UI. The file is pretty simple and should be mostly self explanatory if you've worked with bundlers before. The most important thing here is that you place your bundle in the public directory so that it can be loaded as a static assets on the front end.

Loading the Script

The reason for creating the bundle is to include it as a script when the page is rendered on the client. SSR frameworks like Next.js should do a shallow render of the Web Component. This means that it'll render the Light Dom of the Web Component. This is enough for our bundle to find the light dom, execute, then hydrate it with its corresponding Shadow Dom.

In my Next.js repo I have a default layout file called default.tsx here. It looks like this.

import Script from "next/script";
import paths from "../shared/paths";
import "../shared/styles";
import "../styles/shared.scss";

export default function RootLayout({
  children,
}: Readonly<{
  children: React.ReactNode,
}>) {
  return (
    <>
      {children}
      <Script src={paths.shoelaceBundle} />
      <Script src={paths.kemetBundle} />
    </>
  );
}

Notice the <Script /> components. Their src prop is set to paths can be found in the paths.ts file. This path should match the output of the bundle file created in your bundler.

So as long as you're generating a bundle and calling it on the front end, you're good and your Web Components should work.

Supporting JSX in TypeScript

Great. We got Web Components to work in the browser. At this point you'll notice that your editor is probably complaining about the Web Components. This is because TypeScript doesn't know what the components are. Even if the library you're using ships with declarations for Typescript, since we're loading the bundle on the front end your editor has no access to this information. A not so ideal work around is to simply declare each web component to Typescript. In my repo I do this with declarations.d.ts.

declare namespace JSX {
  interface IntrinsicElements {
    "kemet-button": any;
  }
}

A Note on React 19

Before React 19 you needed a wrapper to get Web Components to fully work in React. This is no longer the case in React 19. My demo repo uses Next.js 15, which comes with React 19 but is in beta at the time of this writing. So the code there, specifically in layouts/default.tsx, is written in the style of React but doesn't use a wrapper. You'll probably want to use a stable version of Next.js. That unfortunately means you can't follow this code using a useState for the opened prop and handling events declaratively such as with onkemet-drawer-opened. On top of that wrappers don't work with SSR.

All is not lost though, to work with events and rich data with Web Components in Next.js you'll need to do it the classic way and get a ref to the Web Component. From there you can use addEventListener and assign objects/arrays/booleans directly to the component. You can find example of this in the legacy.tsx file

Final Thoughts

There's more to the repo but these points are what you really need to know for now. Feel free to reach out with questions! Personally I can't wait for the day we see an SSR Frameworks built on top of this for Web Components. But we're not quite there yet.

Lit and State Management with Zustand

Hasani Rogers — Mon, 08 Jul 2024 10:01:52 +0000

Originally posted on my blog.

I come across a lot of developers who think that web components are for trivial things like buttons and input components. The reality is that you can build an entire application with web components. One of the most important pieces to an application's UI is state management. There are a lot of state management tools out there, like redux and mobx, that work perfectly fine with web components. These tools are a bit cumbersome though and many developers prefer more simple solutions for more simple applications. Enter Zustand, a "bare necessities" state management tool that's making strides in the React world.

I was (sorta) recently introduced to Zustand on a React project I'm working on. I thought it was pretty neat. So naturally I was curious about how you would use it with an application built with Lit and web components. I new it was possible because the Zustand docs has a "Using Zustand without React" section. But I found absolutely no resources out there on how to accomplish using it with Lit. Thus I decided to experiment with an Stackblitz todo app. I had a lot of fun! Since I could find no resources out there I also decided this would be a good topic to blog about.

Getting the basics down

The first thing to know about using Zustand outside of React is that instead of hooks, which is a React thing, you'll be working with it's API utilities. These are:

getState
setState
subscribe
getInitialState

I found that getInitialState and subcribe was the most critical for working with Lit. I've put together a basic demo app illustrating how to work with Lit and Zustand.

This app only has one store and one Lit component. All it does is count bears and remove the count. I made this because I want to demonstrate the basic principals behind using Lit and Zustand. The most important thing to know in this app is lines 75-83 of my-element.ts, the constructor.

constructor() {
  super();

  // we need to subscribe to appStore state changes to rerender the UI when state has been updated
  appStore.subscribe((state, prevState) => {
    // update bears locally
    this.bears = state.bears;
  });
}

In the constructor you are going to want to listen to your store by subscribing to it. From there you want to update data in Lit based off state changes. In this example we update the bears count in Lit (this.bears) with the bears count in state (state.bears) on lines 81. We want to do this because as state changes we need to render a new UI by triggering an update.

The next thing to know is that we want to store the state of the store in a Lit property. In my case I've called this appState here and I've used getInitialState from Zustand API utilities to populate it. This way we can run methods in our store by simply referencing our appState like I've done with the handleAdd method.

handleAdd() {
  this.appState.increasePopulation();
}

Here, increasePopulation is a method in the store taken directly from Zustand docs. As for the Store itself, we don't need to do anything special for Lit here. Set this up as you would setup Zustand in an vanilla JavaScript app according to the Zustand docs.

Everything else in this app should be self explanatory if you know Lit.

The Todo App

My todo app takes the principals I've outlined above and extend upon them a bit. In this app we're using the subscribe and appState pattenrs I've shown you. And example of the appState can be found in todo-app.ts on lines 59-60.

@property()
todoState: ITodoStore = todoStore.getInitialState();

Here we call it todoState. In the constructor you'll also see our subscribe.

constructor() {
  super();
  todoStore.subscribe((state) => {
    this.numberOfItems = state.todoList.length;
  });
}

In this app though we're keeping track of the number of todo items by getting the length of todoList.

Adding a todo

The responsibility of adding todos is handled by the todo-input component. This component makes use of the addTodo method in the store to add a todo. In our app a todo is represented by an object that has two properties, value and checked. They're self explanatory. To add the todo we turn to our store. The code looks like:

addTodo: (newTodo) => set(state => ({ todoList: [...state.todoList, newTodo] })),

On line 20 of store/todo.ts. Adding the todo is mostly standard Zustand stuff. We use set, which gives us state and we then return the new state of todoList by spreading in the current state + newTodo.

Updating State

Where things get interesting is handling how to update state. An example of updating state is updating the checked state of a todo. I've opted to use lodash for this. So lets look at the todoToggle method on line 26 to understand how to achieve this:

todoToggle: (index) => set((state) => lodashSet(state, `todoList[${index}].checked`, !state.todoList[index].checked)),

Once again we're using set. But this time we also have lodashSet which takes an object, a path to thing you want to set, and a value. In our case we give state, a path to the checked property, and value to be the opposite of the last checked state for a toggle effect. We then return the new state object.

But there's a catch, we've updated state and Lit doesn't know about it. The state has been updated but when we do this we need to tell Lit to update the UI because the state is different. You can do that by using requestUpdate. Turn to lines 87-90 in todo-list.ts.

handleChecked(index: number) {
  this.todoState.todoToggle(index);
  this.requestUpdate();
}

When we call todoToggle we also need to request an update in Lit to re-render the UI. The same is true for removeTodo which uses lodash's pullAt to remove a todo in the todoList array.

That's about it folks. I hope you build something more cool than my Todo app with Lit and Zustand. Here's the Todo app for reference:

The new BEM for Custom Elements, CEA

Hasani Rogers — Fri, 09 Sep 2022 11:57:28 +0000

Originally posted on my blog.

Web Components have been around for a while. But with the plethora of tech out there, like React and Angular, the average developer simply doesn't have that much experience with them. So best practices and methodologies are lacking. We definitely need some formal approaches to developing with Web Components. They are designed to work together with, and not replace, Front End libraries. Developers need more exposure to web components and custom elements in general.

The thing I've notice that developers struggle with the most when being introduced to Web Components is the concept of the Shadow Dom. Developers are used to tools that fake what a Shadow Down does naturally. You find this in all sorts of technology. Take styling in React for example. React has something called CSS Modules which allows you to scope CSS to a component. It's cool but the issue it solves for is a non-issue in the Web Component world. Constructed style sheets are inherently scoped. Then there is SCSS. SCSS is nice but it assumes the perspective of working in one massive light DOM tree. The "light DOM" is the regular DOM that developers are used to. SCSS is based on this. Think of nesting selectors for example. You create a kind of "scope" by putting once selector as a child of another. This was incredibly popular and useful when BEM emerged.

If you've been living under a rock BEM is an acronym for Block, Element, Modifier. Developed by Yandex almost a decade ago, BEM is a naming convention that "componenitizes" styles (yes I just made the word componentizes). BEM was brilliant. But like SCSS it assumed one light DOM. In the world of the light DOM BEM and SCSS makes sense. But in the Web Component world we have native encapsulation. Naming conventions like BEM aren't nearly as useful and it takes developers a while to understand this. Hell it took me a while. Just two years ago when I wrote the drawer component for my UI Library I still used BEM. But over time I started to learn my own methodology that makes more sense for Web Components. Well today I'm here to name that methodology and formalize it in writing so that others may have the same insight as me!

CEA is my BEM replacement for Custom Elements.

CEA is an acronym for Component, Element, Attribute. It sorta has a correspondence with BEM but with one major difference. Use attributes to style the state of a component. This is huge because we're so used to styling with classes that a lot of us don't know how to think outside the box on this one. However the primary thing I've noticed is that your component will usually have some kind of state, represented by a property, which can be reflected as an attribute. Your style "modifiers" thus correspond to this state that you access via attributes. I'll demonstrate this more clearly in a second. For now, let me define some terms.

Component: This is your main scope. Think of it as Block in BEM. Instead of a establishing a class name for a block, you simply select by host element or custom element name however.

Element: This is any element that lives in the Shadow Dom of your component or a child of your component. You may select by class name if you wish. You'll often find that literally selecting the element works just as well however.

Atrribute: These are attributes on your host component. They represent a state of the component such as disabled on a button or opened on a dialog.

Of course this can all be illustrated better by example, so lets dive into it. FYI the following example is going to use Google Lit which I highly recommend if you're writing web components.

Learn by example

Let say you're working on a button. Your button has two styles to it. Standard and outlined. Now you could write a modifier class for the outline version of the button based on an outlined property like this.

  static get styles() {
    return [
      css`
        .button {
          ...
        }

        .button--outlined {
          ...
        }
      `
    ]
  }
  render() {
    return html`
      <a href=${this.link} class="button ${this.outlined ? 'button--outlined' : ''}" role="button">
        <slot></slot>
      </a>
    `;
  }

Or, you could simplify the code under CEA and style the outlined attribute directly.

  static get styles() {
    return [
      css`
        a {
          ...
        }

        :host([outlined]) a {
          ...
        }
      `
    ]
  }
  render() {
    return html`
      <a href=${this.link} role="button">
        <slot></slot>
      </a>
    `;
  }

Notice that in CEA we take advantage of the :host selector. We also don't really need a class for the button. We can simply select it by the element as we're not going to have more than one a in the component. The result is that the markup in our template is much cleaner and easier to read and maintain. In my opinion the styles become easier to read too. That's the primary of benefit of CEA.

Reflecting Attributes with Lit

Lit has a nice feature that allows you to reflect the value of property as an attribute on your host component. CEA becomes very useful when engaging in this practice. Instead of the user of the component controlling for an attribute like opened you can have Lit automatically apply the attribute when something opens or closes. Let's take a modal for example. The following modal will close when the user clicks outside of the modal. To close the modal we control the opened property by setting it to false. This will automatically remove the opened attribute from the custom element.

export default class ExampleModal extends LitElement {
  static get styles() {
    return [
      css`
        *,
        *::before,
        *::after {
          box-sizing: border-box;
        }

        :host {
          position: fixed;
          display: flex;
          top: 0;
          left: 0;
          z-index: 99;
          width: 100%;
          height: 100vh;
          visibility: hidden;
          backface-visibility: hidden;
        }

        /* in CEA we style for attributes on the host element as they correspond to "state"
        :host([opened]) {
          visibility: visible;
        }

        /* .content and .overlay elements where given class names because they are both 
         * divs and we need to distinguish between them
         */ 
        .content {
          position: relative;
          z-index: 3;
          margin: auto;
        }

        :host([mobile]) .content {
          padding: 1rem;
        }

        .overlay {
          position: fixed;
          width: 100%;
          height: 100%;
          visibility: hidden;
          top: 0;
          left: 0;
          z-index: 1;
          opacity: 0;
          background: rgba(0,0,0,0.2);
          transition: all 0.3s;
        }

        :host([opened]) .overlay {
          opacity: 1;
          visibility: visible;
        }
      `
    ];
  }

  static get properties() {
    return {
      opened: {
        type: Boolean,
        // set reflect to true so you may style the attribute
        reflect: true, 
      },
      breakpoint: {
        type: String,
      },
      mobile: {
        type: Boolean,
        reflect: true,
      },
    };
  }

  constructor() {
    super();
    this.opened = false;
    this.breakpoint = '600px';
  }

  firstUpdated() {
    this.addEventListener('click', (event) => {
      if (this.opened && event.target.tagName.toLowerCase() === 'example-modal') {
        // this will automatically remove the opened attribute from the host element 
        this.opened = false;
      }
    });

    window.addEventListener('resize', () => {
      this.isMobile();
    });
  }

  updated(prevProps) {
    if (!prevProps.get('opened') && this.opened === true) {
      // Fires when the modal opens
      this.dispatchEvent(
        new CustomEvent('example-modal-opened', {
          bubbles: true,
          composed: true,
          detail: this,
        }),
      );
    }

    if (prevProps.get('opened') && this.opened === false) {
      // Fires when the modal closes
      this.dispatchEvent(
        new CustomEvent('example-modal-closed', {
          bubbles: true,
          composed: true,
          detail: this,
        }),
      );
    }

    this.isMobile();
  }

  render() {
    return html`
      <div class="content">
        <slot></slot>
      </div>
      <div class="overlay"></div>
    `;
  }

  isMobile() {
    /* 
     * here we represent mobile as state. this way users can easily 
     * control the breakpoint where the modal is considered to be mobile 
     */
    const mediaQuery = window.matchMedia(`(max-width: ${this.breakpoint})`);
    this.mobile = mediaQuery.matches;
  }
}

On line 89 we manually close the modal by setting opened to false. With CEA, instead of writing logic to toggle classes, we simply write a selector for the opened attribute. Since it's a boolean if opened is not on the component it's automatically considered closed.

You can write CEA without Web Components

CEA works even when you're not writing formal Web Components with a Shadow Dom. It works with custom elements in general. The most groundbreaking thing about this is thinking in terms of Custom Elements. Custom Elements is a standard browser API, so they work with Vanilla JavaScript and even React. Unlike when BEM was created, we now have the ability to make up our own HTML and attributes. All modern browser support autonomous custom elements. So CEA still applies, you'll just need to write more JavaScript for your components. Here's an example Pen that I wrote using CEA in Vanilla JavaScript.

You'll see that the methodology is the same while working with Vanilla components. The code is just a little bit more complex. Instead of using the host selector we style our custom element directly. That is the Component part of CEA. We then style our children under the scope of the component element, that is the Element part of CEA. Finally we write JavaScript to manually handle the status (opened/closed) of the component as an attribute, that is the attribute part of CEA. It's super straight forward when you get pass a class being the primary way you style something. You can even use CEA in React if you wanted too, although you'd have to manually handle the attributes like with Vanilla components.

If you're working with React, the CEA methodology is the same. You'll simply need to use custom elements and attributes. The syntax for toggling an boolean attribute is a little weird. But it works. Here's an example.

Notice how the attribute corresponds to state.

I'm gonna end this article with a note. CEA is pronounced (See - ah). It's actually wordplay for the Egyptian god Sia. I thought it was fitting because Sia is the deification of perception which thinking in CEA takes a shift in perception. Ha!

The MEWN Stack with Shoelace

Hasani Rogers — Sat, 30 Jul 2022 14:24:00 +0000

Originally posted on my blog.

I'm surprised. Before writing this article I googled "MEWN stack" and got zero relevant results. I mean I know someone out there has probably create something on a MEWN stack but nobody is using the term? Funny. Anyways, first there was MEAN who's primary front end technology was Angular. Then MERN came around once React got popular. Now there's MEWN with web components. I'll let the internet decide how to pronounce it. Now on on the meat.

I recently was asked to do a simple landing page generator app. The app will be used for users who will scan a QR code and get taken to a page with audio or video that plays. The client needs to manage the landing pages via a dashboard. Since I'm a Front End Developer with a lot of experience in WordPress I tend to go to WordPress when I need server side tech. WordPress was overkill for this project though. Each landing page only need a small amount of info. I do have experience with Express.js and MongoDB though. So I said screw it, I'm gonna build an app with Express, MongoDB, Web Components, and Node.

You can find a work in progress repo for the entire app at my Github. However since the client needs exclusive access to it to manage the pages I won't be posting a link to the live app. Instead in this article I'll review concepts with examples of how to execute the code. Read on to learn how to:

Roll out an generated Express app
Configure Express to connect to a remote MongoBD on Atlas
Setup a database model with Mongoose
Add server side routes
Use EJS templating to render the server side page
Review various web components that make up the front end
Setup a front end build chain with Rollup

Roll out an generated Express app

Generating an Express.js app is easy. Just run npx express-generator --view=ejs. EJS is the name of the view engine we're gonna use to render pages. More on that later. After you run the generator do a npm install. You'll then be able to start the app with npm start. But we want to take things a little further. Lets install something called Nodemon with npm i -D nodemon. Nodemon will watch for changes in our Express and reload the app when we make a change to it. After you've installed Nodemon replace node in the start script with nodemon. Your script should look like:

...
"scripts": {
  "start": "nodemon ./bin/www"
},
...

Run npm start again and this time you'll start with an auto refreshing server.

At this point you'll have these files and directories:

bin/www - Starts the server
public/ - Serves up static assets for the front end
routes/ - Backend routes
view/ - Templates for the front end
app.js - The main server config file

This is a standard Express.js install. Most of this stuff you can leave intact unless other wise noted.

Configure Express to connect to a remote MongoBD on Atlas

Instead of setting up MongoDB ourselves, we're gonna to defer to a service called Atlas. Our application is simple so we can use the free account. Once you create an account select a project and look off to the left sidebar. You should see a link named "Databases". Click on it and it should take you to an "Overview" tab. While on the Overview tab there should be button with the label "Connect". Click on it and you'll get a modal. Next click on the option that says "Connect your application." You should see a script that looks something like:

const { MongoClient, ServerApiVersion } = require('mongodb');
const uri = "mongodb+srv://<username>:<password>@cluster0.glgp5.mongodb.net/<database-name>?retryWrites=true&w=majority";
const client = new MongoClient(uri, { useNewUrlParser: true, useUnifiedTopology: true, serverApi: ServerApiVersion.v1 });
client.connect(err => {
  const collection = client.db("test").collection("devices");
  // perform actions on the collection object
  client.close();
});

In the root of your project create a file called .env. Copy the value of the const uri and paste it inside .env. Prefix the value with DB_DSN=. Your .env file should look like:

DSN_DB=mongodb+srv://your_username:your_password@cluster0.glgp5.mongodb.net/your_database_name?retryWrites=true&w=majority

Replace the strings that begin with your_ with your actual username, password, and database name.

We're putting our authentication to the database in an .env for security reasons. Node.js has a library called dotenv that will read this file and create environment variables from them. This is what we want so install dotenv with npm i -D dotenv. Open up bin/www and place this line of code on line 2, require('dotenv').config();. We should now be able to access this in Express with process.env.DB_DSN.

Create a file in the root of the project named database.js place this in it:

const mongoose = require('mongoose');

module.exports.connect = async dsn => mongoose.connect(dsn, {useNewUrlParser: true});

Since we'll be using something called Mongoose to interface with our Database, go ahead an install it with npm i mongoose. This script setups mongoose to connect to our database. Next open up www/bin again and add the following:

var db = require('../database');
...
db.connect(process.env.DB_DSN)
  .then(() => {
    console.log('connected');
    server.listen(port);
  })
  .catch((error) => {
    console.error(error);
  });

This makes the actual connection to our Database using the DB_DSN credentials we've provided.

Setup a database model with Mongoose

Now that we have a connection to our database we need to setup a model for how data will be entered into the database. We do this using Schemas with Mongoose. Create a file directory named models and place a file called page.js in it. Inside page.js add the following:

const mongoose = require('mongoose');
const AutoIncrement = require('mongoose-sequence')(mongoose);
const emailValidator = require('email-validator');

const PageSchema = mongoose.Schema({
  firstName: {
    type: String,
    required: true,
    trim: true,
    minlength: 2
  },
  lastName: {
    type: String,
    required: true,
    trim: true,
    minlength: 2
  },
  email: {
    type: String,
    required: false,
    trim: true,
    lowercase: true,
    index: { unique: false },
    validate: {
      validator: (email) => {
        return emailValidator.validate(email) || email === '';
      },
      message: props => `${props.value} is not a valid email address`
    }
  },
  mediaType: {
    type: String,
    required: true,
    trim: true
  },
  mediaURL: {
    type: String,
    required: true,
    trim: true,
    minlength: 2,
  },
  message: {
    type: String,
  },
  websiteLink: {
    type: String,
  },
  websiteLinkLabel: {
    type: String,
  }
}, {
  timestamps: true,
});

PageSchema.plugin(AutoIncrement, {inc_field: 'id'});

module.exports = mongoose.model('Pages', PageSchema);

We're using two packages to assist Mongoose here so lets install them. Run npm i mongoose-sequence email-validator.

Mongoose Sequence allows us to auto increment a database field. We want to do that with the id because we want a unique id auto generated every time a record is created. The code for this can be found on line 55. We take our schema object and run the plugin on it. Use the property inc_field in the object as options. The value of inc_field should be the name of the field you want to auto increment. In our case that's id.

The other package we're using is Email Validator. This allows us to have the server reject emails that don't match valid email validation. In our app emails are actually optional. So you'll see in the code that the email can return either a valid email or an empty string. Checkout line 24 in the code. Mongoose allows us to setup custom validators on any field. To do so use the validate property. The validate property should be an object with two properties, validator and message. Validator is a function that returns a boolean. It also passes the data used in the field as an arg. This way we can use EmailValidator to run validation on what the user entered. Since its optional we can also return true if the email is an empty string.

The rest of the properties for the fields controls predefined rules such as should white space to be trimmed or the minimum length of the data that was inputted. You can find more about all the options you have in mongoose's schema types documentation.

Add server side routes

With our model in place we need to add a way to actually send data to the database. We also need to display that data back to the user. We do this with routes. Routes allows us to handle both POST and GET on the server. When the user has submitted data we want to handle it as a post request and save that data through our model. When a user wants to see data (view a page), we handle it as a GET request.

We need plenty of routes for our app.

/create - handles creating a new page
/dashboard - displays all the pages that have been created
/delete - deletes the specified page
/edit - edits the specified page
/page - view the specified page

I'm not going to go over all the code in the routes here. After all you can checkout it out on at my repo. What I do want to cover though is the basic concept of handling POST and GET requests.

Handling POST

A POST request happens when the front end makes submits a form. Typically an AJAX call through fetch, axios, or maybe even jQuery is made. In Express, the data sent in this call is accessible through the request body parameter. So to handle a post request you need to use the post method of router and do something with the data by accessing request.body. In our create route for example first we import router:

const router = express.Router();

Then we use post.

router.post('/', async (request, response, next) => {
  try {
    const page = new PageModel({
      firstName: request.body.firstName,
      lastName: request.body.lastName,
      email: request.body.email,
      mediaType: request.body.mediaType,
      mediaURL: request.body.mediaURL,
      message: request.body.message,
      websiteLink: request.body.websiteLink,
      websiteLinkLabel: request.body.websiteLinkLabel,
    });

    const savedPage = await page.save();

    if (savedPage) {
      return response.status(200).json({ message: 'SUCCESS', code: 200 });
    } else {
      return response.status(500).json({ message: 'ERROR', code: 500 });
    }
  } catch (error) {
    const responseData = {
      message: 'ERROR',
      code: 500,
      body: error
    };

    return response.status(500).json(responseData);
  }
});

One line 3 we create a PageModel with Mongoose. That model is an object that represents all the data we've collected from the form. Mongoose takes that data and stores it in the database so as long as it passes validation and saves correctly. Speaking of saving, notice how we have conditional logic on line 16 that handles the save. IF the save fails we need to return an error the front end can handle. We also have it in a try/catch block. If for some reason something goes wrong with the process of saving to the database we catch that error and give it to the front end.

Handling GET

Get requests require us to send a page when the user access a particular url in a browser. To do this we render a template. That template can receive data from the server to display dynamic information such as a user name. For example:

router.get('/:pageId', async (request, response, next) => {
  const page = await PageModel.find({ id: request.params.pageId });
  const templateInfo = {
    title: 'Error',
    bodyClass: `body--error`
  };

  if (page.length > 0) {
    const mediaType = page[0].mediaType;

    templateInfo.title = `${page[0].firstName}'s ${mediaType}`;
    templateInfo.page = page[0];
    templateInfo.bodyClass = 'body--landing';

    response.render('page', templateInfo);
  } else {
    response.render('error', templateInfo);
  }
});

This is the code used to gender the unique landing page in our app. Notice on line 1 we have /:pageId as a parameter of get. This allows us to collect information from the url that was entered. In our case /page/99 would mean that the pageId is 99. You can access this page id via request params or request.params.pageId. On line 2 we grab information specific to the page that was requested via pageId. We then use that information later on to generate a unique landing page. On line 15 we actually render our page. The page comes with templateInfo or an object that contains information from the page that was returned. If the page is not found we default to an error page.

Configure the routes in app.js

You may have notice that there is no /page given as an argument for get in the code above. That's because the path to our routes is actually configured in app.js.

On line 28 of app.js we have:

app.use('/page', pageRouter);

...and pageRouter is an import of our router in routes/page.js; This allows us to only have to specify the route param when writing the logic of our page router.

Use EJS templating to render the server side page

With our routes in place we now need to render a page when users want to view some data from the server. In the beginning of this article I had you generate an express app using the switch --view=ejs. EJS is the name of the templating engine we're going to use to render pages. In a EJS file we have access to all the info we stored in our templateInfo object. We have many views but I'm going to be covering dashboard.ejs. You can take the concepts here and run with them.

The dashboard needs to:

Include the header and footer
Loop through all the pages and display links and actions associated with them.
Handle pagination.

Be sure to checkout the route that renders dashboard.ejs to get clarity on where all this data comes from.

Our header and footer is in a partial that's a separate file. So we need to use include to embed them in our view.

<%- include('partials/head.ejs', { title: title, bodyClass: bodyClass }) %>
...
<%- include('partials/footer.ejs', { title: title }) %>

The first argument is the location of the partial. The second is an object containing data for the template. We don't really need to pass the title down to the footer. I was probably in a rush when I did that.

Next we need to loop through all of our pages. Our dashboard route sends down an array of objects named pageData. This page data is aware of pagination rules so we can just loop through what's sent from the server.

<ul class="pages">
  <% for (var i = 0; i < pages.length; i++) { %>
    <li>/* actions concerning the page go here */</li>
  <% } %>
</ul>

It's a simple for loop to achieve this. We loop through the pages variable which is found in the dashboard's templateInfo object. Every property on this object will be available to us as a variable here.

Finally we need the pagination. In this app I've created a pagination web component. The pagination web component has a number of properties most of which are straight forward to figure out. We do want to build some logic in our template though. For example, we only want to display the pagination component if the pages are actually paginated.

<% if (pagination.currentPage && pagination.limit) { %>
  // pagination component goes here
<% } %>

We can do this by checking the currentPage and limit properties of pagination object. Limit is something we use to tell mongoose to limit the number of records to fetch from the database. If these properties aren't truthy then we don't have any pagination. We also need to provide values to our pagination component's properties and even conditionally add some properties such as last. Last shouldn't display if the user is on the last page because it's unnecessary at that point.

<indelible-pagination
  link="/dashboard?page=[[current]]&limit=<%= pagination.limit %>"
  link-previous="/dashboard?page=[[previous]]&limit=<%= pagination.limit %>"
  link-next="/dashboard?page=[[next]]&limit=<%= pagination.limit %>"
  link-first="/dashboard?page=[[first]]&limit=<%= pagination.limit %>"
  link-last="/dashboard?page=[[last]]&limit=<%= pagination.limit %>"
  total="<%= pagination.totalPages %>"
  current="<%= pagination.currentPage %>"
  <% if (pagination.previousPage) { %> previous="<%= pagination.previousPage %>"<% } else { %> previous="disabled" <% } %>
  <% if (pagination.nextPage) { %> next="<%= pagination.nextPage %>"<% } else { %> next="disabled" <% } %>
  <% if (pagination.currentPage !== 1) { %> first="1" <% } %>
  <% if (pagination.currentPage !== pagination.totalPages) { %> last="<%= pagination.totalPages %>" <% } %>
>
</indelible-pagination>

If you're interested to know how the pagination component was written you can checkout its code here. It's basically a bunch of dynamically generated links.

Review various web components that make up the front end

This app uses various components from Shoelace and custom components written by me. You can find all the custom component here. I'm going to discuss the delete component because it also contains Shoelace components. The delete component is a form that sends a POST request to our delete route. When the users initially click the delete button we don't immediately send the request. Instead we pop open a dialog asking them to confirm the deletion. This is where Shoelace comes in. Shoelace has a dialog component that we're using inside of delete.

<sl-dialog label="Delete this page?">
  Are you sure you want to delete this page?
  <sl-button slot="footer" variant="primary" type="submit">Yes</sl-button>
</sl-dialog>

We have a method on our delete component that will handle what happens when delete is clicked.

handleClick() {
  const dialog = this.shadowRoot.querySelector('sl-dialog');
  dialog.show();
}

When the delete button is click, we just need to call show() on the dialog element. You'll notice that the button in our sl-dialog and has a type of submit. This means that it'll work like a submit button for a form. The real deletion happens when we submit the form with the sl-button. On the form we have a submit handler.

<form action="/delete" @submit=${(event) => this.submitForm(event)}>
  <!-- form -->
</form>

The submitForm() method needs to do a POST request to /delete.

submitForm(event) {
    event.preventDefault();

    const form = this.shadowRoot.querySelector('form');
    const formData = new FormData(form);

    const config = {
      method: 'POST',
      body: JSON.stringify(Object.fromEntries(formData)),
      headers: {
        "Content-Type": "application/json"
      }
    };

    fetch(form.action, config)
      .then(response => response.text())
      .then(text => {
        try {
          const response = JSON.parse(text);

          if (response.code == 200) {
            window.location.reload();
          } else {
            alert('There was a problem deleting the page.');
          }
        } catch (error) {
          console.error(error);
        }
      })
      .catch(error => {
        console.error(error);
      });
  }
}

We use the formData API to get data from the form. In this case the only thing we need to collect is the pageID of the page that needs to be deleted. The user doesn't need actually enter the pageID since our template knows it. So we use a hidden form field to collect the data. If the deletion is successful we reload the page. If not we pop up an alert explaining to the user that there was a problem. Btw we're sending the data as JSON so be sure to set the headers to application/json as shown in the snippet above.

Setup a front end build chain with Rollup

The last thing we need to cover for building a MEWN stack application is bundling front end assets. These days I prefer Rollup for this. Install Rollup with npm i -D rollup. We also want to install a couple of Rollup plugins.

npm i -D @rollup/plugin-commonjs @rollup/plugin-node-resolve rollup-plugin-copy rollup-plugin-scss

We have an npm script named build that runs the rollup command with a config file flag.

"scripts": {
  "build": "rollup -c",
}

The -c in the command means use a config file. You can specify where this config file lives but the default location Rollup will look for is a file in the root of the project named rollup.config.js. We're using the default.

Our Rollup config file looks like this:

import path from 'path';
import resolve from '@rollup/plugin-node-resolve';
import commonjs from '@rollup/plugin-commonjs';
import copy from 'rollup-plugin-copy';
import scss from 'rollup-plugin-scss';

export default {
  input: 'src/javascript/index.js',
  output: {
    file: 'public/bundle.js',
    format: 'es'
  },
  plugins: [
    resolve(),
    commonjs(),
    scss({
      output: 'public/bundle.css',
      sass: require('sass'),
    }),
    copy({
      targets: [
        {
          src: path.resolve(__dirname, 'node_modules/@shoelace-style/shoelace/dist/assets'),
          dest: path.resolve(__dirname, 'public/vendors/shoelace')
        },
        {
          src: path.resolve(__dirname, 'src/assets'),
          dest: path.resolve(__dirname, 'public')
        }
      ]
    })
  ]
};

The starting point for our bundle output is src/javascript/index.js. This is a file that contains a bunch of imports including our custom web components and Shoelace components. Rollup is going to take all the files here bundle them to a file called public/bundle.js. Our application then loads the bundle file.

We're also using the scss plugin. This means that Rollup is going to handle any .scss files we import in index.js. We've configured the plugin to output a complied scss file to a css file called public/bundle.css. Like the JS we load this CSS file on the front end of the application.

Some Shoelace components such as sl-icon has assets associated with them. We need to copy those assets from the node_modules directory to a directory in our app so that we can load them. I've chosen to copy them to public/vendors/shoelace. We also use the copy plugin to copy everything in src/assets to public since public is our static assets directory. Think of it as a build directory. We don't version it.

And that sums up the MEWN stack application folks. I know I didn't cover all the code but I've provided plenty of links to my repo with the application. I hope I've demonstrated that working with web components in an Node/Express/Mongo context is really straight forward. I hope to see the term MEWN catch on one day!