DEV Community: Jim Burbridge

Into the Fray: A Dive into Deno

Jim Burbridge — Mon, 27 Jun 2022 07:55:00 +0000

Tl;Dr: I just wanted to build a simple CLI in Deno, and now I've made at least 5 repositories related to Deno in the search to flush out the ecosystem. I'm not done yet.

Backstory

I've been following Deno since stumbling across Ryan Dahl's talk about things he wishes he'd have done different with Node JS(embedded below).

When 1.0 came out I was itching to try and do something with the runtime. Recently, I got a chance to try something.

Previously where I worked we had a Design Token library. I wasn't entirely sure how it worked, but in thinking about it I thought it should be easy to make something that would generate tokens for my own projects.

Well, I made it.

jhechtf / design-tokens

Design token generator written in Deno + TS

Raven (Design Token Generator)

Trying to create design tokens that can be used in CSS, SCSS, and Javascript/Typescript?

Yeah, me too.

Notes

In the end I hope that there will be two ways that users can use this library:

In code, by importing the relevant items / functions and building it themselves or
By using a CLI tool with a config file (aiming for it to be TS, but considering JSON) to generate it the necessary files in one shot.

Usage

Currently the code can be used with the following examples.

import { MediaQuery, Stylesheet, Token } from './mod.ts';
// Creates a new stylesheet
const stylesheet = new Stylesheet();
// create the tokens.
const primaryToken = new Token('primary-color', '#fecc99');
const spacingToken = new Token('gap', '4px', 'size');
const blueToken = new Token('blue-100'

…

View on GitHub

As Deno (in particular deno.land/x/) works with GitHub when a tag is pushed to the repository I had wanted to do something like NodeJS' "Standard Version." I asked on the Github page if there was a plan to port Standard Version over to Deno, and after not receiving a response I started on Version Bump(aren't I the greatest at names?).

This portion took quite a bit of time, and went through at least 2 system overhauls that I can remember. My goal was to make Version Bump much more pluggable than Standard Version was, and in doing that I had to be very careful with how I worked with things. I could honestly write a whole post about Version Bump, but I had wanted to hit a 1.0 release but wanted to ensure I had hit a code coverage target before going forward.

Well, turns out there's built in code coverage in Deno's testing, and even a way to get it into a format that isn't totally weird. Downside though, is that there wasn't a way I found to get this information into a report table like I was accustomed to (thanks Jest).

Can you guess what I did next?

That's right, built my own!. Code Coverage Takes an LCOV file generated through test data and the deno coverage command and outputs a nice little table for you.

Except the table breaks the viewport when you have a larger file that has many missing blocks of text.

I had to build Terminal Size, using a combination of a very nice Rust package and Deno's Foreign Function Interface in order to get this to work. However, this meant that I had to use a different table library because the one I was using wouldn't be work with the terminal size out of the box. Yup, another package.

ASCII Table Uses the terminal size library to get the terminal size if requested. Unfortunately this requires a lot of permission from Deno's sandbox, and the use of the --unstable flag so I doubt people will use it until it no longer requires that flag.

Impressions

What have you learned?

A couple of things:

I really enjoy Deno.

Direct TS? No fiddling with TS-Node or having to declare TS as a package? I love it.

Since it is newer, it's ecosystem is not as flushed out.

This ends up showing up in weird places; you know, like trying to get your code coverage into a quick and precise format. I'm going to see about contributing back to the deno project's coverage command, but I feel like I should know more about Rust before doing that. I don't want for the Code Coverage tool to be a necessary third-party tool in the Deno ecosystem going forward.

Sometimes the permissions thing feels a little like it gets in the way.

Especially for CLI libraries such Raven, Version Bump, or Code Coverage. On the one hand being able to run and install a library only in the current directory could be great, but on the other it feels more like a hurdle than anything else. One thing I wish I could've done was determine if the current script was being run with the --unstable flag to dynamically load my terminal library, allowing people who aren't using the full-width feature to scope down their permissions.

Please feel free to try out any of the tools I've made, and any ideas for improvements please go ahead and create an issue on the given Github. Any PRs are welcomed!

The World's Worst Todo App

Jim Burbridge — Sat, 23 Oct 2021 03:37:42 +0000

There's plenty of great todo list applications out there.

Vicci is definitely not one of them.

However, that's not what its aim is.

You see, Vicci started life as what was meant to be a front-end only project to show some architecture examples to a friend of mine. We call him "Vinny", and every time I was writing something to help him the old latin phrase "veni, vidi, vici" ("I came, I saw, I conquered"). The last bit of that, "vici", is where I drew the name for the project. It means "I conquered," and I think that's pretty uplifting of a motto for a list of things that needs to get done.

Once I started to go really hard into the code I realized that it would be nice if there was some kind of user system, so I thought "well I'll just add a Cognito, and that way the user can login and out" but after that I thought "I mean, if the user system is out of the way, what's stopping me from building a simple API?" So... I did.

The result is a project far removed from the "quick and dirty" app that I wanted to start with, and is instead an app in a weird state as of writing this.

