Forem: Charles Loder

Environment Variables: a very short intro for JS development

Charles Loder — Fri, 06 Sep 2024 01:04:34 +0000

This article is intended to be a short invesitgation into environment variables for myself, hence the terse style

The basics

The terminal is an app that is really a terminal emulator
We use the terminal interact with the shell
The shell can spawn processes, such as a Javascript program by means of another app, like node
- e.g. shell -> node -> index.js
When we open terminal a new session is created in the shell
This session has variables that can be associated with it (e.g. echo $USER prints the name of the current user)

node

In node, environment variables are accessed via the global process.env



console.log(process.env.USER); // username

Applications typically access secrets or configuration related data via environment variables
- e.g. process.env.DB_CONNECTION
- This is helpful because we want to keep secrets secret, and not every user will have the same configuration needs — this allows for better decoupling of logic and configuration

methods for loading variables

There are a few ways we can make these variables available to our programs.

(1) making them available via the command line:

Pretty straightforward — just call the command with the variable in the command line.



DB_CONNECTION="postgresql://username:password@host:port/database_name" node index.js

(2) storing them in an `.env` file

.env files consist of KEYS and VALUES which are separated by an equals sign.



DB_CONNECTION="postgresql://username:password@host:port/database_name"

These files are commmon, and there are a few ways to make them available to your application.

direnv

Use a tool like direnv which loads variables from a file makes them available in the shell; it is this is typically installed globally.

By default direnv looks for a .envrc file, but it can use .env as well, see here for configuring it to do so.

dotenv

Use a tool like dotenv which loads variables from a file and makes them available in process.env.

direnv vs dotenv

There are pros and cons for each method.

Using direnv is language agnostic and means one less dependency, but it also means that consumers of your application need their own way to load environment variables if not using direnv;

Using dotenv ensures that consumers of the application can just use a .env file with no worries, but it does add a package just to do something the shell can do natively.

node flag

Node recently included support (v20.6.0) for using .env files directly.

A flag has to be used



node --env-file=.env index.js

Like dotenv, this makes the content of .env available in process.env.

Summary

environment variables are technology native to the shell
there are a few different ways to load them — directly, direnv, dotenv, node
direnv loads variables into your shell, but dotenv and node only make them available to your application via process.env
if using node, you should probably opt to use the new --env-file flag

Personal site inspiration ✨

Charles Loder — Wed, 07 Aug 2024 20:13:54 +0000

I'm looking for inspiration to create a personal site!

I want to create something that matches my taste and style.

My background is in humanities, but I work in tech. I want some serif fonts, simple lines, and some good spacing.

Throw any suggestions in the comments!

Modern CSS hamburger using :has()

Charles Loder — Mon, 22 Jul 2024 20:27:15 +0000

I know, I know...yet another CSS hamburger tutorial. There's already hundreds out on the internet to copy-and-paste. Why bother with another one?

Besides the basest reason — I want to do it myself, this tutorial is a little different in that it uses the new :has() selector, which allows us to implement a type of "controller pattern" for our CSS.

Jump to the finished product below to see the Codepen demo.

The problem with most hamburgers

