DEV Community: Sam Beckham

Experimenting with AI

Sam Beckham — Fri, 02 Jun 2023 00:00:00 +0000

The world has gone crazy for AI. AI discussions are dominating keynotes, product releases, and Twitter threads. But what does building with AI actually look like? I wanted to learn, so I started small and spent a day experimenting.

A simple AI experiment

I needed an experiment that was small enough to be shippable in a day, but large enough to challenge me. I decided to update the recommendation feature on this blog. The previous algorithm suggested the three latest articles. It did the job, but wasn't too smart. It was the perfect target for my AI experiments. It was simple to understand, but would a deeper understanding of AI to get it done.

Getting familiar with AI

I wanted to create a some POCs (proofs of concept) to help me learn. The first step was to get the OpenAI API running in my project. I kept it simple and asked it to, "tell me a joke". After following the getting started guide (and some configuration) I got it a response.

"Q: What did the fish say when it hit the wall?

A: Dam!"

–'text-davinci-003'

By doing this, I learned that requests are made of tokens. Each token is a snippet of text, usually the length of a word. There's a limit on the number of tokens you can send and receive in each API call. The longer the prompt, the less room for the response. If you set this limit too low, or make the prompt too big, you get incomplete responses.

Proving the Concept

By updating the prompt from, "Tell me a joke", I could turn it into something useful. I passed a list of article titles and asked for the three most related ones. After some finessing, I landed on the following prompt:

const prompt = ` Given the title of an article is "${article_title}". Which three articles from the following array of article titles are the most related?

${JSON.stringify(article_titles)}.

Return your answer in the following JSON format: { "recommendations": ["one", "two", "three"] }`

I learned that writing prompts like BDD tests is quite effective. The AI was more likely to understand the question if I laid it out clearly.

To make the result parsable, it was crucial to provide a format. Asking it to, "return the answer in JSON" was not enough. I needed to provide an example response to get a more reliable result. More reliable, but not completely reliable.

Here's what I got when asking for related articles for "Increase You Focus With Pomodoro":

{
  "recommendations": [
    "increase your focus with pomodoro"
    "automate your meeting agendas",
    "find what makes you productive"
  ]
}

Though it was obvious in hindsight, the most related article was the article itself. This was easy to fix by filtering it out of the list before passing it up. The POC worked well, but there were a few problems I wanted to address:

1. It wasn't reliable

Since this was chat-based, the outcome wasn't reliable. It worked 80% of the time, but often gave a poor response. It had a habit of adding extra text around the JSON, making it harder to parse. Switching from the text-davinci-003 model to the more chat-focused gpt-3.5-turbo model helped, but didn't completely fix it. I would need to write a more robust response parser if I were to move this from POC to production-ready code.

2. The recommendations weren't great

The recommendations were okay, but they were a bit naive. Since I was only sending the titles of the articles, we weren't giving the AI much data to work with. For example: "Running a Conference" would recommend, "Running the JamStack on GitLab", instead of the more obvious, "Starting a Meetup". To get better results, I'd need to give the AI more data.

3. There were too many API calls

The OpenAI API isn't free. Up to this point I had only spent a few cents, but at scale this could get expensive. Running this for every article—and passing more data per article—would increase costs. I needed to reduce and cache these calls wherever possible.

Using OpenAI Embeddings

After a bit more research into the issues above, I discovered embeddings. Instead of writing a prompt for every article, I could send them all to the embedding endpoint. This would return a multi-dimensional graph with all the articles plotted on it. The closer the points are on the graph, the more related they are.

To understand how embeddings work, we need to simplify what they're doing.

Imagine all the articles plotted on a standard 2D chart. On each axis is a different topic. There's "leadership" on one and "engineering" on another. We can plot all the articles on this chart based on how much the content within them relates to each topic. When we look at this chart, we can see the ones that are closer together are more related to each other. The ones that are further apart, will have less in common.

Comparing two topics doesn't give us much. To get more accurate information, we can add a third axis. This one measures the relation to "productivity". Since the axis needs to be orthogonal to the other two, we need to jump into the third dimension to visualize it.

We can still get the distance between points, but now we're comparing across three dimensions. OpenAI uses thousands of dimensions to create embeddings, but the concept is the same. The closer two nodes are, the more related they are.

This approach solves all our issues. We get more accurate, reliable, recommendations with one API call. Because of this, we can afford to send more data to make the recommendations better. Since this is no-longer chat based, the response is a structured data format. The embedding data may be different if we ran it again, but the data structure would be the same.