The UI is... let's say rough. It wasn't meant to be, but this all started as a way to show off the architecture more than the view. As such, the API is also pretty rough.

That's fine though. It's more a chance to talk about the tech and architecture used in it, specially in the context of a "Serverless" app on AWS.

That all said, let's talk about the tech stack:

React + TypeScript
TailwindCss
Webpack
AWS SAM, includes AWS Lambda and API Gateway
AWS CloudFront
AWS S3
AWS CDK
Route53
AWS Certificate Manager (for the SSL certs in prod)
GitHub as source control version host.

Notice, nothing too outrageous, odds are if you already work in the web right now most of these are things you have at least some experience with. I will (eventually) get to the point where tag pushes to any of the github repos will also trigger a deployment of said resource, but was running into issues and wanted to get this published before my job got busy.

I'm open to feedback from other engineers, and questions from people new to programming in this space. Please create an issue on the corresponding Github repo and I'll address it as soon as I can.

Til then, welcome to the world's worst todo app.

A(nother) Todo List: Version 1.2

Jim Burbridge — Sun, 07 Mar 2021 04:25:48 +0000

Note: This post refers to this branch, and is a part of an ongoing series.

Version 1.2 looks a little different, yet again. As the README states in the repo:

This branch is the version of the application where the developer has started more work into finding a solution where directly modifying the todo values links those changes to the DOM.

For this version of the project I've chosen a very rough implementation of the Observer pattern, as I think that of the ways that frameworks and updates function currently that this is probably the easiest to understand; there's not a lot of magic that goes on, like you would have to make the jump to understand with things like Proxies (which I believe Vue uses, though I could be wrong) or the magic that comes from the Svelte compiler. You create a store, and in one particular place that we subscribe to it we set the render function.

This is also nice because it's a relatively simple pattern to follow and extend, meaning that if we should want to create other "components" there really isn't a lot we would need to add. It's also nice because decoupling the store (or "state") from the rendering process means that we could just subscribe to the todos state in other locations to make some additional functionality, such as adding in a "yet to be done" section in an entirely different part of the page (like the navbar).

So let's take a look at the world's roughest Observable implementation.

//observableStore.class.js
/**
 * @template T
 * @description A very rough observable-store class. In real-life, you would probably use a library like RxJS
 */
export default class ObservableStore {
  /**
   * @param {T} initial The initial value for the store. Defaults to null.
   */
  constructor(initial = null) {
    this._store = initial;
    this._fns = [];
  }

  /**
   *
   * @param {T | (cur: T) => T} v the new value that will be updated to the store. A rough typecheck is done.
   * Could also be function that will be passed the current value of the store and will return the new value.
   */
  update(v) {
    // Rough type check.
    if (typeof v !== 'function' && typeof v !== typeof this._store) {
      throw TypeError('Typeof updated data is not the same as the initial data.');
    }
    // update the store
    this._store = typeof v === 'function' ? v(this._store) : v;
    // run the subscribed functions for each. In a real implementation it might be worth it to check if making this async would cut times on observables with many subscribers.
    this._fns.forEach(fn => fn(this._store));
  }

  /**
   *
   * @param {(data: T) => void} fn A function to run everytime the store is updated.
   */
  subscribe(fn) {
    fn(this._store);
    const index = this._fns.length;
    this._fns.push(fn);
    return () => {
      this._fns.splice(index, 1);
    };
  }

  /**
   * @description This function is only included as it allows for some quick moment-in-time debugging and has some
   * use cases
   * @returns {T}
   */
  get() {
    return this._store;
  }
}

This effectively creates a class that takes an initial value for the store, and whenever someone updates the value using the ObservableStore.prototype.update function, any listener functions are run. Note that these listeners could be functions that tie into anything, anywhere. There's nothing stopping you from subscribing to the store with a function that simply counts how many things there are. Absolutely nothing!

Most of the changes here are for the fact that the Store + Subscription now deal with most of the rendering. The rest is reworking the add/remove/toggle functions to deal with the todos store.

All of the code I think is fairly well documented, but please give drop a comment if you think I could expand upon something.

The next branch will be "the big rewrite" -- it will be the move to TypeScript and creating a very rough React-like Component. The WIP/version-2.0 branch on the repo is there and visible if you want to check it out. It will be removed once I finalize the items and iron out some bugs. I'll be honest, I haven't been working on it for awhile now due to my day job 😅.

A(nother) todo: Version 1.1

Jim Burbridge — Sat, 06 Mar 2021 23:43:36 +0000

Note This post refers to this branch

Our initial version of the project works, but things are kind of ugly.

For one thing, the entirety of the application lives inside the main.js file, and while that may not be an issue now, when the app is relatively simple, it's going to end up being a nightmare later on down the line as we add more and more features. I've kept a good summary in the README.md, but I'll copy/paste it over so we can talk about what is going on.

This branch is meant to be "I've been working in this project for awhile now, and I would like to refactor it to do some things differently."

The things that are different here

The application now does not all live inside the main.js file. Instead all of the functionality has been put into it's own files, with the main.js file simply serving as the aggregator of those events.