Perusing through the various hamburger menu tutorials online, I tend to see a few problems (or rather, things I just don't like):

They rely on Javascript. That isn't the worst (I love JS), but we can handle this logic using just CSS.
They weirdly nest things. Depending on how the HTML is structured, the actual menu can be nested under the hamburger itself. It's just hard to reason about
They are tightly coupled. Complex CSS selectors often mean that the functionality is tightly coupled to the structure of the HTML. While there has to be some coupling, I think there is a better way

Using `:has()` to create a controller.

Honestly, this image pretty much says it all:

In short, the header is a controller. When the state of the .hamburger changes, the state of the .menu is updated.

But let's go through all the main parts to get a better sense of what's happening.

The hamburger

The hamburger HTML is pretty straightforward:



<div class="hamburger">
  <input type="checkbox" id="toggle">
  <label for="toggle" class="icon">
    <span class="bg-white"></span>
    <span class="bg-white"></span>
  </label>
</div>

The CSS is a little more, but still not complicated:



.hamburger {
  height: 32px;
  width: 32px;

  input[type="checkbox"] {
    display: none;
  }

  .icon {
    width: 100%;
    height: 100%;
    display: block;
    position: relative;
    cursor: pointer;
  }

  .icon span {
    display: block;
    position: absolute;
    height: 3px;
    width: 100%;
    border-radius: 3px;
    opacity: 1;
    left: 0;
    transform: rotate(0deg);
    transition: 300ms ease-in-out;
  }

  .icon span:nth-child(1) {
    top: 33%;
  }

  .icon span:nth-child(2) {
    top: 66%;
  }

  input[type="checkbox"]:checked + .icon span:nth-child(1) {
    top: 50%;
    transform: rotate(45deg);
  }

  input[type="checkbox"]:checked + .icon span:nth-child(2) {
    top: 50%;
    transform: rotate(-45deg);
  }
}

By using nesting and input[type="checkbox"] we can create reusable CSS. We can create a second hamburger with a different id for the input without the causing a conflict:



<div class="hamburger">
  <input type="checkbox" id="accordion-toggle">
  <label for="accordion-toggle" class="icon">
    <span class="bg-black"></span>
    <span class="bg-black"></span>
  </label>
</div>

This also allows the hamburger to only care about its own state. You can just drop it in to your site, and without a controller object, the spans will animate, but that's it.

The menu

I won't paste the whole .menu HTML here, but it's a div with a nav, nothing special.

The CSS isn't much either



.menu {
  position: absolute;
  top: 0;
  left: 0;
  /* hide the menu by setting the width to 0 */
  /* we can't animate from display:none to width:auto yet… */
  width: 0;
  height: 100dvh;
  transition: width 300ms ease-out;
  overflow: hidden;
}

We position it absolutely (in this case, we'll position the header so the menu attaches to that) to the top and the left and animate its width. This will cause it to animate from left to right.

The header

The HTML for the header has a logo (optional), the hamburger and the menu:



<header class="flex justify-between px-4 py-6 bg-gray-500">
  <div class="logo">...</div>
  <div class="hamburger">...</div>
  <div class="menu">...</div>
</header>

And the CSS is about as simple as can be!



header {
  position: relative;
  &:has(.hamburger input[type="checkbox"]:checked) .menu {
    width: 300px;
  }
}

Using the :has() selector allows up to check the state of one child to update the state of another.

Reusability

One advantage of this type of menu, besides the ridiculously easy CSS, is how reusable it is.

Another hamburger can be placed anywhere without affecting other menus. In the Codepen below, I added a accordion element using the same hamburger.

This works really well in component based frameworks where you can just use a <Hamburger /> component inside a controller and wire it all up.

Finished project

Here is the whole thing.

I used Tailwind for non-critical styling, and all the relevant CSS for the .hamburger and parts is in the CSS file.

Areas for improvement

One major area for improvement is accessibility. The example isn't very accessible.

As mentioned before, turning the hamburger into a reusable component could greatly improve the portability of it.

Let me know what you think!

Building an Add to Cart Button using Web Components

Charles Loder — Thu, 23 May 2024 21:00:53 +0000

Introduction

This post will layout a short tutorial on how to build an Add to Cart button for an ecommerce store using Web Components. Though this example uses the Fake Store API, the concept can really be applied to any ecommerce platform.

It will review:

The product page and the requirements
The anatomy of a web component
The business logic
The final product

You can skip to the end to see the whole example on CodePen.

But first, a little context…

Context

A client wanted an ajax Add to Cart button for some upsell products on their Shopify store. JQuery would have worked just fine, but I wanted to try something different.

I'd been looking for a reason to use Web Components. I wanted something more complex than a basic counter example but not something too complex.

An Add to Cart button provides the perfect amount of complexity.

Page Overview

The ecommerce store looks like this:

There's a main product with an add to cart button, and then 3 upsell products below.

For this article, the key is that the main add to cart button is not an ajax button; it's a regular form submit as is common on ecommerce sites. When the user submits the form, they are directed to the cart page. Though, that doesn't really happen on a CodePen.

The requirements for the Add to Cart button are simple:

the user should click on the button firing a fetch request
the button should indicate that it is processing the request
if the product was added or if there was an error, the button should indicate that.

The upsell buttons are our web components. Notice that they have the same styling as the main button. That's because they're using the same global CSS. Web Components have their own styling so slots need to be used to ensure they inherit styling.

Anatomy of a Web Component

Web Components are custom elements, so we add them to the page like regular HTML:



<add-to-cart>
  <button slot="button" type="submit" class="btn--atc">
    Add to cart
  </button>
  <input slot="input" type="hidden" name="quantity" value="1">
</add-to-cart>

Take note of how the button and input are being added.

The Web Component structure looks like this:



class AddToCartButton extends HTMLElement {
  // props
  productId;
  button;

  // constructor
  constructor() {
    super();
    this.attachShadow({ mode: "open" });

    // where styles and HTML go
    this.shadowRoot.innerHTML = ``;
  }

  // lifecycle
  connectedCallback() {}
}

// register it
customElements.define("add-to-cart", AddToCartButton); 
```

Like any class, there's a constructor, and props and methods can be defined, but it also includes [lifecycle hooks](https://developer.mozilla.org/en-US/docs/Web/API/Web_components/Using_custom_elements#using_a_custom_element:~:text=Custom%20element%20lifecycle%20callbacks%20include%3A). This one only uses `connectedCallback` which is called when the component is mounted.

### The Constructor

In the constructor, we can set some state and define the HTML of the shadow root.

```js
constructor() {
  super();
  this.attachShadow({ mode: "open" });
  this.shadowRoot.innerHTML = `
  <style>
    :host{
      display: flex;
      flex-direction: column;
      width: 100%;
    }
  </style>
  <slot name="button"></slot>
  <slot name="input"></slot>
  `;
}
```

The constructor isn't the place to check for attributes or really query anything about the component. According to the [docs](https://developer.mozilla.org/en-US/docs/Web/API/Web_components/Using_custom_elements#implementing_a_custom_element):

> In the class constructor, you can set up initial state and default values, register event listeners and perhaps create a shadow root. At this point, you should not inspect the element's attributes or children, or add new attributes or children. See Requirements for custom element constructors and reactions for the complete set of requirements.

The most important thing to note in this constructor is the `this.shadowRoot.innerHTML`.

The style tag defines styles that apply inside component, and only inside component. The `:host` selector selects the actual component. The only style defined is that it's a flex column.

For this component, the button styles need to inherit from the global css, so styling a button within the component wouldn't work.

In order to allow the button to be styled from the outside the component, a `slot` is used.

This component has two slots:

```html
<slot name="button"></slot>
<slot name="input"></slot>
```

This allows children to be passed in to the component:

```html
<add-to-cart>
  <button slot="button" type="submit" class="btn--atc">
    Add to cart
  </button>
  <input slot="input" type="hidden" name="product-id" value="1">
</add-to-cart>
```

This is especially helpful in an ecommerce setting where (1) there is already a set of styles and (2) a templating language like Liquid is used to render out the elements using product data:

```liquid
<input slot="input" type="hidden" name="product-id" value="{{ product.id }}">
```


### The connectedCallback

Once the component is mounted, the `connectedCallback` hook is called.

It's here where the slots can be queried.

```js
connectedCallback() {
  const buttonSlot = this.shadowRoot.querySelector(`slot[name="button"]`);
  buttonSlot.addEventListener("click", (e) => this.addToCart());
  this.button = buttonSlot
    .assignedElements()
    .find((el) => el.tagName === "BUTTON");

  const inputSlot = this.shadowRoot.querySelector(
    `slot[name="input"]`
  );
  const input = inputSlot
    .assignedElements()
    .find((el) => el.tagName === "INPUT");

  // coerce string to number
  this.productId = +(input.value);
}
```

#### Getting the Elements

The `querySelector` can be used to query within the `shadowRoot` to the slots. Then `assignedElements()` returns all the elements that have the matching `slot` name.

So for the button, the attribute of `slot="button"` makes the button an assigned element of `slot[name="button"]`. Filtering according to tag type isn't necessary, but just ensures an actual button is returned.

#### Setting the Properties

The `this.button` and `this.productId` are properties of the component, defined above the constructor.

```js
class AddToCartButton extends HTMLElement {
  /** @type {number} */
  productId;
  /** @type {HTMLButtonElement} */
  button;
  constructor() {}

  connectedCallback() {}
}
```


#### Adding an EventListener

The last part of the callback is adding an event listener:

```js
buttonSlot.addEventListener("click", (e) => this.addToCart());
```

This is where the actual logic of the add to cart button will happen.

## The Business Logic

There are two parts to the business logic — the request to the api and updating the UI

```js
/**
 * Set the state of the button
 *
 * @param {('fetching' | 'success' | 'error')} state
 */
setButtonState(state) {
  const button = this.button;
  const fetching = "fetching";
  const success = "success";
  const error = "error";

  switch (state) {
    case "fetching":
      button.textContent = "Adding...";
      button.disabled = true;
      button.classList.add(fetching);
      button.classList.remove(success, error);
      break;
    case "success":
      button.textContent = "Added!";
      button.disabled = true;
      button.classList.add(success);
      button.classList.remove(fetching, error);
      break;
    case "error":
      button.textContent = "Retry";
      button.disabled = false;
      button.classList.add(error);
      button.classList.remove(fetching, success);
      break;
    default:
      break;
  }
}

async addToCart() {
  this.setButtonState("fetching");

  try {
    const response = await fetch("https://fakestoreapi.com/carts/7", {
      method: "PUT",
      body: JSON.stringify({
        userId: 3,
        date: 2019 - 12 - 10,
        products: [
          {
            productId: this.productId,
            quantity: 1
          }
        ]
      })
    });

    // obviously, this is only for testing
    if(this.getAttribute('error')) {
      throw new Error("A test error");
    }

    const json = await response.json();
    console.log(json);
    this.setButtonState("success");

  } catch(error){
    console.error(error);
    this.setButtonState("error");
  }
}
```

*Note the `error` attribute. That isn't needed, but helpful for testing.*

The `addToCart()` method is straightforward:

- Set the button to `"fetching"`.
- Make the request.
- If it's successful, set the button to `"success"`
- If there's an error, set the button to `"error"`


The `setButtonState()` updates the button's text and applies classes for styling.

In a typical Web Component, the classes would be defined in a style tag, but because slots were used,  the styling from the global css can be applied to the elements assigned to the slot.

This has some pros and cons.
- Pro: can define the CSS of the component with the rest of your CSS
- Con: the class names are hardcoded to the component, but have to correlation to anything inside the component (i.e. what does a `"success"` class mean in the component? nothing).

Attributes could be used to pass in class names:

```html
<add-to-cart
  btn-fetching-class="fetching"
  btn-success-class="success"
  btn-error-class="error"
>
```

This would allow any name class names to be used, but for a one-off component, it may be a bit much.

Now to see it all in action.

## The Final Product

Here is the final product

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/q95iw8rxjqf6wkszvsz0.gif)

Also see it on CodePen

Publishing ESM and CommonJS packages with Typescript

Charles Loder — Mon, 25 Mar 2024 19:22:38 +0000

ECMAScript modules (esm) is the official way to handle imports and exports in Javascript, but CommonJS (cjs) has been part of the ecosystem do so long that support for it still feels necessary.

In this post I'll show my method for publishing an npm package that exports both esm and cjs compatible code.

The code is available on stackblitz.

Note: it is better to view the code on stackblitz as the embedding shows some errors that aren't real.

src

For example purposes, the src/ directory is more complicated than it needs to be. There is an index.ts file, which exports modules from the arithmetic/ directory.

tools

Besides Typescript, this process also relies on tsc-alias and @alcalzone/esm2cjs.

The first is used to add .js extensions for imports, which isn't necessary in all contexts, but doesn't hurt.

The second compiles esm projects to cjs.

So right away, you can see there is quite a lot happening in the build process — tsc, tsc-alias, and esm2cjs.

This isn't ideal for large projects, but for small projects the build time is minimal.

configs

This is the minimal tsconfig config needed:



{
  "compilerOptions": {
    "declaration": true,
    "declarationDir": "dist/types",
    "esModuleInterop": true,
    "lib": ["ES2021"],
    "module": "ESNext",
    "moduleResolution": "Node",
    "outDir": "dist/esm",
    "target": "ES2021"
  },
  "tsc-alias": {
    "resolveFullPaths": true,
    "verbose": true
  },
  "include": ["src"],
  "exclude": ["node_modules", "test"]
}

Note the config for tsc-alias.

package.json

The most complicated part is the package.json:



{
  "name": "tsc-as-cjs-esm",
  "version": "0.1.0",
  "main": "./dist/cjs/index.js",
  "module": "./dist/esm/index.js",
  "types": "./dist/types/index.d.ts",
  "files": ["dist"],
  "exports": {
    "./package.json": "./package.json",
    ".": {
      "types": "./dist/types/index.d.ts",
      "require": "./dist/cjs/index.js",
      "import": "./dist/esm/index.js"
    }
  },
  "scripts": {
    "start": "tsc --watch",
    "build": "tsc && tsc-alias -p tsconfig.json",
    "postbuild": "esm2cjs --in dist/esm --out dist/cjs -l error"
  },
  "devDependencies": {
    "@alcalzone/esm2cjs": "^1.1.2",
    "tsc-alias": "^1.8.8",
    "typescript": "^5.2.2"
  }
}

The exports block lets node know where to look when importing or requiring a module.

building

You can build the package by running npm run build. This causes:

Typescript to compile the project
tsc-alias to add file extensions
esm2cjs to create a cjs package from the above output

This creates a dist/ directory that looks like this:



dist
├── cjs
├── esm
└── types

Inside esm/ and cjs/ each, there is a package.json.



// dist/esm/package.json
{
    "type": "module"
}

and



// dist/cjs/package.json 
{
    "type": "commonjs"
}

After that, running npm pack creates a tarball and copies the root package.json to the package.

testing

Create a package that uses esm modules with a package.json:



{
  "name": "test",
  "main": "index.js",
  "type": "module"
}

Note the "type": "module",

Move the tarball into the repo (not necessary) and install the it using npm i tsc-as-cjs-esm-0.1.0.tgz.

Then in index.js, you can do:



import { add } from "tsc-as-cjs-esm";

console.log(add(1, 2));

If you remove the "type": "module" line, you'll get an error and have to use cjs syntax:



const math = require("tsc-as-cjs-esm");
const add = math.add;

console.log(add(1, 2));

Homebrew on a multi-user Mac with a silicon chip

Charles Loder — Wed, 28 Feb 2024 02:39:04 +0000

It's not the catchiest title, but hopefully this post will be helpful if you have a specific use case — you have a Mac with a silicon chip, you have two users that are essentially you (i.e. work and personal), and you want homebrew to be accessible on both.

This isn't an unknown situation, see here.

I'll call the two users personal and work throughout this post

install homebrew

The first step is to install homebrew. I installed mine on personal.

If you run echo $PATH, you should see homebrew in your path:



/opt/homebrew/bin:/opt/homebrew/sbin

When you run brew in the terminal, those paths are where homebrew lives, which is different on the Applie silicon chips than older chips.

update other user config

In work, update the .zshrc file by adding this:



export PATH="/opt/homebrew/bin:/opt/homebrew/sbin:$PATH"
alias brew='sudo -Hu personal brew'

The first line simply adds homebrew to your $PATH.

Because this user doesn't have permissions for the brew command, you have to hardcode the values.

The second line simply aliases the brew command to use sudo to run brew from the personal user.

Then restart your shell.

After that, while logged in as work, you can run brew install <PACKAGE>, enter the password for personal, and then the package will be accessible to both users!

This may not be the perfect way to do it, but it worked for me.

How to create a 'canary' release on npm

Charles Loder — Mon, 06 Nov 2023 14:19:07 +0000

This post will show how to create a canary release for an npm package.

tldr;



npm version --preid canary preminor
npm publish --tag canary

canary testing

In short, canary testing is a way to publish packages without affecting all users. Users will have to opt-in to use a canary release.

versioning

The version command has a few built in options.

If our package is at 1.1.0 then running npm version minor will update the package.json to 1.2.0. Additionally, it will update package-lock.json and npm-shrinkwrap.json and add a git tag.

To update 1.1.0 to a canary version, run:



npm version --preid canary preminor

This updates the version to 1.2.0-canary.0.

To make updates to this version, run:



npm version --preid canary prerelease

This updates the version to 1.2.0-canary.1.

publishing

To ensure that the canary branch isn't published to @latest, it can be tagged.

To do so, run:



npm publish --tag canary

This ensures that when a user runs:



npm i your-pkg

That it installs the latest, stable, release.

To install the canary version, they must run:



npm i your-pkg@1.2.0-canary.1

summary



npm version --preid canary preminor # go from 1.1.0 to 1.2.0-canary.0
npm version --preid canary prerelease # go from 1.2.0-canary.0 to 1.2.0-canary.1
npm publish --tag canary # publish your-pkg@1.2.0-canary.1

TIDBIT: formatting JSON in a templating language

Charles Loder — Fri, 15 Sep 2023 14:15:41 +0000

Liquid syntax error: Tag '{% if book.numberOfPages %}' was not properly terminated with regexp: /\%\}/

5 ways to write 1 function

Charles Loder — Mon, 28 Aug 2023 13:07:27 +0000

One of the beauties of JavaScript is the many different ways available to accomplish a task.

One of the difficulties of JavaScript is the many different ways available to accomplish a task.

In this tutorial, we'll explore the diverse methods for crafting a basic function.

Our focus: a straightforward name logging function.

Let's proceed!

0. What is a function

A function is reusable piece of code that can optionally take arguments and can return a value, do something, or both.

1. The Fundamentals

Let's start with an incredibly simple function:



function greet() {
  console.log("Hi, Maria");
}

greet();
// "Hi, Maria"

When the greet() function is called, all it does is log the message "Hi, Maria" to the console.

This function is doing something; it is calling another function, console.log, which logs the string.

But what if we wanted to use the name elsewhere?

2. Incorporating Variables

If we want other functions to have access to the name, we can use a variable:



var name = "Maria";

function greet() {
  console.log("Hi, " + name);
}

greet();
// "Hi, Maria"

This produces the same result as before.

Also, now we can write other functions that use the variable:



function capitalize() {
  name = name.toUpperCase()
}

Great!

Except, we can have unexpected consequences:



capitalize();
greet();
// "Hi, MARIA"

Oh, no! Thankfully, there is a way to fix that, parameters.

3. Parameters

We can pass in parameter's to our functions so that they are scoped:



function greet(name) {
  console.log("Hi, " + name);
}

greet("Maria");
// "Hi, Maria"

Unlike the previous example, where the greeting's outcome could be changed due to modifications in a shared global variable (i.e. name), the use of parameters ensures that the greeting's content remains consistently reliant on the specific values passed into the function.This mitigates unexpected alterations and provides a more controlled and predictable behavior.

But what if we wanted to use this greeting in other places, not just the console?

4. Return Statements

If we want to use the greeting in other places, instead of logging the statement we can return it:



function greet(name) {
  return "Hi, " + name;
}

console.log(greet("Maria"));
// "Hi, Maria"

This time, instead of our function logging the greeting, it simply returning the greeting, which we can use any way we want.

In the example we just logged it again, but you could use it as a greeting on a website.

But what if we want to impress people with our cool looking code?

5. Embracing Arrow Syntax

The syntax we've been using is called a function declaration.

We have two more options to use — function expressions or arrow syntax.

There are real differences between all three, but for our purposes the results will be the same.

With the arrow syntax we can write our function like this:



const greet = (name) => "Hi, " + name;

We do not have to explicitly put a return statement.

And we can look extra cool with template literals



const greet = (name) => Hi, </span><span class="p">${</span><span class="nx">name</span><span class="p">}</span><span class="s2">;

More to learn

We learned about the many ways to write a simple function and the pitfalls to some of those ways

There is a lot more that can be said about functions, that can't be said here.

Happy coding!

Question: new tech or old tech on a portfolio?

Charles Loder — Mon, 07 Aug 2023 16:03:13 +0000

If you are a hiring manager, which looks better on a portfolio something written in new tech or old tech?

Besides my passion projects, I've been wanting to write something that would look nice on a portfolio (maybe an issue tracker?). My first thought was Astro, but maybe Ruby on Rails would be good too.

Thoughts?

Svelte: set a default radio button with bind

Charles Loder — Mon, 24 Jul 2023 19:45:50 +0000

I've just started using Svelte, and it's been really fun to work with!

Today, I did, however, run into a little quirk with radio buttons. If you use the bind directive, there is no way to have a radio button checked by default.

bind directive

In Svelte, you can use element directives, and particularly helpful for radio buttons is the bind directive.

Basically, you can group a number of radio inputs together. Here is the example from Svelte's docs:



<script>
  let tortilla = 'Plain';

  /** @type {Array<string>} */
  let fillings = [];
</script>

<!-- grouped radio inputs are mutually exclusive -->
<input type="radio" bind:group={tortilla} value="Plain" />
<input type="radio" bind:group={tortilla} value="Whole wheat" />
<input type="radio" bind:group={tortilla} value="Spinach" />

It's pretty straightforward — all these inputs are bound together as part of the group "Plain".

Note: if the variable were named group instead of tortilla, you can just write bind:group, which is nice.

If you were to create a Svelte repl you would notice that when the code compiles, no radio buttons are checked.

That may be ok in some situations, but I wanted to ensure that at least one is checked.

The solution is a lifecycle hook.

onMount hook

Like most component libraries, Svelte allows you to hook into the components lifecycle.

For this issue, the onMount hook is needed.

Now, when the component is mounted, I can can check if there are any checked inputs. If not, then I check the first:



onMount(() => {
  const inputs = document.querySelectorAll("input");
  const hasChecked = Array.from(inputs).some((input) => input.checked);
  if (!hasChecked) {
    inputs[0].checked = true;
  }
});

That's it!

Here is a full example and a link to a repl.



<script>
  import { onMount } from "svelte";
  let group = "philosophers"
  const options = ["Søren Kierkegaard", "Jean-Paul Satre", "Simone de Beauvoir", "Albert Camus"];

  onMount(() => {
    const inputs = document.querySelectorAll("input");
    const hasChecked = Array.from(inputs).some((input) => input.checked);
    if (!hasChecked) {
      inputs[0].checked = true;
    }
});

</script>

<div class="question">
  <legend>Who is your favorite existentialist philosopher?</legend>
  {#each options as option}
    <div class="option">
      <input type="radio" id={option} bind:group value={option}>
      <label for={option}>{option}</label>
    </div>
  {/each}
</div>

<style>
  div.question {
    display: flex;
    flex-direction: column;
  }
</style>

Hopefully, this helps anyone else who encounters this issue.

Dockerize an Express app and MongoDB

Charles Loder — Mon, 15 May 2023 16:24:53 +0000

I don't like dealing with databases, and I don't like doing tutorials with no idea of what's going on.

Somehow, in someway, something always goes wrong.

This tutorial has two goals:

show how to set up an express app with a mongo database running in Docker
explain what is happening in the Docker configs

The banner image was made with DreamStudio. I should really learn how to do prompt engineering.

What we'll be building

In this tutorial, we'll be building a simple todo app. The server is built with express, and the database will be MongoDB. The key is that the whole app will be dockerized, making dealing with the database easier, but we'll still be able to make changes to our server for development.

I won't get into the details of how Docker works internally (I don't think I could even begin to do that!) but rather make all the configuration needed understandable.

We'll look over

the app itself
the Dockerfile in the app
the docker-compose.yml file

A github repo with all the code can be found here.

Prereqs

The only things you need to have installed are Node (which if you're reading this, you probably have), and Docker.

The easiest way to get started with Docker is by installing Docker Desktop.

How the app works

The app is pretty simple.

There is only one view route /. When a user hits /, the app lists out all the todos in the database.

Whenever the user adds a new todo, deletes a todo, or deletes all the todos, a request is made to the appropriate route, the action is done (like add a new todo), and the app redirects them to / page, where all the todos, including the one just added, are displayed.

This app is just a clone of this repo with some minor modifications.

Dockerizing

Here are our main building blocks for getting set up with Docker:

the Dockerfile
the docker-compose.yaml

`Dockerfile`: our app

The first building block is the Dockerfile. This is a set of instructions that tells Docker how to build our image

Ours looks like this:

FROM node:18
WORKDIR /app
COPY package*.json .
RUN npm install
COPY . .
CMD [ "npm", "run", "start:dev" ]

Let's break it down.

FROM node:18
First we use the node 18 image. This is an express app, so we need node.

WORKDIR /app
The next line sets the working directory to /app. We don't have an /app directory in our source, but Docker creates one inside of the container. This is sort of like a mkdir and cd command in one. It creates a new directory and sets that as our working directory.

COPY package*.json .
The COPY command copies contents from your local machine to the working directory in the container.

Its syntax is like this:

COPY <src> <dest>

This command copies the package.json and package-lock.json files to the container.

RUN npm install
Pretty straightfoward — in the container's working directory, run npm install.

COPY . .
As we've seen from the previous copy command, this copies the contents of our local machine into the container. This particular command, however, copies all the contents of repo (unless we have a .dockerignore file).

CMD [ "npm", "run", "start:dev" ]
Now we start the app! You'll commonly see these commands expressed as an array like this.

The command npm run start:dev is defined in our package.json:

{
  "name": "dcoker-todo",
  "scripts": {
    "start": "node app.js",
    "start:dev": "nodemon -L app.js"
}

`docker-compose.yaml`: running everything

Now we get to the good stuff — actually running our express app with a Mongo database.

Docker terminology can be a bit tricky at times, so let's recap.

In the previous section, we used a Dockerfile to create an image. An image defines our container. A container is an instance of an image running. In this section, we are going to use compose to build an application that's composed of multiple containers.

Before we run our app, there is one thing we need to so first; set up an .env.

PORT=3000
MONGODB_URI=mongodb://db:27017
MONGODB_USER=admin
MONGODB_PASSWORD=admin
MONGODB_DATABASE=todos

The only value that isn't arbitrary is MONGODB_URI. We'll look at that later.

We need to set up a docker-compose.yml, this tells the compose command how to structure our application.

It can be a bit overwhelming at first

# version: "3.8" no longer needed
volumes:
  db:

services:
  app:
    container_name: todo_app
    build: .
    ports:
      - "3000:3000"
    environment:
      - PORT=${PORT}
      - MONGODB_URI=${MONGODB_URI}
      - MONGODB_DATABASE=${MONGODB_DATABASE}
    volumes:
      - .:/app
      # if you comment out the line below, you will have to run npm install locally
      - /app/node_modules
    depends_on:
      - db
    links:
      - db

  db:
    container_name: mongodb
    image: mongo:latest
    restart: always
    volumes:
      - db:/data/db
    command: mongod
    environment:
      MONGO_INITDB_ROOT_USERNAME: ${MONGODB_USER}
      MONGO_INITDB_ROOT_PASSWORD: ${MONGODB_PASSWORD}
      MONGO_INITDB_DATABASE: ${MONGODB_DATABASE}
    ports:
      - 27017:27017

The big picture

Let's break it down.

# version: "3.8" no longer needed
volumes:
services:

version:
You'll often see version number at the top, but this is no longer needed.

The version number is the version of the docker-composer.yml file NOT the version of Compose.

In June 2023 they are updating docker compose to v2. This tutorial is assuming you're using v2 (I'm on v2.10.2).

volumes:
Volumes are how data is persisted outside of the container. So when you tear down the container, the data (i.e. our todos) will still be there.

services:
These are the container in your app.

Now, let's dig into volumes more.

volumes

volumes:
  db:

That's it! No, really. All we have to do is define a volume called db, and we're good to go. We could add extra configuration, but we don't need to do that for this tutorial.

What does matter, however, is that we have to use the name db everywhere to reference this volume. That will matter for our services, and it matters for our .env file above. That's why MONGODB_URI has to connect to mongodb://db:27017. The db has to match the name of the volume. The port number is the default port.

note: often, services is defined at the top of the file and volumes below. The ordering makes no difference.

services

services:
  app:
  db:

We have two containers — app and db.

services:app

services:
  app:
    container_name: todo_app
    build: .
    ports:
      - "3000:3000"
    environment:
      - PORT=${PORT}
      - MONGODB_URI=${MONGODB_URI}
      - MONGODB_DATABASE=${MONGODB_DATABASE}
    volumes:
      - .:/app
      - /app/node_modules
    depends_on:
      - db
    links:
      - db

container_name:
Just a name!

build: .
This tells docker which image to use to build the container. In this case, it's our Dockerfile we defined above.

ports:
    - "3000:3000"

This says to map port 3000 on our machine to port 3000 in the container (i.e. we can access the app by going to localhost:3000)

environment:
  - PORT=${PORT}
  - MONGODB_URI=${MONGODB_URI}
  - MONGODB_DATABASE=${MONGODB_DATABASE}

The sets the environment variables within the app from our .env file. So when we do

var port = process.env.PORT || 3000;
app.listen(port, ...)

The PORT is injected to the container from our .env file.

volumes:
    - .:/app
    - /app/node_modules

This is probably one of the more confusing parts of the set up.

As said before, volumes are ways to persist data. With the first definition, the . directory is mapped to /app in the container. Remember, /app from the Dockerfile? That's our working directory where everything is installed. It essentially replaces /app in our container with ..

The second definition is trickier. Notice that there is no :, which means there is no mapping. This definition will mount /app/node_modules to the previous mapping, i.e. your host. As a side effect, it creates an empty node_modules!

This means that the node_modules in the container is being used.

<Aside>

If you were to remove this definition, the app wouldn't work unless you ran npm install on the host (i.e. your machine).

You would also want to add a .dockerignore ignore to your repo like this:

node_modules
npm-debug.log

</Aside>

The answer here explains it well.

depends_on:
  - db
links:
  - db

These last two go hand-in-hand for our case. The depends_on definition means that Docker will wait for the db service, defined below, to start first. The links definition enables the two services to communicate. We want our app container to be able to talk to our database container.

services:db

services:
  # app: goes here
  db:
    container_name: mongodb
    image: mongo:latest
    restart: always
    volumes:
      - db:/data/db
    command: mongod
    environment:
      MONGO_INITDB_ROOT_USERNAME: ${MONGODB_USER}
      MONGO_INITDB_ROOT_PASSWORD: ${MONGODB_PASSWORD}
      MONGO_INITDB_DATABASE: ${MONGODB_DATABASE}
    ports:
      - 27017:27017

We defined our app service, now we have to define a service for our database.

We already defined this as a volume, but we also need to define it as a service (i.e. a container). The name of the service, needs to match the name of the volume.

container_name: mongodb
Again, just a name!

image: mongo:latest
Unlike the build command in our previous service, image tells Docker to pull down a prebuilt image; in this case, mongodb.

restart: always
Restarts the service if something happens.

volumes:
    - db:/data/db

Another volume! We know that : means we are mapping something. In this case, we are mapping the volume defined at the top of our file to the directory /data/db in the container, which is the default storage location. Remember that a mapping essentially replaces the right hand side. So when the container starts, /data/db is replaces by the volume that Docker created to persist our data.

command: mongod
The command to start the database.

environment:
  MONGO_INITDB_ROOT_USERNAME: ${MONGODB_USER}
  MONGO_INITDB_ROOT_PASSWORD: ${MONGODB_PASSWORD}
  MONGO_INITDB_DATABASE: ${MONGODB_DATABASE}

I think that this is one of the coolest things! We can set a default username, password, and database when the container starts. These environment variables are specific to mongo, and there is more information in the docs.

What's cool is that we can define these in our .env and use them to connect to the database with our server, like this:

mongoose
  .connect(`${process.env.MONGODB_URI}`, {
    dbName: `${process.env.MONGODB_DATABASE}`,
    user: `${process.env.MONGODB_USER}`,
    pass: `${process.env.MONGODB_PASSWORD}`,
    useNewUrlParser: true,
    useUnifiedTopology: true,
    useFindAndModify: false,
  })

This let's us keep our code DRY!

ports:
  - 27017:27017

Another mapping; this time for mongo's default port.

Running it.

If you clone the repo, all you have to do it is run it:

docker compose up

That should do it!

A little extra

Ok, that's a lot of output. We really only want to see the output of our app. We can run:

docker compose up --attach app

to get output only from our app container. It will look something like this:

todo_app  | 
todo_app  | > dcoker-todo@1.0.0 start:dev
todo_app  | > nodemon -L app.js
todo_app  | 
todo_app  | [nodemon] 2.0.22
todo_app  | [nodemon] to restart at any time, enter `rs`
todo_app  | [nodemon] watching path(s): *.*
todo_app  | [nodemon] watching extensions: js,mjs,json
todo_app  | [nodemon] starting `node app.js`
todo_app  | Successfully connected to the server at 'http://localhost:3000/'
todo_app  | Connected to todos as admin

Of course, todos and admin will be whatever you set them as in the .env.

Additionally, after you shut down the container, you'll still want to run

docker compose down

to stop the mongodb container.

Let me know if it works, and I hope it help!