Sending the right data to the AI

We can send more data to the API, but which data do we send? We could send the whole article, but we would soon hit the token limit. Luckily, ChatGPT is great at summarizing and categorizing text. We can use this to our advantage and ask it to generate tags for all our articles. By sending tags instead of the full article, we send less data but still get the point of the article across. Because I was only doing this once, I used the ChatGPT app. This came with the added benefit of using the more powerful GPT4 engine that isn't available to us on the API.

Here's the prompt I wrote:

Given the following markdown article, please suggest five tags formatted as yaml:

{ARTICLE_CONTENT}

Notice I'm using the BDD test style again. I didn't provide an example response, so the results weren't reliable. Since this was using the ChatGPT app though, it didn't matter too much. It had the context of the previous chat messages so I could refine the result. When it returned the results in the wrong format, I would ask it to, "reformat the response as yaml" and it fixed it up. I could also refine the suggestions by saying, "swap {TAG_NAME} for another suggestion".

Here were the suggestions for this article:

- AI experimentation
- recommendation feature
- OpenAI API
- embeddings
- article tagging

It took a while to generate all the tags, but it was a one-time operation. Once I had all the tags, I wrote a script that fetched all the articles and extracted their tags. I then sent an array of these to the embedding endpoint and got all the data back to run comparisons against later.

{
  input: [
    "Experimenting with AI: AI experimentation, recommendation feature, OpenAI API, embeddings, article tagging",
    "Increase your focus with pomodoro: Productivity, Time Management, Focus Technique, Pomodoro Technique, Distraction Management",
    "Running a Conference: conference, event organization, sponsorship, diversity fund, speaker payment",
    //… 
  ]
}

Cosine similarity formula

Our brains can't handle graphs in dimensions higher than the three we live in, but computers have no problem with it. Using the cosine similarity formula, we can get the distance between two points in any number of dimensions. Letting the compute-cosine-similarity npm package do the heavy-lifting, made computing similarity a breeze. To get the recommended articles, I loop through all the articles and calculate their similarity to the current article. Then I sort the array by similarity, remove the first result, and return the next three. This is all done against the dataset we generated previously, so it's really fast.

Takeaways

This approach solved all the issues with the first POC. It's much more reliable since we're dealing with deterministic data. There's only one API call that's made once every few weeks. Most importantly, the recommendations are much better. They're not perfect, but they're good enough.

// For "Running a Conference"
{
  "recommendations": [{
    "title": "Starting a Meetup",
    "path": "/wrote/starting-a-meetup/",
    "similarity": 0.8543
  },{
    "title": "All Meetings are Optional",
    "path": "/wrote/all-meetings-are-optional/",
    "similarity": 0.8363
  },{
    "title": "Automate Your Meeting Agendas",
    "path": "/wrote/automate-your-meeting-agendas/",
    "similarity": 0.7954
  }]
}

Recommendations are a nice feature, but the point of this was to learn more about AI. I'm an engineering manager so I don't need to be a guru, but I still need to know what I'm talking about. By going through a practical application of AI, I'm better prepared for conversations with my engineers as we dive in to AI at GitLab.

If I've made any incorrect assumptions, or could have done this better, reach out on Mastodon, or Twitter and tell me about it. I'm always happy to learn.

Owning my content again

Sam Beckham — Mon, 07 Oct 2019 20:08:27 +0000

Medium, we had fun, but you've changed. A beautiful reading experience tarnished by paywalls, advertisements, and popovers. I want my content back on my own platform.

Owning my own platform gives me freedom. Freedom to tweak the code and eek out those extra milliseconds of performance. Freedom to add whatever features I want, and remove those that I don't. But most of all, the freedom of knowing it won't ever change or disappear, unless I want it to.

It does come with a few downsides. The biggest two being discoverability and collaboration. I can write all the posts I want, but no one will see them unless they actively look for them.

With a couple of extra additions to this site, I may have solved these problems. I just had to use something old, something new, something borrowed, and something blue.

If you've got to this point and are wondering, "I thought you wanted your own platform, this is Dev.to". You're right. The original article is on my blog.

Something old