The renderer and the store have been largely separated. The render function here is what would be called a "Pure" function -- it keeps no track of state and will render the todos based solely off their values into the DOM.

Largely there are no direct interactions with the todo variable outside of the todo.store.js file with 1 exception. I could imagine that a slightly more knowledgeable engineer would want to persist information between browser refreshes, and as such takes advantage of the localStorage. However, trying to pull this data from storage and use our todos store API was likely a bit more complex. I imagine someone having had a bit of time to fiddle around with adding the items in a loop, but "this way was faster and just worked" is definitely something I could see myself in my earlier years saying.

However, this definitely has some downsides. The largest thing is that since we are no longer doing this all in the main.js file there are multiple places where we need to call document.querySelector('#todo-list-container'), which even for a relatively small app was rather annoying to write.

The question then is: how do we make it so that we only have to call the query selector once? There are a few ways, if you are starting off with Javascript and ESM think of a few and test them out.

Beyond that, I think a lot of developers after looking at this code will say something like "I just feel like there should be a way to get the rendering function to run when the data updates... there has to be some way to do that, right?"

Also at this point many people are probably feeling the itch of wanting to make the UI a bit prettier, with a navbar and things...

So let's look at what our src/ directory looks like now

Well, there's definitely more files!

Notice that each one of the files is a bit more specific. There are two files that start with todos, but one very clearly says it is the "store"(todos.store.js) while the other is the "render" (todos.render.js). The store now handles actions related to the actual array of todos. This means adding, removing, and marking todos as done is all stored in one logical place.

// todos.store.js
import renderTodos, { itemCache } from './todos.render';

/** @type {import('./todos.render').todo[]} */
const todos = [];
// Get an item from local storage
const stored = localStorage.getItem('todos__visited');

// if we do not have a value from our localStorage, add an example to the array.
if (!stored) {
  todos.push({
    title: 'Example todo',
    done: false,
    description: 'Extra details you may want the user to know.'
  });
  // make sure to set the storage so that other people do not see it again.
  localStorage.setItem('todos__visited', 'true');
}

export default todos;
/**
 * 
 * @param {string} title
 * @param {stirng} description
 * @returns {boolean} true if added / false if not.
 */
export function addTodo(title, description = null) {
  try {
    todos.push({ title, description: description || '', done: false });
    // render tick
    renderTodos(document.querySelector('#todo-list-container'), todos);
    return true;
  } catch (e) {
    return false;
  }

}

/**
 * 
 * @param {number} todo the index of the todo
 * @returns {-1 | 0 | 1} 1 for success, 0 for failure, -1 if the item could not be found. Helpful for debugging and not much else.
 */
export function removeTodo(todo) {
  // if we do not have this todo, don't try anything further
  if (!todos[todo]) return -1;
  // try to do this
  try {
    (itemCache.get(todos[todo]) || []).forEach(el => el && el.remove && el.remove());
    todos.splice(todo, 1);
    renderTodos(document.querySelector('#todo-list-container'), todos);
    return 1;
  } catch (e) {
    return 0;
  }
  // re-render
}
/**
 * 
 * @param {number} index 
 * @returns {boolean} True if toggled, false if there was an error.
 */
export function toggleTodo(index) {
  if (!todos[index]) return false;
  todos[index].done = !todos[index].done;
  renderTodos(document.querySelector('#todo-list-container'), todos);
}

The .render. file focuses solely on taking the data and rendering it out to the provided <dl> element.

Other than that, there isn't really a whole lot different about this branch. It was just meant to serve as a logical thing, going from the "but it works!" to the "well, now things are a bit sectioned out and we've separated out concerns."

// todos.render.js
import styles from './styles.module.css';
/**
 * @typedef todo
 * @property {string} title
 * @property {boolean} done
 * @property {string} description
 */

/** @type {Map<todo, [HTMLElement, HTMLElement]} */
export const itemCache = new Map();

/**
 * @param {HTMLDListElement} todo
 * @param {todo[]} todos 
 * @returns {void} 
 */
export default function renderTodos(todo, todos) {
  const els = todos.flatMap((todo, index) => {
    // either we can grab this item from the cache OR we create a new one.
    const [dt, dd] = itemCache.get(todo) || [document.createElement('dt'), document.createElement('dd')];
    if (!itemCache.has(todo)) {
      // set the innerHTML, along with creating the delete span.
      const span = document.createElement('span');
      // Very generic close button
      span.innerHTML = '&times;'
      span.setAttribute('role', 'delete');
      dt.append(
        document.createTextNode(todo.title),
        span
      );

      // Add necessary classes.
      dt.classList.add(styles['todo-list-item']);
      dt.classList.toggle(styles['todo-list-complete'], todo.done);

      //update description element if we have a description
      if (todo.description) {
        dd.innerHTML = todo.description;
      }
      itemCache.set(todo, [dt, dd]);
    }

    dt.dataset.key = dd.dataset.key = index;
    dt.classList.toggle(styles['todo-list-complete'], todo.done);

    return [dt, dd];
  });
  // store the data so that it persists between sessions.
  localStorage.setItem('todos__data', JSON.stringify(todos));
  // append the items to the list.
  todo.append(...els);
}

