Forem: Ben Mildren

7 JavaScript blogs to follow going into 2021

Ben Mildren — Thu, 10 Sep 2020 15:58:32 +0000

This blog post is from webdesignrepo's list of best Blogs and News websites.

Discover the best tools and links at webdesignrepo.

CSS-Tricks

Despite having CSS in the title, CSS-Tricks focuses on all aspects of Frontend development.
You may know them from their world famous "A Complete Guide to Flexbox" article, you only have to google flexbox for this to be top. They show off lots of new JS features and post a bunch of tutorials on how to things.

Post frequency: Multiple times a day
Standout feature: Variety of content

David Walsh

David Walsh has been cranking out posts since 2007! He is a veteran in the field and knows JS like the back of his hand. David Walsh has some amazing API reference guides where he distills complex topics into easy to digest language, a prime example being "JavaScript Promise API".

Post frequency: Several times a month
Standout feature: Solid fundamentals

Codrops

Do you like fancy animations? You'll love Codrops then. They publish demos and tutorials for some weird and wonderful animations, often leaning heavily into canvas, WebGL, Three.js etc. Here's a wave motion tutorial they posted from earlier this year.

Post frequency: Once a month
Standout feature: Beautiful animations

Flavio Copes

Flavio Copes has posted a blog every single day since January 2018. One man, one post, every single day. The commitment is outstanding! Either that or he lost a bet with the devil and is forced to post every day for all eternity. Devil's doing or not, it's a great blog for consumers and teaches lots of JS (and non-JS) stuff in really short bites. Some of it is beginner level, some intermediate, some advanced, so there's something for everyone. I would recommend Flavio for beginners as he explains core concepts well. If you use Google a lot, you're bound to run into Flavio's posts sooner or later, with titles like "How to test for an empty object in JavaScript" that explain small things well.

Post frequency: Daily
Standout feature: Bite sized posts

Tania Rascia

If I could only recommend one blog it would probably be Tania Rascia's blog. It mostly covers a lot of fundamentals as well as some experimental stuff, but most importantly it's very measured. When you look at Tania's blog history, it feels like every post matters, with almost every post being solid reading for all JS developers of all levels. It's just solid blog posts all the way down. Check out "Using Git submodules for private content" for a taste.

Post frequency: A couple times a month
Standout feature: Long form tutorials

Scotch

I'm more of a whiskey man myself, but who can deny how good Scotch tutorials are for free? They've been in the game for a long time posting tutorials and courses for popular frameworks and JS apis like React, Authentication, APIs, Tailwind and more. If you like video courses or longer form tutorial posts, Scotch is for you. Their latest tutorial is "Add social login to Ionic apps".

Post frequency: A couple times a month
Standout feature: Long form tutorials

Josh Comeau

After a brief hiatus, Josh Comeau is back! Josh writes about a lot of different topics, and although unconfirmed, it feels to me like Josh writes about problems he stumbles into in real life, at least that's the vibe I get from reading. Rather than churning out content for SEO, Josh's blog feels like a diary of his recent programming hurdles and how he overcame them. You'll get a real array of content with Josh, dark mode, Netlify, Gatsby, speaking at conferences, but he used to work at Gatsby so he does blog a lot about React and Gatsby if that's your thing. Check his post "Animated sparkles in React".

Post frequency: A couple times a month
Standout feature: His menu goes bloop

Stay up to date with all Javascript and Frontend related resources at webdesignrepo.

5 best tools for writing Javascript documentation

Ben Mildren — Tue, 18 Aug 2020 21:22:35 +0000

This blog post is from webdesignrepo's list of best documentation tools.

Discover the best tools and links at webdesignrepo.

Easiest setup

Docusaurus makes it easy to maintain documentation in a git repo. Your documentation files are just markdown files that live alongside your code, and the website is built for you automatically.

Perfect for open source projects.

Best documentation for components

Storybook is documentation for your components. React or vue or angular, they all work inside Storybook. It's a great way to showcase your components in a styleguide style way. You can also toggle state/props easily to show functionality of the components.

Most enterprise level

Wiki.js is easily the most flexible documentation framework. It has enterprise level features like localization, 2FA authentication and user management so you're probably wondering what the pricing tier looks like, but it's actually free and open source. Overkill for smaller projects, however for larger or company wide documentation it's unrivaled.

Most stable

Originally released in 2011, JSDoc is certainly showing it's age now. But with age comes maturity, and this sure is one tried and tested documentation generator. It's stable and feature-full although a little dated visually.

Best multi language support

Slate is very much inspired by Stripe's amazing documentation and they don't hide it. If you like Stripe's API docs, you'll love Slate with it's multi language support and clean look.

Slate works best with API documentation.

Hopefully you've found the javascript documentation generator to fit your needs!

For more of the best dev resources be sure to check out webdesignrepo.

How I built webdesignrepo in 17 days with JAMstack

Ben Mildren — Wed, 22 Jul 2020 08:04:00 +0000

webdesignrepo – New dev & design links every day. Plus a collection of helpful links.

Here's how I built it in 17 days. (Whilst staying inside as many free tiers as possible)

Deciding the stack

webdesignrepo consists of two things:

A large repository of top notch links, to serve as a reference point for designers and developers, almost like a big list of bookmarks.
A daily links section, where new interesting articles, research, projects, tidbits are posted. New additions to the repository get posted here also, with a little star showing they're special and they've been "saved" to the repository.

So, all I needed was a system where I could add these links (and tags, icons etc) and the site would build each day. Seemed a no brainer to run JAMstack over a bulky database.

The stack I settled on:

Gatsby (React based static site generator)
Sanity (Amazing headless CMS)
Netlify (Hosting and build pipeline)

That's for the website, but I also used Azure Functions, Sendy (emails) and a raspberry pi, I'll get to those bits later.

Day 1 - Setting up the project

I created two github repositories, one for Gatsby the frontend and one for Sanity the CMS.

Sanity is so fast to set up a quick schema with, I added a basic "Daily link" document type and added a new document into my CMS.

Gatsby is also quick to get up and running, although you do need to remove a fair few boilerplate files that aren't needed.

I used the gatsby-source-sanity plugin to start pulling in data from the CMS at build time.

Sanity and Gatsby have both written articles on how to use the combo together, you can see them here: Gatsby's guide and Sanity's guide.

I was already pulling in data from the CMS! Here's what I had end of day 1:

Day 2 - Organizing by days

Each day there are 3-5 daily links posted. I needed links to be ordered by day so that we could show "Monday – x, y, z" then "Tuesday - a, b, c" etc. So the schema for these daily links now looked as below:

export default {
  title: 'New link',
  name: 'newLink',
  type: 'document',
  fields: [
    {
      title: 'Label',
      name: 'label',
      type: 'string',
      validation: (Rule) => Rule.required(),
    },
    {
      title: 'Link',
      name: 'link',
      type: 'string',
      validation: (Rule) => Rule.required(),
    },
    {
      title: 'Post date',
      name: 'postDate',
      type: 'date',
      validation: (Rule) => Rule.required(),
    },
    {
      title: 'Added to vault',
      name: 'addedToVault',
      type: 'boolean',
    },
  ],
}

The addedToVault is whether the link was also added to the repo. Vault was a dumb word I used at the start and never bothered to change. I use the word vault interchangeably with repo links going forward. I regret this and should've changed to repo early.

For those who haven't seen Sanity, here's what that schema translates to:

Here's how it looked organized by day:

I continued to add a basic scaffold for what the repository of links might look like. Again, I set up a basic schema for these repository links and pulled the data into Gatsby.

Sanity encourages you to split your data logically, rather than based on what appears near other things visually. It's interesting once you get into this mindset but it did take me a moment.

For example, I have separate document types for Categories, Subcategories, and Vault Links. So you go to the CMS, add a new Category like Plugins. You then add a new Subcategory like Animation, which is linked to the Plugins parent category. You then add a vault link, which is linked to the Animation subcategory. It allows for any part of the chain to be renamed, replaced or changed without interfering with the rest.

I added a few dummy vault links in and I began pulling the data into the frontend. I also added a search bar but it didn't do anything.

Continuing into the evening, I cleaned up the design a little and moved it towards how I wanted it to look:

Day 3 - CSS and removing future posts

I added even more CSS:

When adding daily links, I might schedule them to be a day or two in the future. So I needed a way to remove these future posts and only show links from "today" and in the past. This seems like a very simple concept, but I actually ran into a few issues with Gatsby on this front.

The issue comes from Gatsby only allowing static queries in components. So querying data based on the date was out of the window inside components. I needed my graphql query to look like this (with SERVER_DATE being something like 2020-12-25):

query loadNewLinksQuery {
      allSanityNewLink(
        sort: { fields: [postDate], order: DESC }
        filter: { postDate: { lte: "${SERVER_DATE}" } }
      )

Pages in Gatsby work slightly differently, and aren't static in the same way. But you can't use template literals in page queries either 😞 You can pass through query variables via page context, but that felt a little pointless, so I ended up making basically all my API calls (to Sanity) in gatsby-node.js.

Although annoying to not be calling the data inside components, I did end up doing a fair amount of logic inside gatsby-node.js after calling the data and passing it to the page components, so it did start to make more sense as I went along. That said, I'd love to see Gatsby allow template literal queries or query variables in components.

I ordered all the links by date in gatsby-node.

Day 4 - Animating days and archive pages

With framer-motion (React animation library) imported, I set out to animate the transitions between days. This actually took a lot longer than expected, as is often the case with animation, it just takes a long time tweaking to make it feel perfect.

Later in the day, I added archive pages. These are pretty straight forward. I wanted to show 7 days on the homepage that the user could flick through, then after 7 days it'd take them to an archive page which showed 10-20 "daily" links on one page, and the user could keep going back in time if they wanted to.

Day 5 - Minor CSS

Day 5 was a pretty slow day and I took a quick stab at how the styling might look for the repo section. This was a job I was putting off and didn't want to do, because organizing a huge amount of data like this to be scanable and readable is quite a difficult design challenge.

Here's how it looked early on:

Day 6 - Search page

The search bar had sat at the top of the page for almost the entire time building this and had been totally useless. Today was it's day to shine!

A search function was something I knew not many users would use, but would be of massive help to that fraction of users that did. So I built it.

First off, I had to add tags to each link. I knew that just providing search through the labels/domains wouldn't be as helpful without the tags. So each repo link and each daily link now accept an array of references to tag documents (read: you can add a list of tags). In Sanity schema code it looks like this:

{
      title: 'Tags',
      name: 'tags',
      type: 'array',
      of: [
        {
          type: 'reference',
          to: [{ type: 'tag' }],
        },
      ],
      validation: (Rule) => Rule.required(),
    },

Each tag document only had one field: a label.

So I created a bunch of tags that I knew would be used a lot: 'Javascript', 'React', 'CSS' and figured I'd add the rest as I needed them.

With the tags set up, I went about creating what I can only describe as a very rudimentary search function. gatsby-node grabs every. single. link. along with each links tags and passes them all to the /search page. Then the search page checks the URL for params, and does a giant filter.

So, user is on the homepage. Types "react animation" into the search input and hits enter. They get moved to /search?terms=react,animation. The search page extracts those search terms, and then filters the giant list of links to the few that contain those terms in either the label, domain or tags of a link.

This is not a great solution. I'm totally aware and as the site grows larger this solution will get worse and worse. So within the next couple months I'm going to rebuild it in some fashion, but hey, it works for now.

As you can see below, I even added a "How search works" box to tell people just how crappy this search was.

You might've also spotted a newsletter subscription box in the footer! I actually added that Day 5 and it shows up in a few places.

Day 7-11 - Replacing Mailchimp

Ahh Mailchimp. Mailchimp is a great tool – but it is very expensive. In an effort to keep this rebuild as free as possible, I decided to ditch Mailchimp as my newsletter sender of choice. I had amassed 2000 email subscribers from webdesignrepo's following before, and needed a cheaper way to send them all update emails. Introducing Sendy.

Sendy is a self hosted email solution. It's PHP based (which I'm not familiar with) and uses Amazon SES to send the emails. I went with Sendy as it's a one off cost of 59USD. That 59 bucks will pay itself back within a month or two and then I'll be sending emails basically for free.

Hosting Sendy seems very easy, and it probably is if you're a regular person who fires up a DigitalOcean droplet to run it on or any other server. But I had a Raspberry Pi Zero W sat in my drawer that I'd never used and figured I'd put it to the task. If I have one regret in this whole thing, it's this part.

I will spare all the details, but basically I ran into a ton of issues. This is not Sendy's fault, it was due to me running it on the Pi from my home network. I had never "connected a device to the internet" before, which is weird to say as a professional senior front end developer but it's just not something I'd done before. I've always used cloud servers.

Suffice to say, I learnt a whole lot during this process about connecting devices to the internet. A few things I figured out after lots of googling:

You (kind of) need a static IP for your device. And domestic internet providers don't really offer that. Your home internet changes it's IP fairly often. So I set my Pi to be static internally, so other devices on the same network could always find it under the same IP. But it also needs an external static IP so I could point foo.com to 123.111.222.333 and be sure that the IP wouldn't change. I needed to either upgrade to enterprise level internet for a static IP (not going to happen) or to find another solution. Turns out there is another way! Many domain providers (or DNS) offer dynamic DNS. I'm with namecheap and all I had to do was set up an A+ record for my subdomain and point it to my network IP. So A+ record for foo.webdesignrepo.com pointed at 123.111.222.333. Namecheap has a URL that you can hit to update the IP of that A+ record. So, I set up a cron job on my Pi to ping that namecheap URL every 5 minutes, and if my networks IP has changed namecheap will update the A+ record. Awesome!
Now I have foo.webdesignrepo.com pointed to my networks IP. What happens next? Again, I felt embarrassed for not knowing this, but hey it was a great learning exercise. Once you have your domain pointed at your network IP, you need to forward those requests onto the right internal IP. So I setup port forwarding on my router to move :80 traffic onto my raspberry pi (which has a static internal IP).
I tested out the newsletter signup button locally and it worked! The new webdesignrepo was (secretly) hosted at v4.webdesignrepo.com, so I fired it up and tried to sign up to the newsletter and it failed. The signup box on the website just pings foo.webdesignrepo.com and says "Hey! ben@mildren.com wants to sign up". The problem stemmed from v4.webdesignrepo.com being served over HTTPS, and the Sendy installation being on HTTP (http://foo.webdesignrepo.com). So the browser blocked the request. Or the Sendy server blocked the request. One of the two, honestly I can't remember what blocked what but I remember it not working. So I needed foo.webdesignrepo.com to be served over HTTPS. I had used Let's Encrypt before so figured this would be easy to get the SSL certificate. Turns out the Pi Zero W has issues with it due to limited RAM. Bummer. After jumping through a million hoops to get the Pi to use Lets Encrypt correctly...it still failed when trying to sign up. This was my lowest point 😂 Honestly I was so close to switching to Mailchimp, at this point I'd spent 3 or 4 days on this thing and all of that time was spent trawling through forum posts trying to fix issue after issue. After what felt like an eternity, I stumbled across the answer and it was simple. HTTPS' default port is 443 🤦‍♂️ So I setup the port forwarding for 443 and what do you know everything worked.

At this point, I had everything working with Sendy on my Pi Zero W! It honestly took me days and I hated most of it but I learnt so much from this.

With the setup out of the way, I could start firing emails. So I started a new github repo called 'webdesignrepo-newsletter-sender' and this part was pretty straight forward. It's just a small node app that grabs today's links down from Sanity, then constructs some basic HTML for the email with those links in, and then it pings foo.webdesignrepo.com with the email HTML. Sendy then sends out the email. Easy.

I set this on cron job to complete every day.

So despite the tedious few days where I was close to crying, I had effectively set up a Mailchimp alternative for about 70USD total (Sendy is 59USD and the Pi was 9GBP I think).

Sending 2000 emails a day, 30 days a month, with Amazon SES works out to be 6USD, not bad.

Day 12-13 - Accessibility and mobile designs

I want webdesignrepo to be accessible to all, so I added all the relevant aria attributes where needed and started working on the focus order.

I spent a while thinking about how the focus order should work and settled on this:

You can see the tab focus order here (for some reason dev.to won't let me embed this gif)

I asked Twitter what the best way to handle focus order for these items would be and nobody replied.

A11y is important to me and I want to be as inclusive as possible, so if something doesn't look right, work right, or screenreaders aren't working as expected at webdesignrepo then please ping me on Twitter and let me know.

At this point the whole site was coming together but I had only been designing for desktop. So I got to work on the responsive side of things, constantly testing along the way to make sure everything felt right.

Day 14 - Images for each post

I wanted each daily link to have a little icon next to the link for the website, like a favicon/logo. Adding this sounds trivial but in practice was a little more involved.

Sanity has 500k limit per month on it's CDN for assets, which is actually super generous, but I wanted to stay within the free tier for as long as possible, and I might pass the 500k image requests sooner than you'd think.

Some math:

There are 7 days displayed on the homepage of daily links
Each of those days has 3-5 links, let's assume it's 5
That's 5 * 7. 35 little logo images on the homepage alone

With every pageview, I'd use 35 CDN requests. If a user wanted to go further back in time, each archive page hold 10 days worth of links which is 50 more images.

Even assuming that nobody every visits an archive page (for 50 more requests), 500,000 / 35 is 14,285 pageviews.

So at 14k pageviews a month, I'd have to start paying for CDN access. Granted, Sanity's costs are real cheap at 1USD per every extra 100k requests (which is around 3k pageviews). And Sanity does deserve my money, I think they've made an amazing product and I'm happy to pay for it, but I really was thinking of this as an exercise in scaling for as low cost as possible (just for the fun of it).

As well as the costs, I'd have to upload a logo for every single link. Sure, some are re-used a lot, I post a lot of Github links, CSS-tricks etc. But I also post a ton of smaller blogs that I may only post once. I didn't want to upload an image for every single link.

Alternatively, I could have a bot go and grab the images for me. Favicons are unfortunately too small, as I wanted at least 64x64px. Twitter images and Facebook open graph images worked decently enough though, higher res and often of the website logo! But for the same reason as above, I didn't want to do this for every image as it would cost a lot of money, probably way more than just using Sanity's CDN.

I needed a balance of both.

What I actually went with is three different ways of getting the images. Here's how it works:

I added Icon as a document type in Sanity, so I can upload images. I added a field onto the DailyLink schema to select these icons. For the most often used websites, I downloaded an image of their logo, resized to 64x64 and ran through TinyPNG, then uploaded to Sanity. In gatsby-node, (which runs during the gatsby build process) when I request all the daily links, I also request the icons. This means the icons are only requested once a day. Each icon is then base64'd and placed directly inside the code. Lightning fast for users, keeps me inside the free tier and only adds ~20kb to the page load. This only works for the sites I post the most, I currently only have around 20 icons saved.
I built a serverless function and hosted it on Azure. I pass it a list of URLs and it returns a list of twitter and FB open graph images as URLs. Honestly, I could've used my Pi for this but it's slow at this kind of thing and I didn't want that to be a point of failure, my Pi has enough on it's plate. Azure's cloud functions also have a generous free tier. You get 400,000 GB-s, that's gigabyte seconds. I'll spare the math, but with my function taking around a second to run each time, that works out at around 3 million function invocations. Again, in gastby-node at build time, I call this cloud function with all the URLs on the homepage (excluding ones I already have images for from Sanity). I then add these image URLs into the code, and they're requested from the website in questions servers.
For archive pages, for when a user goes back in time, these images are not supplied. When a page loads and finds links without a base64 image (from Sanity) or a URL src (from the links site), it calls the Azure function with a list of URLs and then fetches those images.

It's a little convoluted, a three step process for something quite trivial, but it does work and it is free.

To recap:

I add popular images into the CMS. They're base64'd into the code
Azure function is called for remaining missing images on homepage, twitter/open graph URLs used.
For archive pages, nothing is embedded at build time and the Azure function is called by the client to fetch twitter/open graph images.

Was this worth it? 🤷‍♂️ It was fun to try to reduce costs as much as possible though

The only issue with this system, is some of these smaller blogs I post are hosted on servers without HTTPS. So webdesignrepo makes HTTP calls to assets and some browsers note this in the security padlock icon. That's something I'll have to think about.

Day 15-16 - Adding all the data

I tidied up the design for the repo section:

I added a menu button for quickly navigating the repo:

With the bulk of the site complete, I just had to add the data. I had hundreds of links in bookmarks for this, all organized by category and subcategory. I estimate adding them all to the CMS took 8-12 hours. Of course, it's taken me years to collect such a great set of links.

Sanity does have an API for adding stuff which could've made this quicker, but once I got into a rhythm it wasn't so bad. It was actually quite therapeutic after such chaos with the Sendy Pi setup to have a mindless task like this.

Day 17 - Cron jobs and Twitter bot

I have a Twitter account for webdesignrepo and wanted to post all new daily links there every day without having to do it myself.

Using the Twit library, it's so simple to set up this kind of bot. I spun up a new repo, created one index file and it was done. It requests today's links and posts them spread across the day. I also added a twitter handle field on the daily link Sanity schema, so I add that in when adding new links and the Twitter bot tweets like this:

${link.label}

${link.url}

@${link.twitter_handle} #${link.tags}

This is simplified but at it's core that is all it does. The tags I add to each daily link (and repo link) for searchability are great for twitter which also uses hashtags. Again, cron job this bad boy and it's good to go.

Usually when you set up a headless CMS with a static site generator you'd have the site rebuild every time data is added to the CMS. I've done this before with Gatsby and Sanity, but it's actually not what I wanted or needed.

webdesignrepo only needs to rebuild once a day at 6am to show the new daily links. Netlify offers a really simple webhook for this, and when you ping the URL it rebuilds so I set up a cron job on the Pi to rebuild the site every day.

That's all folks

There were lots of smaller things not mentioned in this post like: adding the 'added to repo' icon, favicon/social media icons, meta/SEO stuff, adding sponsored tags, testing etc.

I'm currently within every free tier on Sanity, Azure and Netlify by quite a long way. Side note, Netlify's free tier offers 300 build minutes per month. The site takes around 2 minutes to build each day, which is around 60 build minutes used each month. It'll be interesting to see how this build time goes up in a year when potentially thousands more links have been added.

And that's it, that's how I built webdesignrepo in 17 days. In reality, this was spread across about 6-8 weeks as I have a full time job and there were also plenty of days where I'd only do 15-30 minutes work, but largely it was just 17 full days.

How it looks today:

webdesignrepo - check it out for links on javascript, react, css, design and all things web dev!

React 16 and 16.2 Overview - Fragments, Portals and Error Boundaries

Ben Mildren — Thu, 21 Dec 2017 00:00:00 +0000

React 16 (and 16.2) adds some nice quality of life changes along with some performance gains.

Return types and Fragments

There's a whole slew of new return types in the render method.

You can now return a string or number.

const Foo = () => 'string'

const Foo = () => 25

Often you end up wrapping a group of items in a div or span tag because React requires a wrapping element. React 16 introduced the ability to return arrays of items.

const Foo = () => ([
    <p key='a'>1</p>,
    <p key='b'>2</p>,
    <p key='c'>3</p>,
    <p key='d'>4</p>,
  "Some words"
])

But that kind of sucks as you need to add a key to each item, seperate each item by a comma and text must be wrapped in quotes. Yuck.

React 16.2 builds on React.Fragment to make a really nice way to wrap a group of items without the extra DOM node.

import React, { Fragment } from 'react'

const Foo = () => (
    <Fragment>
        <p>1</p>
        <p>2</p>
        <p>3</p>
        <p>4</p>
    </Fragment>
)

There is also a shorthand way of writing Fragment which doesn't require the import.

import React from 'react'

const Foo = () => (
    <>
        <p>1</p>
        <p>2</p>
        <p>3</p>
        <p>4</p>
    </>
)

This does look a little funky I'll admit, but I think once we've gotten used to it we won't know how we lived without it! Babel will support the <> shorthand syntax in v7. See this blog post for support in various tools. You can use the imported Fragment component right now on Babel 6.x.

One thing to note is that you still need to key Fragments when you map over data and such. The shorthand <> does not accept the key attribute unfortunately.

import React, { Fragment } from 'react'

const Foo = () => (
    <Fragment>
        {[1, 2, 3].map(n => (
            <Fragment key={n}>
                <span>hello</span>
                <span>world {n}</span>
            </Fragment>
        ))}
    </Fragment>
)

The above code will produce an HTML output of this:

<span>hello</span>
<span>world 1</span>
<span>hello</span>
<span>world 2</span>
<span>hello</span>
<span>world 3</span>

Finally no more wrappers cluttering our DOM 🎉

Error Handling

Prior to React 16, when something went wrong with a component the whole application could crash and it was only visible in the console. That's why packages like redbox-react get over a million downloads a month!

To solve this issue, we now have Error Boundaries using a new componentDidCatch lifecycle event.

You can wrap potentially breaking components in Error Boundaries and then configure them to show fallback UI if they do break.

I modified a component that the official React blog supplies for an Error Boundary that will work in basically any app.

import React from 'react'
import PropTypes from 'prop-types'

class ErrorBoundary extends React.Component {
    constructor(props) {
        super(props)
        this.state = { hasError: false }
    }

    componentDidCatch(error, info) {
        // Display fallback UI
        this.setState({ hasError: true })
        // You can also log the error to an error reporting service
        // Remove this if you have no error logging
        logErrorToMyService(error, info)
    }

    render() {
        const { children, errorMessage } = this.props
        if (this.state.hasError) {
            // You can render any custom fallback UI
            return <h1>{errorMessage}</h1>
        }
        return {children}
    }
}

ErrorBoundary.defaultProps = {
    errorMessage: 'Something went wrong.'
}

ErrorBoundary.propTypes = {
    children: PropTypes.oneOfType([
        PropTypes.arrayOf(PropTypes.node),
        PropTypes.node
    ]).isRequired,
    errorMessage: PropTypes.string
}

export default ErrorBoundary

You then just wrap that around anything you think will fail.

const foo = () => (
  <div>
    <ErrorBoundary errorMessage='This component is not working properly'>
      <UnstableComponent>
    </ErrorBoundary>
  </div>
)

Remember we can customise the UI, it's not just a message. So you could have some really cool fallback content for components.

Things to note:

componentDidCatch works just like a regular old catch {} block
Error Boundaries must be class components
Error Boundaries can only catch errors from their children, not errors from themselves

Portals

Portals provide us with the ability to render things in other DOM nodes outside of the parents scope.

This opens up some really cool possibilites for things like modals, dialog boxes, tooltips etc.

I've seen many different systems for modals in React across many projects and I never feel like anyone has gotten in right, and that's likely because React didn't have the tools to do it right. Now with Portals we might be able to solve this problem. There's no more passing a function all the way through your React tree or using context.

Portals can be used with the simple ReactDOM.createPortal(child, container) function.

import React, { Component } from 'react'
import ReactDOM from 'react-dom'

const Bar = () => (
    <p>Through the portal</p>
)

class ContactScreen extends Component {
    constructor(props) {
        super(props)
        this.nav = document.querySelector('nav')
    }
    render() {
        return ReactDOM.createPortal(
            Bar,
            this.nav
        )
    }
}

child can be any valid React component and container can be any DOM node.

When using styled components or any other css in js system, you're classnames will end up being all mangled strings. It might be worth adding an ID to these components so you can portal to them should you need it.

Of course, this isn't just reserved for existing DOM nodes. You can create one on the fly and insert it yourself into the DOM.

Custom DOM attributes

Previously, you could only use DOM attributes that actually existed, along with aria- and data- prefixed attributes. Now you can use any custom attribute and it'll get passed through to the real DOM element.

<div foo='bar' />

Server Side Rendering

Server side rendering is not something I've used personally before, so I won't try to act like I know a lot about it. We did use it at a previous company I worked for, but I wasn't involved in the process. So here's a really good article about what's changed in SSR in React 16. (TLDR: it's more performant)

Miscellaneous

It got smaller. React + React DOM is now ~30% smaller than before.
They changed the license to MIT 🎉

Maps in ES6 - A Quick Guide

Ben Mildren — Mon, 11 Dec 2017 00:00:00 +0000

Overview

Maps and Sets often get lumped together in articles. They're both new ES6 collection types with similar interfaces but that's where the similarities stop. So it makes sense to have two separate articles on them.

Maps are like the love child of Arrays and Objects with a nice and sane interface.

You can instantiate one like so:

const foo = new Map()

In my last article on Symbols we looked at how Objects could use either Strings or Symbols as keys. Well Maps can use any type of data as a key. Use the .set() method to add key value pairs.

Map.prototype.set(key, value) : this

// as `this` is returned, we can chain the set methods
foo.set(1, 'one')
   .set(null, 'nothing')

const bar = { name: 'Ben' }
foo.set(bar, { age: 25 })

You can also pass the constructor a 2D iterable when creating a Map.

const foo = new Map([
  [undefined, 'hello'],
  [null, 'nada']
])

To retrieve items from a Map use the .get() method.

Map.prototype.get(key) : any

foo.get(undefined) // 'hello'

Unlike Objects (but more like Arrays), Maps have a handy .size property.

const foo = new Map([
  [1, 1],
  [2, 2]
])

Map.prototype.size : number

foo.size // 2

Maps check references to Objects for equality, so using Object literals is a bad idea as you won't be able to retrieve the values.

const foo = new Map()

foo.set({}, `you'll never catch me`)

foo.get({}) // undefined

There are a number of other useful methods Maps supply.

const zoe = { name: 'Zoe' }
const foo = new Map([
  ['hey', 0],
  [9, 'nine'],
  [zoe, { age: 23 }]
])

// .has checks if the collection contains a key
Map.proptype.has(key) : boolean
foo.has(9) // true
foo.has(5) // false


// .delete simply deletes an item
Map.prototype.delete(key) : boolean
foo.size // 3
foo.delete(5) // false
foo.size // 3
foo.delete(9) // true
foo.size // 2


// .clear deletes all values
Map.prototype.clear() : undefined
foo.clear() // undefined
foo.size // 0

Map API Summary

const foo = new Map()

foo.set(key, value) 

foo.get(key)

foo.has(key)

foo.delete(key)

foo.clear()

foo.size

Usage

One fantastic advantage Maps have over Objects is how you can iterate over them. They're built to be iterated over with baked in methods like .forEach and an iterator protocol for use with for..of loops.

They also preserve their order, unlike Objects and more like Arrays. So you can be sure everything is in the correct order.

const foo = new Map([
  [1, 'first'],
  [2, 'second'],
  [3, 'third']
])

Map.prototype.forEach(callback(value, key, map), [thisArg]) : undefined

foo.forEach((val, key) => console.log(val, key)) 
// first 1
// second 2
// third 3

The for..of loop returns each item (including both key and value), not just each value like you might expect.

You can use destructuring to separate the values.

for(let [key, val] of foo) {
  console.log(key, val)
}
// 1 'first'
// 2 'second'
// 3 'third'

Just like with Objects we get access to .keys(), .values() and .entries().

Map.prototype.keys() : Map iterator
const keys = foo.keys() // 1, 2, 3

Map.prototype.values() : Map iterator
const values = foo.values() // 'first', 'second', 'third'

Map.prototype.entries() : Map iterator
const entries = foo.entries() // [1, 'first'], [2, 'second'], [3, 'third']

These methods all return iterator objects. As they all conform to the iterator protocol, they can be used with for..of, like a generator or using the ... spread operator.

const keys = foo.keys()
for(let key of keys) {
  console.log(key)
}
// 1
// 2
// 3

const entries = foo.entries()
entries.next() // { value: [1, 'first'], done: false }
entries.next() // { value: [2, 'second'], done: false }
entries.next() // { value: [3, 'third'], done: false }
entries.next() // { value: undefined, done: true }

const values = foo.values()
console.log(...values) // 'first', 'second', 'third'

All of the above iteration methods make for a much more well rounded approach to iterating over a key value store, with a wealth of methods and consistent order; considerably better than on an Object.

A great use case for Maps is the potential to add metadata to existing objects or attaching some extra data to immutable objects. Symbols are also very good for this, see my previous article.

const dataObjects = [
  { name: 'Ben', age: 25 },
  { name: 'Zoe', age: 24 },
  { name: 'Roman', age: 50 },
]

const mapObjects = new Map()
dataObjects.forEach(val => mapObjects.set(val, { created: new Date() }))

console.log(mapObjects.get(dataObjects[0])) // [{ name: 'Ben', age: 25 }, { created: Sun Dec 17 2017 11:57:52 GMT+0000 (GMT) }]

Should I use a Map or an Object?

After seeing all that Maps can do, you might be thinking: "Will I ever need to use plain old Objects again?"

Let's look at the pros and cons of each:

Pros

Ordered. They stay in order like Arrays and have many iteration methods.
Objects (or any other type) as keys. Having objects as keys can be super powerful.

Cons

Loses a lot of Object methods. Most are very rarely used, but some are handy.
No fast dot notation, which means no destructuring.

So, if you need to iterate over your object or you want keys that aren't strings, your only option is Maps. If you know the shape of your object and expect it to be static (not adding or removing properties) then an Object might be best.

Details & Caveats

What is equal?

Maps use something called SameValueZero to determine if a Map has a key.

SameValueZero is very similar to === but has 2 notable differences:

NaN is equal to NaN
+0 is equal to -0

NaN === NaN // false

const foo = new Map()

foo.set(NaN, 'hello')
foo.get(NaN) // 'hello'

Non-existant keys

When looking up a key that doesn't exist, undefined is returned. You'll need to be aware of this if you might be expecting a return value of undefined.

new Map().get('notAKey') // undefined

Building from Objects

Object has a handy .entries() method which returns the 2D array structure needed for a Map.

const foo = { name: 'Ben', age: 25 }
const entries = Object.entries(foo) // [ ['name', 'Ben'], ['age', 25] ]
const foo = new Map(entries)

Weakmaps

Despite being in the Details & Caveats section, WeakMaps are not trivial at all! (I just figured this would be the best place to put them)

WeakMaps are a seperate data type to Maps. Just like their non-weak counterparts except they allow Javascript to remove their keys from memory if required and the keys must be objects.

They have a very similar api to Maps, with a few methods removed. These are all the methods WeakMaps have:

WeakMap.prototype.get(key) : this
WeakMap.prototype.set(key, value) : this
WeakMap.prototype.has(key) : boolean
WeakMap.prototype.delete(key, value) : boolean

Put simply, WeakMaps are basically Maps which allow its own object keys to be garbage collected. This helps with memory leaks.

If a Map has an object as a key and that object gets destroyed, the Map still retains that object as a key and it will stay in memory and won't be garbage collected as it's still "reachable" (don't worry, I'm going to write an article about how garbage collection works soon!).

const foo = new Map()

let bar = { name: 'Ben' }

foo.set(bar, { age: 25 })

foo.get(bar) // { age: 25 }

bar = null

foo.entries() // [ [{ name: 'Ben' }, { age: 25 }] ]

Conversely, if a WeakMap has a deleted object as a key, the WeakMap allows the garbage collector to remove that key and it's associated value.

const foo = new WeakMap()

// You can only use objects as keys, no primitives
foo.set('primitive', 1) // TypeError: Invalid value used as weak map key

let bar = { name: 'Ben' }

foo.set(bar, { age: 25 })

foo.get(bar) // { age: 25 }

bar = null

// If there are no other reference to bar, it is removed as a key from foo

Now, you might be wondering why I didn't show that the WeakMap doesn't retain the bar key in the above example, and that's because I can't!

WeakMaps do not have the tools to check, such as .size, .entries(), .keys() or .values(). And there is a good reason for this limitation: it wouldn't be safe to show it.

Javascript garbage collects at different times depending on what is executing, how intense current operations are, how much their is to collect, etc. Each Javascript engine handles these things slightly different too. So, although we know the WeakMaps key will be removed by the garbage collector, we do not know exactly when that will run. So it's not safe to use things like .size which might tell us we have 1 item one moment and 0 the next due to garbage collection running in the background.

Where to use WeakMaps over Maps

WeakMaps won't see a ton of usage but there will be niche cases where they come in handy.

One potential use case would be in state management where you need an object as a key. Most larger apps have a dedicated library for state management like Redux or Vuex. But maybe for a smaller app, if you were to roll your own state management system it might be handy to use WeakMaps there. Storing objects as keys, but also allowing those object to be garbage collected should they not be required anymore could be quite powerful.

There is also the possibility of using WeakMaps for private data.

const keepOut = new WeakMap()

class Person {
    constructor(name) {
    keepOut.set(this, { name })
  }
  get name () {
    return keepOut.get(this)
  }
}

const me = new Person('Ben')

me.name // { name: 'Ben' }

As the instance of Person is stored as the key in the WeakMap, the data cannot be accessed without having that instance of Person.

I mentioned above about using Maps to add metadata to objects or simply extend objects that couldn't be extended. WeakMaps are very handy for doing this with DOM elements.

const myH1 = document.querySelector('h1')
const myImg = document.querySelector('img')

const domElems = new Map([
  [myH1, { created: new Date() }],
  [myImg, { someExtraData: 'foo' }]
])

Now you can track extra data along with the DOM elements and the WeakMap will allow them to be garbage collected when the DOM elements are no longer needed!

Symbols in ES6 - A Quick Guide

Ben Mildren — Thu, 07 Dec 2017 00:00:00 +0000

Overview

Symbols are a new primitive type introduced in ES6.

Symbols are completely unique identifiers. Just like its primitive counterparts, they can be created using the factory function Symbol() which returns a Symbol.

const foo = Symbol()

The two variables below, foo and bar are not the same, they are both unique. Imagine a really long random string is return by each Symbol() call.

const foo = Symbol()

const bar = Symbol()

foo === bar // false

// I imagine Symbols looking like this 'NqkvK1kq7q#R99l9&7YH*@7wa8cFJc'

It takes an optional description argument, used only for debugging purposes.

const foo = Symbol('foo')

Unlike its counterparts (Boolean, Number and String), Symbols do not have a literal nor can they be used as a constructor.

const foo = new Symbol()
// TypeError: Symbol is not a constructor

Usage

Symbols primary use case is for making private object properties, which can be only of type String or Symbol (for those curious, Numbers are automatically converted to Strings).

const sym = Symbol()

const foo = {
  [sym]: 'someValue'
}

foo[sym] // 'someValue'

Using Symbols for object properties is handy for hiding certain properties that might name clash with other libraries.

They're also very useful for defining metadata on an object, as Symbols are not enumarable and as such they are not iterated over when using a for...of loop and other functions that return object properties.

const sym = Symbol()

const foo = {
  name: 'Ben',
  age: 25,
  [sym]: 'someHiddenMetadata'
}

for(let val of foo) {
  console.log(val) // Ben, 25
}

Object.getOwnPropertyNames(foo) // Ben, 25

Object.keys(foo) // Ben, 25

Symbols as object properties are not completely hidden though, hence why I've been italicising hidden in this article. You can still access Symbols by using the following methods:

Object.getOwnPropertySymbols(foo) // Symbol()

Reflect.ownKeys(foo) // Symbol()

So, they're not entirely private, but they are skipped in common iteration cycles.

Just as you'd expect they can also be used for any object property name, including methods.

const bar = {
  [Symbol('method')] () { 
    console.log('hello')  
  }
}

Usage without objects

Although the main application for Symbols seems to be as object property names, they could have value elsewhere, most notably as a replacement for Strings in constants.

Lots of projects have a set of constants that looks something like this:

const ARTICLE1 = 'ARTICLE1'
const ARTICLE2 = 'ARTICLE2'
const ARTICLE3 = 'ARTICLE3'

These constants might then be used in another file making a request as such:

import * as c from './constants'

const getRequestURL = req => {
  switch(req) {
    // Standard articles
    case c.ARTICLE1: {
      // do stuff
      return `https://api.com/${c.ARTICLE1}`
    }
    case c.ARTICLE2: {
      // do stuff
      return `https://api.com/${c.ARTICLE2}`
    }
    case c.ARTICLE3: {
      // do stuff
      return `https://api.com/${c.ARTICLE3}`
    }
    // Articles written by users get handled here
    default: {
      // do stuff
      return `https://api.com/userGeneratedContent/${req}
    }
  }
}

Obviously the above is quite a contrived example but you get the picture. A lot of frontend apps are structured similarly to this.

Let's imagine that by chance someone named the title of their article 'ARTICLE1'. It would not get to the default function of the switch statement where it wants to be, it would be intercepted above. You can see that because our constants are not unique, they can interact in unexpected ways.

The solution to this issue is using Symbols as constants.

const ARTICLE1 = Symbol('ARTICLE1')
const ARTICLE2 = Symbol('ARTICLE2')
const ARTICLE3 = Symbol('ARTICLE3')

Now there is no possible way these constants can conflict with another constant.

Details & Caveats

Global Symbols

Global Symbols seemingly go against the whole point of Symbols: they're not unique. But they do have a purpose.

A Global Symbol Registry exists where you can store and access Global Symbols. You can use the Symbol.for(key) method to both create and access Global Symbols.

const foo = Symbol.for('hello') // If the Symbol does not exist, it's created

const bar = Symbol.for('hello') // The Symbol exists, so it is returned

foo === bar // true

Note that the key here is not an optional description like in regular Symbols, it is an identifier.

You can do a reverse look up for Global Symbols if you have the Symbol itself and want the key.

const foo = Symbol.for('someKey')

const bar = Symbol.keyFor(foo) // someKey

Global Symbols exist across realms. A realm is a context in which code exists, almost like a scope. Modules, global variables etc. all exist within realm. Each frame in a browser is in its own realm, so iFrames have a different context to your main frame. Global Symbols actually do exist across realms and can be used between them.

"Well Known" Symbols

There are a number of "Well Known" Symbols baked right into javascript and they all have specific functions.

The most useful of these so called "Well Known" Symbols is Symbol.iterator, which allows us to make our own objects iterable. The for...of loop calls Symbol.iterator to iterate over a set of values.

MDN provides this simple example to show how you'd use Symbol.iterator.

var myIterable = {}
myIterable[Symbol.iterator] = function* () {
    yield 1;
    yield 2;
    yield 3;
};
[...myIterable] // [1, 2, 3]

You can see a full list of "Well Known" Symbols right here.

No auto conversion to String

Unlike many other types, Symbols do not auto convert to a String. You may not have even noticed this was happening for other types, but think about when you alert() a Number, or alert() an Array. They get auto converted to a string.

Symbols don't support this. You must explicitly call the .toString() method.

This funcionality is here to help us as usually they should not be converted.

const sym = Symbol();
const foo = '' + sym
// TypeError: Cannot convert a Symbol value to a string

alert(sym)
// TypeError: Cannot convert a Symbol value to a string

alert(sym.toString()) // Symbol()

Due to this, you need to use square brackets within object literals, like so const foo = { [Symbol()]: 'hey' }.

When are they copied?

Symbols are copied in both Object.assign and the object spread operator { ... }.

const sym = Symbol('hey')

const a = { [sym]: 'a' }

const b = { ...a } // { Symbol('hey'): 'a' }

const c = Object.assign(a, {}) // { Symbol('hey'): 'a' }

Sets in ES6 - A Quick Guide

Ben Mildren — Wed, 18 Jan 2017 00:00:00 +0000

Overview

Sets are a new data type in ES6.

They're similar to Arrays with one major difference, each value must be unique. They have an API that's very similar to Maps. They're a little bit simpler than Maps though so don't worry!

Sets are instantiated as you'd expect: either empty or with an iterable.

const foo = new Set()

const foo1 = new Set([1,2,3,4,5])

You can add to the Set with the .add() method. As it returns this, you can chain them.

Set.prototype.add(value) : this

foo.add('hello')

foo.add('hey there')
   .add('yo')

You can also check to see if a value exists with .has() method.

Set.prototype.add(value) : boolean

foo.has('yo') // true

foo.has('greetings') // false

You may have noticed a pattern with this API in comparison to Maps now and removing items is no different with the .delete() and .clear() methods. .remove() returns a boolean depending on if the value existed or not.

Set.prototype.delete(value) : boolean

foo.remove('yo') // true

foo.remove('greetings') // false

Set.prototype.clear() : undefined

foo.clear() // undefined

The static property .size returns the amount of items in the Set.

Set.prototype.size : number

const bar = new Set([1,2,3,4,5])

bar.size

Set API Summary

There a few other methods for iteration which we'll cover in the next section, but these are the basics.

const foo = new Set()

foo.add(key, value) 

foo.get(key)

foo.has(key)

foo.delete(key)

foo.clear()

foo.size

Usage

Special snowflake

Remember the big difference between Arrays and Sets? In a Set, a value cannot occur more than once. So each value is definitely unique. This immediately has some fantastic use cases. I know I've certainly reached for Lodash's _.uniq functions before, well now you don't need to.

const myArray = [1,1,2,2,3,3]

const mySet = new Set(myArray)

const uniqueArray = [...mySet]

This is pretty powerful, although it would be nice for Arrays to have a built in method for this function. (Side note: ... and Array.from are the slowest methods to do this, with for...of being the quickest on modern browsers. This is a real shame as the first 2 are so much cleaner. Source)

Iteration

Something not immediately obvious is that you cannot retrieve values from a Set using the Array index method [n]. This is because Sets are not indexed.

The only way to use the values in a Set is through iteration, and for this reason they're stored in insertion order. You can use the .forEach() method to iterate over a Set.

const foo = new Set(1,2,3,4)

Set.prototype.forEach(callback(val1, val2, Set), [thisArg]) : undefined

foo.forEach(i => console.log(i)) // 1, 2, 3, 4

Strangely, the callback you pass to .forEach() accepts 3 arguments. Both of the first 2 args are the same thing: the value. I imagine they duplicated the value to conform with the same API that Maps have (where they have a key and a value). The third value is the current Set you're iterating over. A number of methods have this argument, and I've never figured out why (please comment if you know why). Finally, you can optionally set the value of this.

Sets also use the iterator protocol which allows you to use Sets with for...of loops.

for (let i of foo) {
  console.log(i) // 1, 2, 3, 4, undefined
}

Maps have a .keys(), a .values() and a .entries() method. Sets do not have keys so they do not have a .keys() method, but they do have the other two.

Set.prototype.values() : Set iterator

const vals = foo.values() // SetIterator {1,2,3,4}

for (let val of vals) {
  console.log(val) // 1, 2, 3, 4
}

Set.prototype.entries() : Set iterator

const ents = foo.entries() // SetIterator {1,2,3,4}

for (let ent of ents) {
  console.log(ent) // [1, 1], [2, 2], [3, 3], [4, 4]
}

Should I use an Set or a Array?

When we asked a similar question for Maps and Objects, Maps seemed like the better choice quite often, but it was a pretty good split on pros and cons for the pair of them. Unfortunately for Set, I think the answer here is much more one sided.

Arrays are almost always more useful in every day life. Sets having only unique items within them is definitely helpful, I just don't see many more things that I'd honestly pick a Set for over an Array. Sure, there are certain situations where Sets excel, but they're so few and far between that I'd reach for an Array basically every time.

That said, do read the details and caveats below as there are definitely certain situations where a Set is more performant or more practical.

Details & Caveats

What is equal?

Like Maps, Sets use something called SameValueZero to determine if a Set has a value.

SameValueZero is very similar to === but has 2 notable differences:

NaN is equal to NaN
+0 is equal to -0

NaN === NaN // false

const foo = new Set()

foo.add(NaN)
foo.size // 1

foo.add(NaN)
foo.size // 1

Using Array methods

Converting between Sets and Arrays is so easy, using Array methods on Sets is easy!

const foo = new Set([2,1])

const sortedArray = [...foo].sort()

const sortedSet = new Set(sortedArray) // 1, 2

Or even shorted (but slightly less clear)

const foo = new Set([2,1])

const sortedSet = new Set([...foo].sort()) // 1, 2

WeakSet

WeakSets are a separate data type, but they are very similar to Sets.

This is the full WeakSet API:

WeakSet.prototype.add(value) : this
WeakSet.prototype.delete(value) : boolean
WeakSet.prototype.has(value) : boolean

As we can see, this just like the Set API but with a few things removed.

It is worth noting that WeakSet.prototype.clear() used to be apart of the spec, but has been removed. Although this may work with certain browsers, you should not use this as it will be unsupported soon.

There are two fundamental differences between WeakSets and Sets:

You can only add objects to WeakSets, no primitives
WeakSets allow their values to be garbage collected

Let's see the first point in action: no primitives.

const foo = new WeakSet()

foo.add(1) // TypeError: Invalid value used in weak set

foo.add('hello') // TypeError: Invalid value used in weak set

foo.add({}) // ✅

That's straightforward, but the second point is a little harder to grasp without good understanding of how garbage collection works in modern browsers (I'll be writing a blog about that shortly).

Browsers hold on to objects in memory for as long as they think that object is "reachable". If you were to store a value in a Set, and that value became unreachable anywhere else, it'll still be reachable in the Set and thus the garbage collector will not remove it from memory.

const foo = new Set()

let someObj = { name: 'Ben' }

foo.add(someObj)

someObj = null

foo.size() // 1

In the above example, foo holds on to the value and stops it being garbage collected. WeakSets hold on to their values weakly and will allow garbage collectors to remove them.

const foo = new WeakSet()

let someObj = { name: 'Ben' }

foo.add(someObj)

someObj = null

Unfortunately, there is no way to check that the object has been removed from foo, but rest assured it will be once a garbage collection happens.

WeakSets have such a tiny API that I cannot see many every day use cases for them. There is potentially some very niche cases such as marking certain items. Say you need to know if you've marked an item that you've previously iterated over. You could add another property to the object or you could add that item to a WeakSet.

const foo = new WeakSet()

const someArr = [
  { name: 'Ben' },
  { name: 'Zoe' },
  { name: 'Roman' }
]

for (let value of someArr) {
  // Flipping a coin
  if(Math.random > 0.5) {
    foo.add(value)
  }
}

// You can check later if that value got a heads or tails
foo.has(someArr[0])

Assuming that item becomes unreachable in the future, it will also be removed from the WeakSet.

This all feels like a stretch to me if I'm honest. It just feels like I would basically never reach for a WeakSet. I'd love for someone to comment and let me know some use cases for WeakSets.

Forem: Ben Mildren

7 JavaScript blogs to follow going into 2021

CSS-Tricks

David Walsh

Codrops

Flavio Copes

Tania Rascia

Scotch

Josh Comeau

5 best tools for writing Javascript documentation

Easiest setup

Best documentation for components

Most enterprise level

Most stable

Best multi language support

How I built webdesignrepo in 17 days with JAMstack

Deciding the stack

Day 1 - Setting up the project

Day 2 - Organizing by days

Day 3 - CSS and removing future posts

Day 4 - Animating days and archive pages

Day 5 - Minor CSS

Day 6 - Search page

Day 7-11 - Replacing Mailchimp

Day 12-13 - Accessibility and mobile designs

Day 14 - Images for each post

Day 15-16 - Adding all the data

Day 17 - Cron jobs and Twitter bot

That's all folks

React 16 and 16.2 Overview - Fragments, Portals and Error Boundaries

Return types and Fragments

Error Handling

Portals

Custom DOM attributes

Server Side Rendering

Miscellaneous

Further Reading

Maps in ES6 - A Quick Guide

Overview

Map API Summary

Usage

Should I use a Map or an Object?

Details & Caveats

What is equal?

Non-existant keys

Building from Objects

Weakmaps

Where to use WeakMaps over Maps

Symbols in ES6 - A Quick Guide

Overview

Usage

Usage without objects

Details & Caveats

Global Symbols

"Well Known" Symbols

No auto conversion to String

When are they copied?

Further Reading

Sets in ES6 - A Quick Guide

Overview

Set API Summary

Usage

Special snowflake

Iteration

Should I use an Set or a Array?

Details & Caveats

What is equal?

Using Array methods

WeakSet