Back in the good-old-days we all had our own blogs. People were still able to discover our posts by using RSS feeds. You could subscribe to the RSS feeds of you favourite blogs and your RSS reader would collate them all. It's a bit like Podcasts. You subscribe to the stations you want to listen to. Then your podcast player displays all the new podcasts from your favourite stations. In fact, it's exactly like podcasts. Because RSS is what they use to manage this.

Unfortunately, using RSS for blogging died off a little in recent years. But as more and more people want to own their own data again, they're regaining popularity.

So, in the sprit of boosting RSS back to the top, I created a feed for this blog. This site is running on Gridsome which made it easy to add an RSS feed. All I needed to do was hook up gridsome-plugin-rss

module.exports = {
  plugins: [{
    use: "gridsome-plugin-rss",
    options: {
      contentTypeName: "SanityPost",
      latest: true,
      feedOptions: {
        title: SITE_NAME,
        feed_url: `${GRIDSOME_BASE_PATH}/rss.xml`,
        site_url: GRIDSOME_BASE_PATH
      },
      feedItemOptions: node => ({
        title: node.title,
        description: node.description,
        url: `${GRIDSOME_BASE_PATH}/wrote/${node.slug.current}`,
        date: node.publishedAt
      })
    }
  }]
};

I dropped in the default config, tweaked it to match my own site, ran yarn build to give it a test, and success! Sort of. The good news was, the feed was there and all my posts were in it. The bad news was, they were in a completely random order. After a little digging I realised they were all alphabetised on their UUIDs. A lovely order, but an entirely useless one. This was because gridsome-plugin-css sorted posts by node.date and my Sanity implementation doesn't have a date field. It's a little more granular and has _createdAt, _updatedAt, and publishedAt. The one I wanted was publishedAt, but there was no way to tell the plugin this information. Yet.

The best thing about open source is that everyone can contribute. I found a problem with the plugin and took it upon myself to fix it. A couple of changes to the codebase and I could pass in dateField: "publishedAt" which orders our posts by the correct date field. Joy!

The RSS feed is up-and-running. It's nothing fancy, but it gets the job done.

Something New

The best posts are the ones that spark a conversation. But how do we allow those discussions on a static site? I could add Disquss, or use FaaS (Functions as a Service) to let people post comments. But it's not quite what I want. Usually, I prefer using the boring solution. But this time I went for the shiny option. It's my platform, I'll do what I want.

The shiny solution here is a new standard called Webmentions. In essence, they're a list of all the places that "mentioned" your post. If you Tweet out your post on Twitter, that's a mention. If someone responds to that Tweet, that's a mention. If someone likes, or retweets that Tweet, that's a mention too. Then all you do is take that list, filter it, and render it to your site as "comments". This isn't just Twitter either. It works for other sites too, but for simplicity, I'll stick with Twitter for now.

Getting this list wasn't too hard. I followed the instructions on Max Böck's post to the letter. If you want them on your site too, I'd start there.

Once they were set up, I had to integrate them into Gridsome. Unfortunately, Max uses eleventy, so I could only use his post as guidance. There are also no Gridsome plugins for Webmentions yet, so I had to go alone on this one.

If you want to see exactly how I did it, I'd recommend looking at the Merge Request (that's what we call Pull Requests at GitLab). This whole blog is public, so you can dig in and have a proper look at the code. If you want the cliff notes, the whole thing was done in three steps:

1. Add the Webmentions feed into the Gridsome API

This is probably the most complex part. I needed to take the API provided by webmention.io and expose it on the GraphQL endpoint in Gridsome. This was done by adding the following code to gridsome.server.js

const axios = require("axios");

const API_ORIGIN = "https://webmention.io/api/mentions.jf2";
const { GRIDSOME_WEBMENTIONS_TOKEN } = process.env;

module.exports = function(api) {
  api.loadSource(async store => {
    const { data } = await axios.get(API_ORIGIN, {
      params: { token: GRIDSOME_WEBMENTIONS_TOKEN }
    });

    const mentions = store.addCollection("mentions");

    for (const item of data.children) {
      mentions.addNode(item);
    }
  });
};

2. Pull the mentions into a `PostComments.vue` component

Once the Webmentions data was available on the GraphQL endpoint, I could pull it into the project. Webmentions collates, likes, retweets, mentions, and replies. But I'm only interested in replies for now so I filtered everything else out using wm_property.

query {
  comments: allMentions (sortBy:"published" filter: { 
    wm_property: { eq: "in-reply-to" }
  }) {
    edges {
      node {
        id
        author {
          name
          photo
          url
        }
        content {
          text
        }
        published(format: "MMMM Do, YYYY")
        url
        wm_target
      }
    }
  }
}