Please do view the gitlab repository. I am working on getting a live preview of the "app" up and going but the workflow here is a bit weird.

A(nother) Todo List: The Mainline Branch

Jim Burbridge — Sun, 10 Jan 2021 06:38:37 +0000

Note This article refers to this branch

The Code

The mainline branch is pretty straight forward: it is a Node package that has a source directory, a static directory, a gitignore file, our README.md, the requisite package.json file, our pnpm lock file, and our Snowpack config file.

The source directory has only two files, main.js and styles.module.css.

the static directory also has just two files, index.html and styles.main.css.

Let's look at each of those in a bit more depth; we'll save the main.js file for last as it's arguably the biggest file.

// snowpack.config.js
// Snowpack Configuration File
// See all supported options: https://www.snowpack.dev/#configuration

/** @type {import("snowpack").SnowpackUserConfig } */
module.exports = {
  mount: {
    static: '/',
    src: '/_dist_'
  },
  // plugins: [],
  // installOptions: {},
  devOptions: {
    fallback: 'index.html'
  },
  // buildOptions: {},
};

The Snowpack config is pretty straight forward, if you know how to read Snowpack configs. The mount object takes key-value pairs, with the key being the directory on your file system and the value is where it will be mounted to in the Snowpack dev server. Notice static mounts to /, so you can directly access our items in the static folder. The src directory mounts to /_dist_ meaning any files we include have to be relative to that base.

<!DOCTYPE html>
<html lang="en">

<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Todo List</title>
  <link rel="stylesheet" href="/styles.main.css">
</head>

<body>
  <h2>Todos</h2>
  <form id="todo-form">
    <input class="block" type="text" id="add-input" placeholder="Add a todo">
    <input class="block" type="text" id="description-input" placeholder="Add extra details">
    <button type="submit">Submit</button>
  </form>
  <dl id="todo-list-container"></dl>
  <script type="module" src="/_dist_/main.js"></script>
</body>

</html>

Pretty standard HTML file, right? The things to notice are the <link> and <script> tags I have. The link is pulling the styles from /styles.main.css, because the static directory was mounted to the root of our development server.

/* styles.main.css */
body {
  font-family: 'Segoe UI', Tahoma, Geneva, Verdana, sans-serif;
}

input[type="text"] {
  padding: 4px 8px;
  border-radius: 2px;
  border: 1px solid lightgray;
}
input[type="text"]:focus {
  outline: none;
  border: 1px solid gray;
}
input.block + input.block {
  margin-top: 4px;
}

.block {
  display: block;
}

.block + .block {
  margin-top: 2;
}

It's some pretty straight forward CSS, just to modify the elements not created by Javascript.

In the src directory first we'll talk about the styles.module.css file:

/* styles.module.css */
dd {
  margin-left: 0;
}
dt {
  font-weight: 600;
}
.todo-list-item {
  font-size: 1em;
  color: #333;
  font-family: sans-serif;
}
.todo-list-item span[role="delete"] {
  margin-left: 5px;
  color: pink;
}
span[role="delete"]:hover {
  color: red;
}
.todo-list-item.todo-list-complete,
.todo-list-item.todo-list-complete + dd {
  text-decoration: line-through;
  color: #989898;
}

There isn't anything spectacular here because honestly the UI isn't spectacular; it is functional, which is where a lot of people start ("make it work, then make it pretty"). As a base style we are removing the left margin from our <dd> tags, and setting our dt tag to be sort-of bold. We add some margin to our delete indicator, and we add some styles to visually differentiate completed vs. in progress todos.

Now, I would post the entirety of the main.js file, but it's 137 lines, and honestly in one go that would be too much. So, let's look at it a few lines at a time so that we can discuss what is occurring.

// main.js, lines 1 thru 28
import styles from './styles.module.css';
/**
 * @typedef todo
 * @property {string} title
 * @property {boolean} done
 * @property {string} description
 */

/**
 * @type {todo[]}
 */
const todos = [
  {
    title: 'Example Todo, no details',
    done: false,
    description: ''
  },
  {
    title: 'Example todo, with details',
    done: false,
    description: 'Many details'
  },
  {
    title: 'Completed Todo',
    done: true,
    description: 'with details'
  }
];

Alright, so if you are brand new you'll likely notice something weird almost immediately. There's this long comment with weird notations such as "@typedef" and "@property." It's a notation system called JSDoc and when you are using raw JS it's very helpful if you have a code editor (or a plugin) that uses it to help give you information about the code in question.

That long comment is just me declaring a type that I will use throughout the rest of the code in this file called "todo." A todo will have 3 properties: title, description, and done. A todo's title and description are strings, and "done" is boolean (true/false).

With that out of the way let's talk about the actual Javascript seen here.

Line 1 is importing the styles from our CSS module. That's all it does so far.

the line that starts with const todos ... is just assigning an array of todos with some initial data. Remember, the point of this branch is to reflect the workstate of "I got this done in a hurry and it works." Some todos are done, some are not.

Now let's talk about the next bit of code.

/** @type {Map<todo, Element | Element[]} */
const itemCache = new Map();

This is utilizing our todo type that we defined previously in that big comment from the first section we talked about. The notation here is a bit weird, especially if you've never worked with a language that uses generics. The basics of it is that the Map object in JS takes one type to use as a key, and stores another type. the line Map<todo, Element | Element[]> in words says "We have a Map, using the type 'todo' as the key, which will store either a single Element object or an array of Element objects."

Now, I'm going to introduce this next bit of code out of order, just because it is needed to make sense of some of the event listeners we have setup. This code is the function that actually renders our todos, and it starts on line 102 and ends on line 137. The JSDoc dictates that the function has two parameters, the first is an HTMLDListElement and the second is an array of todo elements. It also handedly notes that this function doesn't return anything -- it just runs the code inside of it.

/**
 * @param {HTMLDListElement} todo
 * @param {todo[]} todos 
 * @returns {void} 
 */
function renderTodos(todo, todos) {
  const els = todos.flatMap((todo, index) => {
    // either we can grab this item from the cache OR we create a new one.
    const [dt, dd] = itemCache.get(todo) || [document.createElement('dt'), document.createElement('dd')];
    if (!itemCache.has(todo)) {
      // set the innerHTML, along with creating the delete span.
      const span = document.createElement('span');
      span.innerHTML = '&times;'
      span.setAttribute('role', 'delete');
      dt.append(
        document.createTextNode(todo.title),
        span
      );

      // Add necessary classes.
      dt.classList.add(styles['todo-list-item']);
      dt.classList.toggle(styles['todo-list-complete'], todo.done);

      //update description element if we have a description
      if (todo.description) {
        dd.innerHTML = todo.description;
      }
      itemCache.set(todo, [dt, dd]);
    }
    dt.dataset.key = dd.dataset.key = index;
    dt.classList.toggle(styles['todo-list-complete'], todo.done);
    return [dt, dd];
  });
  todo.append(...els);
}

I think the easiest way to show what this does is to show what HTML results from it. Assume you call the following code

renderTodos(document.querySelector('#someDLElement'), [
  { title: 'Hello DevTo!', done: false, description: 'Remember to hit the heart button!'}
]);

... and subsequently check the HTML in your browser, you'd get this:

<dl id="someDLElement">
  <dt class="_todo-list-item_8dbky_7" data-key="0">Hello DevTo!<span role="delete">×</span></dt>
  <dd data-key="0">Remember to his the heart button!</dd>
</dl>

So, some notes about this:

It creates a <dt> element, and a text node for the actual text of the given todo.
Inside the <dt> element there is a <span> element that has a role attribute on it, signifying that it deletes the current element.
it adds in data-key attributes equal to the current todo's index in the todos array on both the <dt> and matching <dd> tag.

These are important things to remember going forward, as the remaining portion of the "app" will assume this HTML structure when calling for events.

The next bit of code is quite long so I will attempt to break it up.

window.addEventListener('DOMContentLoaded', () => {
  const todoList = document.querySelector('#todo-list-container');
  // Whole mess of stuff here.
});

This function wraps the rest of the code in an event listener. the "DOMContentLoaded" event will fire after the DOM has finished parsing and you can call things like document.getElementById() without worrying.

The next thing we are doing is querying the document in search of an element that has an id of "todo-list-container", which if we look back at our HTML is a <dl> element that will hold our todos.

Now we get onto the meat of the project. The first up is going to be a lot to take in all at once, but I think it's better that we talk about it as one item, and not in parts.

todoList.addEventListener('click', e => {
    const { target } = e;
    // if our target matches a delete element
    if (target.matches('span[role="delete"]')) {
      e.stopPropagation();
      // grab the key
      const key = target.parentNode.dataset.key;
      // grab the element
      const todo = todos[key];
      // grab the elements from our cahce
      const els = itemCache.get(todo);
      // sanity check
      if (els) {
        // for each element associated with this todo, delete it.
        els.forEach(el => el && el.remove && el.remove());
        // remove the todo from our cache
        itemCache.delete(todo);
        // remove the todo from the array
        todos.splice(key, 1);
        // re-render, mostly to fix key-indexes
        renderTodos(todoList, todos);
      }
    }

    // if our target matches just the regular dt element
    if (target.matches('dt.' + styles['todo-list-item'])) {
      e.stopPropagation();
      // get the key
      const key = target.dataset.key;
      // if the todos does not have this key, stop execution.
      if (!todos[key]) return;
      // invert the value
      todos[key].done = !todos[key].done;
      // re-render
      renderTodos(todoList, todos);
    }
  });

This event listener is added on to our todoList, since the child elements will come/go quite frequently adding an event onto them doesn't particularly make a lot of sense. Instead, we add the events onto the container, which will not go away. Here we have two things to check

Was the delete span that we created clicked?
Was the actual <dt> element clicked?

The first scenario is handled by the first if() statement, which I think is commented quite well, but I will go through the steps after we go into the if() statement.

The first thing we do is stop the propagation of this click. In a real application with pure JS we have no idea what could be listening on click in the ancestor elements, so we stop the propagation upwards.