Unfortunately, Gridsome isn't able to pass javascript variables into GraphQL queries just yet. Which means I couldn't filter the mentions by post. This query returns all the mentions for all the posts. To get around this, I requested wm_target which gave me the url to the post linked to that specific mention. All I needed to do was filter out the ones I didn't need after I loaded the mentions. Then I had a nice, clean array of "comments" that I could loop over and render as I please.

computed: {
  comments() {
    return (
      this.$static.comments &&
      this.$static.comments.edges
        .filter(comment => comment.wm_target.match(this.postSlug))
        .map(comment => comment.node)
    );
  }
}

3. Re-build the site when new comments are posted

Because the comments get baked in at build-time, new mentions won't be rendered until I re-build the site. All I had to do there was set up a new pipeline trigger and pass the webhook URL to webmention.io. Whenever I get a new mention, webmention.io calls the webhook, GitLab triggers a build, and my site is redeployed. There's a potential 10-30 minute delay, but it's a small price to pay. Besides, the conversation is happening on Twitter, I'm just re-rendering it on this site.

Something Borrowed

The RSS feed is a great first step towards discoverability, but I want to get my posts in front of a bigger audience. This is something Medium gave me for free and one of the main reasons I switched to using it. But there is another way.

Dev.to is a similar platform to Medium, but with a lot of the junk removed. If I didn't want to own my own data, this would be the platform I'd use. But just because it's not my primary platform, doesn't mean I can't borrow it when I want to. Dev.to can automatically cross-post your items to their platform. All you have to do is pass it your RSS feed. It's a good job we've just added one of those!

If you're reading this post on Dev.to, then this process worked!

Something Blue

I'll be honest, this is where the analogy falls down. How about a lovely, blue footer?

I'm just getting back into writing again. I hope to continue to add little improvements to this blog and write about them as I go. If you end out using any of these techniques on your own sites, let me know!

Running the JAMstack on GitLab

Sam Beckham — Thu, 03 Oct 2019 10:37:08 +0000

The JAMstack has piqued my interest. Not because it's fast, secure, or totally hot right now. But because it got me thinking, "We could run that on GitLab".

These thoughts cross my mind a lot. GitLab is such a versatile tool that it has endless applications. I use GitLab to run a conference, keep track of my wedding plans, and even help create GitLab. It's almost definitely a case of Maslow's Hammer where, "…everything looks like a nail". But who cares, I'm eyeing up a JAMstack shaped nail right now, with my GitLab branded hammer in hand.

What is the JAMstack?

Before we dig into what I did, let's explain what the JAMstack is. The acronym itself stands for Javascript, APIs, and Markup. Which on its own, could describe almost any website. Here's a quote from the top of https://jamstack.org/ that explains it better:

A modern architecture —

Create fast and secure sites and dynamic apps with JavaScript, APIs, and prerendered Markup, served without web servers.

The key part here is "served without web servers". JAMstack sites are static. They do all the compiling at build time, not at runtime. It's often confused with isomorphic websites built with Next, Nuxt, or similar. But the concept is entirely different. We're not rendering pages on the server, then hydrating them once they get to the frontend. We're building the pages once (at build time) then serving up those static pages at runtime. This makes for a blazing fast website with little to no server costs.

Let's do this

If you hadn't already guessed, the project I created on the JAMstack is the blog you're reading right now. It looks and behaves in much the same way that it did previously, it's just a lot faster, and easier to update.

The first thing I needed to do was pick a static site generator. I had a look at Gatsby and Eleventy, but ultimately settled on Gridsome. It's based on Vue.js and integrates with GraphQL, which is something I've been wanting to look into for a while. This seemed like the perfect excuse.

With the site generator chosen, I needed to work out where to store my data. When this site was running on Jekyll, I used markdown files stored in the repo. Whilst this worked well enough, I wanted a little more flexibility. Something that required a CMS. I chose Sanity based on a recommendation from Jamie Bradley. Sanity is a headless CMS with a GraphQL output layer, a perfect fit for my needs.