Next is that we grab a key out of the parent node's dataset. Remember, in this scenario the item being clicked is the <span role="delete"> element, and not the actual <dt> element. The <span> element doesn't have the data-key property on it, so we look for the parent instead. If the todos array does not have an element at that index, we stop execution. Otherwise, we grab the corresponding elements from our cache variable, remove each of them, delete the key from our cache, remove the todo from our array (using .splice()), and finally re-render the todos in the todos container.

The next if() block is for toggling the "done" status of the clicked todo. Like the first one, it stops the propagation of the event; then we grab the key from the dataset. The same check is done to make sure we have the given key value in our todos, and then we toggle it to the opposite of whatever the current state is (i.e. if the current state is false, then we toggle it to true and vice versa). We then re-render the list.

The next section deals with handling the submission of new todos through the form on the HTML page.

// main.js, lines 74 to 95
// add an event handler to the form to prevent default stuff.
  document.querySelector('#todo-form')
    .addEventListener('submit', function (e) {
      // prevent the default
      e.preventDefault();
      // get the elements from this form.
      const { "add-input": addInput, "description-input": descriptionInput } = this.elements;
      // break execution if we do not have strings.
      if (addInput.value.trim().length === 0 || descriptionInput.value.trim().length === 0) return;
      // push the results
      todos.unshift({
        title: addInput.value,
        done: false,
        description: descriptionInput.value
      });

      // Reset the values
      addInput.value = descriptionInput.value = '';

      // Render the todos
      renderTodos(todoList, todos);
    });

The Discussion

Q: Why didn't you use TypeScript?
A: I imagine someone coming into Javascript not particularly feeling the need of TypeScript -- If people would like I can create a TypeScript branch of each version, but unless someone asks I'm not likely to do so until a larger version difference.

Now, as I said in the original post, this is meant to be an exercise to show people why things like React have gotten popular. While this is definitely not the best way to setup an app, it's definitely a way that many people will do for their first few (speaking from past experience here).

The next branch we will talk about is the Version 1.1 branch, which changes the structure a bit so that we don't need one large file. Keep an eye out for that post!

Feel free to comment any questions / clarifications!

A(nother) Todo List

Jim Burbridge — Sun, 27 Dec 2020 23:09:55 +0000

I've been working on the web since 2001, when I first got in to HTML, CSS, and Javascript. The internet of 2001 is not the same internet that we have today, and that is in no small part to the updates of all three of the web's technologies. However, with this growth has come some changes in how people actually develop for the web: frameworks.

When I started there was nothing fancy-- If you wanted to do things in Javascript you needed to learn how to use Javascript and the Document Object Model (DOM). This was ... well quite honestly it was awful, and honestly it's still not great -- but it is doable.

Normally, I don't tend to think about this anymore. I trust that the teams responsible for the frameworks I use put much more time in caring how they deal with the DOM on a webpage than I ever will. However, I am active in places like StackOverflow and Quora. Recently, on Quora I saw a question that I've seen many times, and that I've ignored just as many times:

Why should I learn (React / Angular / Vue / another framework or library)?

The other day when I read the first thing I said internally was "because most people don't want to have to deal with the DOM themselves." While that statement might be broadly correct, it occurs to me that I know plenty of people who can work in React or Vue or Angular, but who would absolutely have no idea how to build the same functionality in a framework-less world.

I had started writing a response when an idea hit me: "Instead of just telling them about how dealing with the DOM is annoying, just make a quick app that doesn't use anything outside of pure JS."

So, I did. I call the project "Vanilla Todo" and in it I have attempted to imagine myself as someone who is a recent entry into the world of web development, and that they are somehow unaware of the many frameworks and libraries that now live on the front end.

Each branch of Vanilla Todo will progress through stages that I myself can remember hitting when I was new to the web. The first branch is "version 1" or "I put this together in a craze and it works!". Each branch from there will modify the repository, both in code structure and in implementation, until such time that I (hope) a new user will understand why people have flocked to front-end frameworks.

The repository is still in it's earlier stages, with two branches being overall done, and I am working on others as we speak.

The link for the repository is gitlab.com/jhechtf/vanilla-todo.

I will be making posts to talk about each branch in a bit more detail, and possible things that people could do to try out different ways of dealing with the DOM.

[Request For Post] Your solution for auto publishing NPM packages?

Jim Burbridge — Sat, 14 Mar 2020 00:14:10 +0000

Backstory

I recently created an NPM module that while it's not hugely popular, has more downloads than I thought it would. I have a CI/CD setup on my gitlab to lint, test, generate a changelog, and publish.

Three of those jobs work. Take a guess at which 3? That's right, linting, testing, and changelog-ing all work.

All of the places I've found mention of CI/CD with Gitlab and NPM boils down to the following:

Either run npm config set registry //registry.npmjs.org/:_authToken ${NPM_TOKEN} and then running npm publish OR
doing basically the same thing, but instead adding the //registry.npmjs.org/:_authToken=${NPM_TOKEN} to a local .npmrc file.

I've tried both of these on my WSL Ubuntu install. Neither has worked.

I found this Stack Overflow post, and in digging through some links found someone who recommended setting strict-ssl to false. I can't say I'm comfortable with that.

How do YOU do it?

Most of the time my CI/CD stuff pertains to servers, not necessarily NPM modules, so I'm a little out of flavor here. I figure there has to be some way to do this without turning off SSL? I'm holding off on updating my pipeline in the hopes that maybe there's something I missed in all my searching.

Opinion: PUT should be the HTTP method for new data

Jim Burbridge — Wed, 11 Mar 2020 21:33:59 +0000

I said what I said, and I mean every word of it.

Rewind

For those a little confused, let's back up.

REST (REpresentation State Transfer) APIs are still very common, and honestly I don't have an issue with them for most projects. REST APIs work by using HTTP verbs to denote the purpose of a request, i.e. a GET request on a given endpoint (say "comments") means that the user is trying to get a list of (or perhaps a specific) comment value(s). DELETE along with an identifier of some type does just what you think it would: removes the resource given by the identifier. The last two main HTTP methods utilized with REST are POST and PUT, and this is where I seem to break with most API designers / REST routing libraries.

Schism

The last two, in English, are very close to one another due to some extra uses of the word "post", as in to "post a job listing" (i.e. put up, create). For a long time many back-end languages didn't have good support for requests outside of GET or POST (for reasons I honestly don't know), so POST sort of fell as the default for anything that needed more security in sending data (i.e. not transmissible through the URL).

With the growth of AJAX (i.e. XMLHttpRequests) REST APIs became the flavor-of-the-month and with it developers should have thought about our default to using POST requests for creating data / records. Not many did, unfortunately, and many places that use REST APIs have, in my opinion, mixed up PUT and POST.

My Argument

I read an article some years ago (if I can find it I will link it, but so far have been unsuccessful) stating that the four big verbs (GET,DELETE,PUT, POST) are really the only verbs you'd need for a large majority of use cases. In that post the author made a point: POST requests are (in his opinion) for resources that are being modified, not created, because they are POST creation. To create new values, you would PUT data to the server (database).

I think PUT has always made more sense as the verb for adding new data, but please give me any reasons you may have for thinking that POST is the preferred method.

Automating VSCode Extension Publishing and Changelog Generation with Gitlab-CI

Jim Burbridge — Mon, 26 Aug 2019 05:26:28 +0000

When I build my first real VSCode Extension I released it by hand every time. This also meant that I was making up the CHANGELOG every time as well. I had roughly looked into what I would need to do in order to make the changelog / marketplace publishing automated. I never got around to doing this, since it looked to involve more time than I had, and since it was "only one extension, I'll likely not update it that often."

After creating Git Angular I decided I would use it as a test bed for two things: fiddling around with Standard Version and finally cementing a way to publish extensions from Gitlab CI.

NOTES:

Standard Version uses the Angular-style commits to create the changelog. This means that if you are coming from a different commit style, such as Emoji Commit, or just "whatever information seems relevant in the commit", then that part is going to be difficult. There are other presets, but I've never used them so I don't know much about them or how they are. I'm looking into creating one for the Git Emoji commit style, but don't hold your breath on when that will be available.

Also, if you are like me and you look for an "elegant"-ish solution, this won't be it. This is what I came to terms that I would have to do in order to get it (more or less) automated, and I figure it is worth documenting the process for some other soul to see later on.

Tl;DR:

Make sure you have a Personal Access Token (PAT) from both Gitlab (created under User Settings > Access Tokens) and Azure Devops (instructions linked below for this step). Your Gitlab PAT should have write repository access. I would recommend maybe making these expire every month or so just in case it somehow gets exposed. Sure, you have to remember to remake the token in a month, but the alternative is someone hijacking everything.
Add those two tokens into the Settings > CI/CD > Variables. I named the Azure Token PAT and the Gitlab PAT to GL_PAT. You can name them whatever, but remember what you name them later on.
- Make sure that the "publisher" value in your package.json is not taken, otherwise your deploys will have issues.
Copy the .gitlab-ci.yml file from the section below, editing the repository URL.

First Thing: make an extension.

I obviously have Git Angular that I can use, but if you have yet to make an extension then you should use the guide. Basically you are going to want to install yo and generator-code. You then run yo code and follow the prompt. If you don't exactly know what sort of voodoo you want this extension to be, that's fine. Just make sure you are following the commit pattern mentioned by the Standard Version page I linked above. It makes most of your commits look something like feat(settings): added in settings page or fix(submodule): fixed logic error in submodule that would cause errors.

Second Thing: Prep a Gitlab Repo

Go over to your Gitlab and make a new blank repo for it. Go into your extension directory and make sure you run

# only run this command if you didn't already initiate the folder as a git repo
git init 
# Change "YOUR-USERNAME" and "YOUR-REPO" to their respective values
git remote add https://gitlab.com/YOUR-USERNAME/YOUR-REPO.git origin

For my Git Angular extension, this would be

git remote add https://gitlab.com/jhechtf/git-angular.git origin

VSCode Marketplace Access Token