With those two chosen, I had everything I needed to get started developing locally. I moved over all my old posts to Sanity, which was a lot harder than I expected. I wish there was an easy way to convert markdown to Sanity blocks (Sanity's rich text editor) but I had to do it all manually. I guess the one upside to my low output on this blog is that there weren't too many posts to migrate.

I already had a lot of the components of my blog written in Vue from when I tried to move it over to VuePress. A Vue based static site generator that ended out being unfit for purpose. I copied these components over, tweaked them to fit, and added my GraphQL layer. Then I was good to go.

Once I was ready to deploy, I copied the example .gitlab-ci file from Gridsome's documentation and pushed the site to GitLab. This triggered the build process on GitLab's CI pipeline and built out the static site to GitLab pages. After two painless DNS additions, I had my domain hooked up to GitLab pages with automatic SSL certs.

With very little set up—which consisted more of copy/pasting than any real hard work—I had my blog up-and-running. When I pushed a change to the master branch, GitLab's CI pipeline would trigger a build, regenerate all the static files, and re-deploy my website. This was the boring solution. The smallest possible change I could make to get my blog migrated to the JAMstack with GitLab.

Iterating on the Boring Solution

The boring solution was great, but are were a few small tweaks I could do make to make the process a little nicer.

Because my content was in Sanity, GitLab wasn't aware of any changes I made to it. The content publised on the website would be the content from Sanity at the time of the most recent build. I could manually trigger the pipeline after I published a change to pull in the latest data, but I'm far too lazy for that. I needed to automate this. Thankfully, GitLab allows you to create pipeline triggers that can listen to a webhook and start a pipeline every time it's used. On the Sanity side of things, you can call that webhook every time you publish a post. Now, whenever I publish a post, it triggers the pipeline then the website is re-built and deployed. It's not as instant as a usual CMS set up but it only takes a minute or so, and it only has to happen once.

I'm also a bit of a stickler for performance. The boring solution was fast, but still fell down on a few points. I've fixed them all now and it's blazing fast. I'll save the story of how I did that for another day. To summarise, I minify, lazy-load, pre-fetch, and cache all of the things. I also added in a service worker for good measure and that sweet offline first experience.

Serverless functions

Whilst this site has no need for serverless functions (Functions as a Service, FaaS), they are a large part of the JAMstack. Static websites are great for sites with little user interaction beyond reading information. But what if your site needed to be more complex? What if you needed to allow users to log in, make purchases, or post content? This is where serverless functions come in. They're API endpoints that (when called) spin up a VM, run some code, then disappear again until they're needed next time. There are a lot of different platforms that offer this service. AWS lambda is the biggest right now, but there's also Netlify, Firebase, and a load of other providers that offer functions as a service. Including—you guessed it—GitLab.

If you want a more in-depth look at how FaaS can be used with the JAMstack, take a look at this section of, "Are you being servered" by Phil Hawksworth. Then go back to the beginning and watch the entire talk. It's a great example of what you can do with the JAMstack.

Have a go yourself

If you want to have a go at building your own JAMstack website on GitLab, I've made this project completely public. You can look at the code, clone the project yourself, and even watch my pipelines. If GitLab's not your thing, head on over to staticgen.com, pick a generator, and get your site up and running in seconds on Netlify.

Deep Copy and the Immutability Issue

Sam Beckham — Sun, 25 Feb 2018 18:08:09 +0000

In the latest episode of, "I Have No Idea What I'm Doing" I learned that everything I thought I knew about immutability in Javascript was a lie.

Okay, so I'm being dramatic. Not everything was a lie. But a fundamental part of my understanding was incorrect. After speaking to a few people about the issue, it seems this was a shared misconception.

This all stems from a subtle, yet fundamental difference in how we copy objects in javascript. Deep copying and shallow copying.

Deep copying is what we want for true immutable data. It is a copy of all the values of an object, and all the values of all the objects within it. Shallow copying—on the other hand—is a copy of all the values of an object, with references to all the objects within it. This is what tripped me up.

To understand the problem, we need to look at three ways of copying objects.

Referencing

Okay, so let's strip this all the way back. Let's create a mutable reference to an object.

const initialObject = { name: "Sam", twitter: "@samdbeckham" };
const newObject = initialObject;

This is bad for immutability because any changes to newObject reflect in initialObject like so:

newObject.twitter = "@frontendne";
console.log(initialObject.twitter); // @frontendne

In this example, newObject is a reference to initialObject. So whenever we get or set data on either of these objects it is also applied to the other object. This is useful in a lot of different ways, but not great for immutability.

Shallow copying

This is the most common form of copying data in an immutable manner. We utilise the spread operator to create a copy of initialObject. If you've used redux before, you'll have seen this inside your reducers.

const initialObject = { name: "Sam", twitter: "@samdbeckham" };
const newObject = { ...initialObject };

It's a subtle change, but the ... makes all the difference. newObject is no-longer linked to initialObject. It's now a copy of the data and an entirely new object. So if we make the same change we did earlier, we get the following result:

newObject.twitter = "@frontendne";
console.log(initialObject.twitter); // @samdbeckham
console.log(newObject.twitter); // @frontendne

Modifying the data on newObject doesn't affect initialObject anymore. We can go about our day, modifying newObject and initialObject remains clean.

But this is a shallow copy, and the immutability is only one level deep. To show this, we need an object inside our initialObject:

const initialObject = {
  name: "Sam",
  social: {
    twitter: "@samdbeckham",
    youtube: "frontendne"
  }
};
const newObject = { ...initialObject };

At first glance, this newObject looks like an immutable copy of initialObject but look what happens when we do this:

newObject.social.twitter = "@frontendne";

console.log(initialObject.social.twitter); // @frontendne

Sadly, the immutability is only skin deep. As soon as we go down another level, we're back to referencing values. If we were to open up newObject, it would look a bit like this:

const newObject = {
  name: "Sam",
  social: initialObject.social
};

We can get around this issue by shallow copying one level deeper and defining newObject like so:

const newObject = {
  ...initialObject,
  social: { ...initialObject.social }
};

This is how it's usually dealt with in redux, but it only adds one more level of immutability. If there are any other nested objects they will still be stored as references. You can see how (with certain data structures) this could get messy.

Note: Object.assign() and Object.freeze() have the same shallow copying issues as spread.

Deep Copying

Finally, we get to deep copying. Deep copying offers us true object immutability. We can change any value in an object—no matter how deeply nested it is—and it won't mutate the data we copied it from.

const initialObject = {
  name: "Sam",
  social: {
    twitter: "@samdbeckham",
    youtube: "frontendne"
  }
};
const newObject = deepCopy(initialObject);

newObject.social.twitter = "@frontendne";

console.log(initialObject.social.twitter); // @samdbeckham
console.log(newObject.social.twitter); // @frontendne

Hooray! We're immutable!

Unfortunately, Javascript doesn't have a function called deepCopy() so we've had to make our own; and it isn't pretty. There's no "nice" way to handle deep copying in Javascript. Das Surma wrote a article on deep copy which has a few good examples, here are some of the simpler ones.

JSON

This is the most concise and easy to understand method, and it looks like this:

const deepCopy = object => JSON.parse(JSON.stringify(object));

First we turn the object into a JSON string with JSON.stringify() then we convert that string back into an object with JSON.parse(). Stringifying the data throws out all references, making the returned object completely immutable. But, if there are any references we need to keep inside this object, they're gone. If we have any maps, regex, dates, or other special types; they're gone. If we have any cyclic objects inside the object (which we shouldn't) the whole thing breaks and throws an error. So it's not very robust.

Data Laundering

If you don't want want to deal with the issues the JSON parser brings, there are a few—albeit hacky—methods you can can use. These all revolve around pasing our data to a service, then querying that service to pull our cleaned data back out. It's like money laundering, only with data, and nowhere near as cool.

For example, we can utilise the notification API:

const deepCopy = object =>
  new Notification("", {
    data: object,
    silent: true
  }).data;

This triggers a notification, silences it, then returns the data from that notification. Unfortunately, the user needs to be able to receive notifications for this to work.

We can also utilise the history API and the messageChannel in similar ways. But they all have their downsides.

What do now?

Deep copying is a bit of a heavy-handed approach to immutability. Being aware of the gotchas of shallow copying should be enough to see you through most problems. You can use the nested spread method outlined above to fix any problem areas.
If this approach is starting to get unwieldy, you should aim to improve your data structure first.

If you absolutely need deep copying, then fear not. There's an issue on the HTML spec that hopes to address this, with the introduction of structuredClone(). The more visibility this gets, the more likely it is to be implemented. Until then, I'd suggest using a library like Immutable.js to handle your immutability. Or grab the cloneDeep() helper from the underscore library for a quick-fix.

If you're up for a challenge, try coming up with your own solution to deepCopy. My friend Niall had a lot of fun playing with some ideas on Twitter. I'd be interested to see what you all come up with.

This post was originally published on my website