The instructions for creating a PAT that you can use to publish to the VSCode Marketplace is a bit more involved than I would care to cover in-depth here. Please check this guide. Make sure you copy/paste that TEMPORARILY somewhere on your computer. I recommend you only use this token for a single VSCode extension so that if, on the off change, this token gets exposed you can view activity from your account and revoke only the necessary token.

Gitlab Personal Access Token

You can make a new Personal Access token by logging into Gitlab, and then clicking on your profile picture on the right side. From the dropdown menu click "Settings."

Make sure to name your Personal Access Token something you can distinguish quickly, and I would recommend setting an expiration date within about a month. You need to make sure your PAT has write access to your repository, or this will not work.

.gitlab-ci.yml

If you are unsure the structure of the .gitlab-ci.yml file, please check here for a rough version. I've commented my gitlab-ci file below, but let's talk about what needs to happen exactly in order for us to be able to push the files. The basics of it are

make sure git is configured since standard-version auto commits its changes to package.json and CHANGELOG.md Without the two git configure lines the job will fail with an error since git won't let an unknown person make a commit.
I use yarn, but the equivalent npm command would npm run release. This runs standard-version from my package.json
Gitlab CI checks out a commit, not a branch. Therefore the changes committed in the release script will not be saved. We must therefore merge those changes back into the master branch.
Merge the new commit into the master branch, and using our PAT push the code up.

The very basic Gitlab CI file that I made looks like this:

# Smaller image, faster to download than the regular node:12 image.
image: node:12-alpine
# Stages list. I will eventually have more stages, but this was a proof-of-concept more than anything
stages:
  - test
  - deploy
# Before any job, add the vsce globally, and install our node_modules.
before_script:
  - yarn global add vsce
  - yarn

Deploy:
  script:
    # update our distro and add git.
    - apk update && apk add git
    # configure our newly-installed git to use our user name and email
    - git config user.email $GITLAB_USER_EMAIL
    - git config user.name $GITLAB_USER_NAME
    # I added a release task which simply runs the standard-version library.
    - yarn release
    # Gitlab checks out the commit, not the branch, putting any committed changes into a detatched-head scenario.
    # this gets the commit SHA and stores it in the $CUR_HEAD variable.
    - CUR_HEAD=$(git rev-parse HEAD)
    # checkout master and merge in our detatched head
    - git checkout master && git merge $CUR_HEAD
    # GITLAB_USER_LOGIN is your gitlab user name, and GL_PAT will be the Gitlab Personal Access Token you created earlier. We are pushing our current HEAD to the master branch
    # on the quoted repo URL
    - git push --follow-tags "https://${GITLAB_USER_LOGIN}:${GL_PAT}@gitlab.com/jhechtf/git-angular.git" HEAD:master
    # finally, publish our extension by passing in our $PAT token.
    - vsce publish -p $PAT

  only:
    - master
  when: manual

Other considerations

I have modified my repository so that only I may push to the master branch (developers can merge branches, but only I may push to it directly).

the when: manual makes it so that I must go in and start the Deploy job manually, so that things like the release tags aren't run. I am likely to keep this, as one push could theoretically spawn a million different patch pushes (which I don't want).

Closing Notes

I am open to hearing about how other people have setup their own Extension publishing pipeline, so if you have a setup please let me know in the comments. I also wish that the Azure Devops dashboard would allow me to restrict the PATs to a specific project, but unfortunately that doesn't seem possible.

Let me know if you have any clarifications you'd like me to make!

Introducing Git Angular: a VSCode extension for Angular-style commits

Jim Burbridge — Sun, 18 Aug 2019 07:09:25 +0000

Why does this extension exist?

A lot of the projects I work on have some variety of pattern you need to follow in order contribute. This largely is because the commit messages will become part of the release notes and/or changelog later on.

My previous company had a very rough process for Git messages, and most of my personal projects tend to have commits designed for "Future Jim" to read. Because of that, I personally adopted the Git-Emoji commit style, as I enjoy a little bit of spice in my commits.

My current company, however, is very particular about their commit structure. They use a version of Angular's Commit Message Guidelines. The thing is I am having just the hardest time with it, so I wrote this little extension to help myself, and I figured I would share it with other people.

What does it do?

One thing, fairly simply: helps you build the starting point for an Angular-style commit.

... OK?

I know, that doesn't sound so awesome, and if I'm honest this extension isn't meant to be something like GitLens, it's just meant to be a simple helper that plugs in to VSCode's default Git extension.

The biggest thing about Git Angular is that it is configurable, either globally or via workspaces. This was done because not every person who is using the Angular commit style will be using Angular's commit style (much like my current company). You and your team could be using different types or scopes, and Git Angular allows for that.

How do I use it?

Unfortunately, VSCode has about a million extensions that have "Angular" in the title, so it's best to follow this link. Otherwise, the easiset way I found to find it without a lot of fuss or muss is searching for "Git Angular" (quotes included) into the VSCode Extension search box.

It contributes a single command, gitAngular.commit, that you can bind to a keybinding or use from the command palette. I personally bind this to ctrl+shift+c

Wrapping up

Let me know if you think there's something missing from the extension that many Angular-style commit users would enjoy to have.