DEV Community: Ryan Boone

Misadventures in web components

Ryan Boone — Mon, 17 May 2021 00:18:06 +0000

I have been thinking about web components a lot lately, and I wanted to see how we could start using them at The Container Store. The idea was to pick a simple component and recreate it as a web component, and the first candidate that came to mind is our frequently-used quantity stepper. The stepper appears in several places throughout the website, and it's dependent on an embarrassing amount of jQuery.

Here's my humble first attempt:

The result isn't perfect, but I gained a better understanding of web components, their limitations, and where they're useful.

Lessons learned

My ultimate goal was to create a web component that progressively enhanced from a run-of-the-mill number input to a custom element. I also wanted to explore the limitations of web components inside a form. What I ended up with was this weird solution that sidesteps the shadow DOM altogether.

Progressive enhancement...sort of

The experimental component requires a donor number input, either as a child of my-stepper or, my preference, via a data-is attribute on a native input[type=number]. This is my naive version of customized built-ins, which I suspect would be perfect for this particular situation.

The reason for the hand-rolled functionality is because Safari doesn't support customized built-ins, nor do they intend to anytime soon¹. I will probably swap out my custom data attribute solution for a polyfill that supports the native is attribute when implementing in production because this is not implemented to spec.

The my-stepper's template inserts child content in between two buttons wired up with click listeners. The listeners increment or decrement the value of the input (if present). The interesting thing about template slots is their content remains in the light DOM, making them completely accessible to the parent form.

The result ensures that the input remains an input if JavaScript is disabled or (more than likely) takes a while to load, parse and execute².

Native form functionality

The shadow DOM encapsulates style and markup, but that comes at the cost of accessing field data in form field web components. Shadow DOM field values aren't registered in form.elements and shadow fields cannot participate in the form lifecycle (e.g. field validation) by default.

If you need to access field values, you can use a hidden input or listen for the formdata event on the parent form. Both strategies ensure you can pass data properly on submit, but neither will give you full access to the form lifecycle.

The ElementInternals interface, however, officially grants web components access to the lifecycle of a parent form, including methods to determine the field's value and validity:

class MyElement extends HTMLElement {
  constructor() {
    this.internals = this.attachInternals();
    // use internals to set the form field value, 
    // determine valid data, etc.
  }
}

In addition to gaining access to the form lifecycle, the ElementInternals specification grants access to the accessibility object model. Only Chrome and Chromium-based browsers support internals at the time of this writing, but, again, there are polyfills.

Accessibility

I learned that elements within the shadow DOM will still receive focus and are properly announced via a screen reader out-of-the-box (curiously, VoiceOver announces shadow DOM barriers as a new frame, at least at the time of this writing). I guess it acts sort of like an iframe in that respect?

One concern I had, though, was how to reference an ID in the shadow DOM with a label in the light DOM. Unfortunately, shadow DOM ID reference is not possible, at least not natively. There have been discussions about somehow delegating labels via an option passed to attachShadow, but I haven't seen anything regarding implementation.

The only thing I found that works with the shadow DOM is determining the input's label(s)³, then adding click listeners to each that imperatively focus the shadow DOM target:

const template = document.createElement('template');

template.innerHTML = `
<input name="name" />
`

class MyInput extends HTMLElement {
  static get formAssociated() {
    return true;
  }

  constructor() {
    super();
    this.attachShadow({mode: 'open'});
    this.shadowRoot.append(template.content.cloneNode(true));
    this.internals = this.attachInternals?.() || {};
  }

  connectedCallback() {
    this.internals.labels?.forEach((label) => {
      console.log(label)
      label.addEventListener('click', () => {
        this.shadowRoot.querySelector('input')?.focus();
      });
    });
  }
}

customElements.define('my-input', MyInput);

Hey, check it out, we're exercising the ElementInternals API! That didn't take long.

Note that we have to first specify that an element is form-associated with the formAssociated static property, then we can access the form-related internals. Also, note that we have to attach the click listeners in the connectedCallback method instead of the constructor (which is what I attempted at first)⁴. Form association only happens after the element has attached to the DOM, so this.internals.labels is null in the constructor.

Styling

There are several ways to customize web component styles. For this experiment, I'm opening up custom styling via shadow parts and the ::part() CSS pseudo-element. I think this strategy works for this particular instance since there are only three pieces that need to be styled: the two buttons and the wrapper.

The ::part() pseudo-element takes an identifier that is assigned with the part attribute:

<button part="decrement control">&minus;</button>
  <slot>CHILD CONTENT</slot>
<button part="increment control">+</button>

my-stepper::part(control) {
  /* styles here */
}

Note that you can pass multiple identifiers to part. I'm using this feature to allow consumers to style both buttons with the control shadow part and the individual buttons with their respective shadow parts.

Shadow parts may not scale that well with more complex elements, and I haven't tested how they would work on child web components (web components nested in a web component shadow DOM).

Final thoughts

As I mentioned earlier, I think the next step is to redo this component as a customized built-in and let a polyfill or library do all the heavy lifting. I'm curious to see what role, if any, shadow DOM plays in that particular type of web component.

I'm also interested in exploring LitElement and Stencil.js, particularly how they would integrate with our current stack. My ultimate goal is to make web component creation as easy and gotcha-free as possible, and libraries help normalize some of the weirdness you may get with a low-level API like web components.

I had a ton of fun messing around with web components, and I learned a lot as well. If you found this helpful or have something you'd like me to write about, let me know. I enjoy doing these experiments and hope to deep dive even more into web components in the future.

Until next time!

Resources

More on web components and the accessibility object model: https://www.24a11y.com/2019/web-components-and-the-aom/
Best practices: https://developers.google.com/web/fundamentals/web-components/best-practices
Follow the latest in web components: https://www.webcomponents.org
A nice overview of web component criticism: https://blog.logrocket.com/what-happened-to-web-components/

Safari engineers argue that customized built-ins violate the Liskov substitution principle. Given the fact that this custom stepper will only support an input[type=number], I believe they're probably right. But also, HTMLInputeElement is the element API equivalent of a dumpster fire. ↩
Yes, the site should just run faster, I agree. Baby steps. And in an ideal world, we would pre-render shadow DOM on the server and hydrate it client-side. Currently, shadow DOM is imperative-only, so there's no way to render on the server, but there is a proposal for declarative shadow DOM, something I hope to write about soon. ↩
Remember, labelable elements can have more than one label. ↩
It's a good idea to always run your side effects like attaching listeners inside connectedCallback, even if you have access in the constructor. And make sure you clean up any listeners in the disconnectedCallback method. See the resources section for a link to web component best practices. ↩

Native form validation with JavaScript

Ryan Boone — Sun, 28 Mar 2021 02:19:39 +0000

You don't need to install a validation library to create rich client-side form validation experiences. HTML5's native client-side form validation is widely-supported and easy to implement, and while its default functionality is limited, the native Constraint Validation API allows for custom behavior with JavaScript.

Enter the humble login form

Let's build a login form. We'll use an input for email, password, and a submit button:

<!-- login.html -->

<form id="login-form" action="/api/auth" method="post" >
  <div>
    <label for="email">Your Email</label>
    <input id="email" type="email" name="email" />
  </div>
  <div>
    <label for="password">Your Password</label>
    <input id="password" type="password" name="password" />
  </div>
  <div>
    <button>Log In</button>
  </div>
</form>

That's a pretty bare-bones login form. There are two inputs, one with a type of email, the other with a type of password, and a submit button. The form posts to an endpoint that handles the login process on the server¹.

Even though we haven't yet done anything to the form, it already has some client-side validation built in, thanks to the email input. If you were to enter an invalid value into the email field and submit, you would see something like this (screenshot from Chrome):

The browser has blocked the submission of data, focused the first invalid field, and now we see an error message describing the issue. We have email validation, and at no point did we type npm install and download half of all known JavaScript dependencies.

There is a problem, though. If you submit with both fields left blank, the form submits as valid, but our backend script requires both fields.

Requiring fields

There's an easy fix for the valid blank fields. Let's add the required attribute to both the email and password inputs.

<!-- login.html -->

<form id="login-form" action="/api/auth" method="post" >
  <p>
    <label for="email">Your Email</label><br/>
    <input id="email" type="email" name="email" required />
  </p>
  <p>
    <label for="password">Your Password</label><br/>
    <input id="password" type="password" name="password" required />
  </p>
  <p>
    <button>Log In</button>
  </p>
</form>

Now submitting without an email or password will look something like this (again, screenshot from Chrome):

So far, so good. Who needs JavaScript?

Styling error state

You might want to style your error state to draw more attention to fields with issues. We can do that by using the :invalid CSS pseudo-class.

/* login.css */

input:invalid {
  border-color: hsl(351, 100%, 27%);
}

Now we see the first issue: HTML forms run validation immediately. By default, both the email and password fields are blank, and since they are required, they immediately render invalid. Boo!

Ideally, we would want the fields to appear valid until a user attempts to enter a value. We could choose either to validate on blur or wait until the user tries to submit the form. Either way, we want to validate invalidated fields as their values update to ensure the quickest feedback possible.

Sadly, we have reached the limits of default HTML client-side form validation. But fear not! We have access in JavaScript to all that validation goodness in the form of the aforementioned Constraint Validation API.

Validation, final form

The Constraint Validation API gives you complete access to the built-in validation we've been using up to this point but with more control. The first rule of Constraint Validation, much like Fight Club, is to not talk about validation:

// login-validate.js

const form = document.getElementById("login-form");

form.noValidate = true;

Setting noValidate turns off the native client-side validation, freeing us up to do whatever we want. Turning off validation with JavaScript ensures the default validation still runs if JavaScript never executes for whatever reason. It also prevents showing our invalid style preemptively.

The first thing we should do is run validation when the form is submitted. To validate the entire form, use the form method reportValidity:

// login-validate.js

const form = document.getElementById("login-form");

form.noValidate = true;

form.addEventListener('submit', function handleFormSubmit(event) {
  const isValid = form.reportValidity();

  if (isValid) {
    // POST form data to backend with fetch
  }

  event.preventDefault();
});

reportValidity runs the form validation, returns true or false based on whether or not the form is valid, and reports any validation errors to the user. We can use the return value to determine whether or not to post to the backend.

Marking invalid inputs

Before taking the validation reins we could tie into the convenient :invalid pseudo-class to style invalid fields, but now that's no longer an option. Let's fix that next.

When reportValidity runs, it will dispatch an invalid event for each invalid field. This event is cancellable, but it doesn't bubble, which means we'll have to register an event handler on each element in the form:

// login-validate.js

// ...

for (const field of form.elements) {
  field.addEventListener("invalid", function handleInvalidField(event) {
    field.setAttribute("aria-invalid", "true");
  });
}

This will add the aria-invalid attribute to invalid elements, which not only communicates validity state to accessible technology, it gives us a new hook for our invalid styles².

/* login.css */

input:invalid,
[aria-invalid=true] {
  border-color: hsl(351, 100%, 27%);
}

Whenever I can, I try to tie style to semantics. This helps communicate the importance of the selector's existence and avoids unnecessary styles that may not be that reusable outside of the current context.

The styles work now, but they remain even after the input becomes valid. Before we can correct that, there's another problem we need to solve.

Our new validation pattern

We need to talk briefly about how we want this custom validation to work. Luckily for us, form error UX is well-researched. For this example, I'm referring to guidelines published by the Nielsen Norman Group.

Here's a quick summary of the plan:

Each field will first validate on the blur event. This will avoid displaying warnings too early.
Once a field has been visited initially, it will validate on user input. Immediate feedback helps users verify the information they've entered is correct. This also addresses the invalid style issue we currently have.
Errors will be displayed alongside the field. We'll replace the default error tooltips with inline messages that remain on screen as long as the field is invalid.

First I'll add the validation on field blur. We'll add that to our previous field level JavaScript:

// login-validate.js

// ...

for (const field of form.elements) {
  // previous code
  field.addEventListener("invalid", function handleInvalidField(event) {
    field.setAttribute("aria-invalid", "true");
  });

  // new
  field.addEventListener("blur", function handleFieldBlur() {
    field.removeAttribute("aria-invalid");
    field.checkValidity();
  });
}

When a field element dispatches a blur event, we optimistically remove the aria-invalid attribute and then run checkValidity, which does everything reportValidity does except report validation errors to the user. We'll handle error reporting ourselves later.

Next, we need to run validation on user input, but only after a field has been previously visited. For that, we'll need some local state.

Validating on user input

For tracking fields that have been visited, we'll use a simple JavaScript array. Once a field has been visited, we'll push it into the array. To check for visited status, we query the array to see if the field is included.

// login-validate.js

// ...

// new
const visited = [];

// ...

for (const field of form.elements) {
  // ...

  field.addEventListener("blur", function handleFieldBlur() {
    // new
    if (!visited.includes(field)) {
      visited.push(field);
    }

    // REMOVED field.removeAttribute("aria-invalid");
    field.checkValidity();
  });

  // new
  field.addEventListener("input", function handleFieldInput(event) {
    if (!visited.includes(field)) return;

    if (!field.validity.valid) {
      field.setAttribute("aria-invalid", "true");
    } else {
      field.removeAttribute("aria-invalid");
    }
  });
}

Here we have added a visited array and are adding fields to it inside handleFieldBlur. We're also removing the aria-invalid attribute code since it's now handled in the new input handler.

Inside the input handler, we prevent validation from running before the field has been visited with a short circuit. We check the field's validity using its ValidityState, which is a handy object that contains everything related to field validation. More on that in a bit.

At this point, the desired validation behavior is done. The final thing we need to do is add custom error styling.

Custom inline errors

The current error messages only show up on a submission attempt and have the default tooltip styling. We want to show the errors directly underneath the invalid fields and update them on blur and user input. We need to first create containers for the error messages.

<!-- login.html -->

<form id="login-form" action="/api/auth" method="post" >
  <div>
    <label for="email">Your Email</label>
    <input id="email" type="email" name="email" 
          aria-describedby="email-error" /> <!-- new -->
    <span id="email-error"></span> <!-- new -->
  </div>
  <div>
    <label for="password">Your Password</label>
    <input id="password" type="password" name="password" 
          aria-describedby="password-error" /> <!-- new -->
    <span id="password-error"></span> <!-- new -->
  </div>
  <div>
    <button>Log In</button>
  </div>
</form>

The important thing to notice in the above markup is we've added an aria-describedby attribute to both inputs. This attribute ensures that screen readers associate each error message with its respective input. When an invalid input is focused, the screen reader will announce the input's label and type, pause briefly, then announce the error³.

We now need to populate the error containers with the appropriate error messages. Luckily the input fields have access to their validation messages:

// login-validate.js

// ...

for (const field of form.elements) {
  field.addEventListener("invalid", function handleInvalidField(event) {
    errorContainer(field).textContent = field.validationMessage; // new
    field.setAttribute("aria-invalid", "true");
    event.preventDefault(); // new, prevents default validation errors
  });

  // ...

  field.addEventListener("input", function handleFieldInput(event) {
    if (!visited.includes(field)) return;

    if (!field.validity.valid) {
      errorContainer(field).textContent = field.validationMessage; // new
      field.setAttribute("aria-invalid", "true");
    } else {
      errorContainer(field).textContent = ""; // new
      field.removeAttribute("aria-invalid");
    }
  });
}

// new
function errorContainer(field) {
  const errorContainerId = field
    .getAttribute("aria-describedby")
    .split(" ")
    .find((id) => id.includes("error"));
  return document.getElementById(errorContainerId);
}

Before we go any further, it looks like every time we set the error container text, we also set the aria-invalid attribute on the field. Let's clean this logic up by moving it into a function.

// login-validate.js

// ...

for (const field of form.elements) {
  field.addEventListener("invalid", function handleInvalidField(event) {
    setFieldValidity(field); // function-ified
    event.preventDefault();
  });

  // ...

  field.addEventListener("input", function handleFieldInput(event) {
    if (!visited.includes(field)) return;
    setFieldValidity(field); // here too
  });
}

// ...

// new
function setFieldValidity(field) {
  if (!field.validity.valid) {
    errorContainer(field).textContent = field.validationMessage;
    field.setAttribute("aria-invalid", "true");
  } else {
    errorContainer(field).textContent = "";
    field.removeAttribute("aria-invalid");
  }
}

Here's what our custom errors look like now when we try to submit with blank inputs (I'm adding the red "X" with CSS):

Better form validation

At this point, there are some rough edges, but it's working more or less as we want it to. One annoying thing is in Chrome validation messages get wordy. You can substitute a custom validation message based on the type of validation error is associated with the field. I'll leave that as an exercise for you.

This exploration only looked at required fields and email pattern validation, but there are a variety of validation criteria built into browser validation. Like the email input type, there are several other input types with built-in validation, as well as ways to limit the range or length of an input's value, and a pattern attribute that gives you even more control over input validation for certain types of inputs.

Keep exploring

I hope this post has inspired you to explore the Constraint Validation API. Taking advantage of native APIs improves frontend performance and moves complex logic off of your plate. Use them whenever possible.

Do you like Web APIs? What's your favorite? Which one mystifies you? Let me know on DEV Community or Twitter. And if you enjoyed this post, let me know by liking it on DEV Community and giving me a follow.

Until next time, keep exploring!

Our imaginary backend script also validates and sanitizes the data posted from the form. Client-side validation is a user experience enhancement. Never trust user-generated data and always validate on the server. ↩
To learn more about ARIA attributes, roles, and relationships, check out the WAI-ARIA specification. ↩
aria-describedby can take multiple IDs separated by spaces (aria-described="first-id second-id third-id"). This is helpful if you have instructions associated with an input, like password constraints. ↩

Hold off on optimizing JavaScript performance

Ryan Boone — Wed, 10 Mar 2021 23:07:14 +0000

As a developer, I love optimizing performance. Learning efficient algorithms makes me feel like a software engineer. But performance is not the only developer concern, nor should it be the first or second. David K. Piano recently pointed this out on Twitter, offering up a suggested framework:

Make it work
Make it always work
Make it work for everyone
Make it right
Make it fast

David's suggestion expands on a well-known programming maxim attributed to Kent Beck, Make it work, Make it right, Make it fast. What does that mean? I want to take some time to expand on each layer.

Make it work

Making working code is the first concern. This step may seem obvious, but there are a few things to consider as you make the code work.

First, consider a test-driven development approach. At the very least, wrap your code in tests as you write. This will make the rest of the process faster and ensure you don't break core functionality.

Second, don't worry about writing pretty code. If you find yourself debating what to name a variable, call it thing1 and move on. Use formatting tools like Prettier to avoid thinking about white space and semicolons.

Finally, try to go fast here. You only need working code. If you hit a roadblock, start over. Writing sloppy code at the beginning can help you arrive faster at a better solution.

Make it always work

Now we shift our attention to edge cases, cases involving less-common or unique data sets. These are the areas where bugs tend to show up. Here are some scenarios you might want to consider:

No data
A single piece of data
The maximum amount of data
One less than the maximum amount
Bad (malformed) data

If your code involves asynchronous calls:

Rejected promises
A promise that never resolves
Slow responses
Immediate responses

Again, take the time to write tests. Whether you follow test-driven development or write tests after the fact, they will be invaluable as you move up the layers of concerns.

Make it work for everyone

JavaScript is a funny language in that you can never be sure of the execution environment. Identify your feature's core functionality and make sure it works in a wide variety of browsers. Having a list of your code's official browser support helps in this step.

There are two approaches to supporting multiple environments: progressive enhancement and graceful degradation. Both involve detecting feature support, but progressive enhancement adds functionality while graceful degradation removes functionality.

Both approaches are viable in different scenarios, and which you use depends on the context of the functionality.

Make it right

The next layer of focus is making the code right. Right means making the code readable and maintainable. All of the tests written up to this point pay off by giving you confidence that functionality remains.

Developers read code much more than write it, so taking the time to make your code readable will help your colleagues and your future self. Readable code is more maintainable and extendable. The small cost of refactoring now can have an exponential impact on future project development.

Focus on small changes that make a noticeable impact. Use domain-specific variable names, ensure your functions are in the correct scope, use comments as indicators for creating functions. I recommend reading Martin Fowler's excellent book Refactoring for more specific guidance and practical advice.

Make it fast (if needed)

After we've made the code work, considered edge cases, added fallback support, and made the code readable, we finally optimize performance. Maybe.

The first rule from the Rules of Optimization is don't optimize. If you must optimize, however, there are a few things to keep in mind.

First, make sure you are testing production code. Many frameworks bolt-on functionality and tools that help the development process but hinder performance. Production builds exclude this extra functionality, so ensuring you are testing in the right environment keeps you from optimizing performance unnecessarily.

Next, you need to get baseline measurements. These will ensure that your optimizations worked. If possible, emulate slow internet connections and throttle CPU speed, two features Chrome's devtools offers.

One thing to keep in mind as you optimize is how your optimizations may affect the readability and maintainability of code. Usually, the most optimized solution is nowhere near the most readable. Always favor readable code.

Summary

Performance optimization makes sense to developers because it's something that's easily measured. Optimizing code may be a more attractive goal than finding edge cases or making code more readable but should be avoided until the end of the process. Optimizing at the very end forces developers to focus on writing working, maintainable code.

So, thanks for making it to the end! If you found this helpful, please let me know by liking this article on DEV Community and following me to know when I post a new article. And ask me all the questions you'd like (preferably about this article, but no judgment) on Twitter.

Until next time!

What I learned blogging daily for a month

Ryan Boone — Thu, 04 Mar 2021 18:05:40 +0000

I recently challenged myself to write a blog post every day for a month. Up to that point, I had only written eight blog posts for two years. A month later, not only do I have 28 new blog posts, I've learned some valuable lessons about my blogging process and my website. I wanted to share things about the experience that worked for me and issues I discovered that need attention.

Worked: Setting deadlines

It's surprising how an unmoving date can motivate you to complete a post. One of my recurring issues with blogging has been the tendency to overwork a piece until I completely lose interest. Experience has taught me that time is the biggest enemy of posting, and firm deadlines force you to throw away what's not working and focus on what is.

Being accountable to others dramatically increases the power of deadlines. One of my blogging rules involved announcing in my Twitter feed that I was posting daily. In my mind, I felt like I was accountable to a large audience. Social pressure works, even if it's imaginary¹.

Worked: Having a healthy backlog

In the middle of February, we experienced the second coldest temperatures ever recorded in North Texas (-2℉, -17℃). That may not be cold for some of you reading this, but our state's infrastructure is poorly prepared for temperatures that cold. Power generation froze up, and several utility buildings lost power, including our water station. Some were without power and water for a week.

I barely wrote during that week, yet I stayed on schedule thanks to my backlog, a running list of ideas in Notion that I use to build out full posts. Sometimes an article I've been working on just isn't working, so it's nice to have a safety net.

Worked: Cross-publishing on DEV

I decided at the suggestion of Stephanie Eckles to cross-publish to DEV Community. Cross-publishing ended up being a great decision because DEV's platform exposed me to a bigger audience than I ever would've received on my blog. Coupled with the motivation and encouragement I received from comments and reader interaction, I've decided to continue doing this for all posts.

There are, however, some challenges I've found cross-publishing, mainly due to differences in platforms. My site is built in Eleventy, and my front matter formatting doesn't completely align with DEV's. There are also differences in how I mark up embedded content. If you notice, hardly any of my posts have CodePens embedded, and I didn't use any images.

Now that I have some time, I'm going to start ironing out these issues, starting with images. That's a topic I need to address on my site first, which brings me to my first thing that didn't work.

Did not work: My website styling is lacking

In terms of my blog, falldowngoboone, I discovered many rough edges throughout the month. One such issue that comes to mind is an excerpt filter I created², which unfortunately doesn't process Markdown properly. If anything in the first 20 words of a post contains Markdown, it's not processed, and if there are any special characters, they are escaped.

It also appears some of the code blocks that Notion produces use a syntax I don't support. I know that may not seem like a big deal, but it's broken syntax highlighting on my site. This should be an easy fix.

Finally, my home page needs an overhaul. When I had only eight posts, it was easy to find them. Now, it's getting a bit ridiculous. I plan to completely change the homepage design, featuring the most popular articles, my most recent posts, and a link to post archives. I may even add a search (gasp!) at some point.

Did not work: My publishing process sucks

Near the end of the month, I wrote about how I write my posts, and I briefly mentioned some ideas I had for optimizing my publishing flow. Currently, I walk through at least 18 different steps to publish a single blog piece. I think better tools and well-planned automation can reduce those steps.

Notion, as I'm currently using it, doesn't fit with my publishing process. Unfortunately, its exported Markdown output doesn't align with the format I use in Eleventy. It would be nice if Notion offered a way to tweak the export formats, but I understand that constraints like this are necessary to allow flexibility in other areas.

One idea I have is to write a script that could convert the exported metadata into front matter. Another idea is to change to a full content management solution, like Sanity. Scripting a solution would mean I could keep using Notion, with the downside of maintenance. Using Sanity would give me a streamlined publishing solution with little toil. I'm still weighing my options here (and I'll make sure to write about whatever choice I make).

Finally, there are areas of my process best suited for automation. My article backlog includes a status flag (Planned, In Progress, and Published³). I'd love to figure out a way to automate In Progress when I schedule the piece and Published once the post has merged.

What next?

I will not continue to blog daily, as insightful as it's been. But I will focus on creating blog posts at a regular frequency, at least once a week. I hope to improve my communication skills and connect with more amazing people through DEV Community.

Finally, if you're thinking about blogging, do it. Don't worry about whether or not you have something to say. When I began blogging, I was afraid I wouldn't have anything to say. Now I can't stop writing.

That's it for now. If you found this helpful, please let me know by liking this post on DEV Community and following me so you know when I publish. And if you have any questions, don't hesitate to reach out to me on Twitter.

Until next time!

Share variables between JavaScript and CSS

Ryan Boone — Mon, 01 Mar 2021 02:16:29 +0000

Whether you need site breakpoints for matchMedia or access to theme colors, sharing values between your JavaScript and CSS is sometimes unavoidable. The easiest solution is to copy and paste values, but how can you ensure values stay synchronized when that brand blue color changes to indigo?

The answer is to create a single source of truth by sharing values between the JavaScript and style layers. There are several ways to accomplish this, and the best approach for a project depends on its frontend stack. Here are all of the ways I know how to pass data back and forth between all the layers.

ICSS

CSS Modules, gives us two ways of sharing variables, the Interoperable CSS (ICSS) spec and the PostCSS Modules Values spec. ICSS appears to be the older of the two specifications, so I'll start there.

ICSS is a low-level specification that's mainly for loader authors. It describes how to treat CSS modules as JavaScript dependencies and introduces the :export directive to act as a way to export defined values. Coupled with Sass variables, it allows you to export theme values:

// colors.module.scss
// assuming this is within Create React App; the `.module` lets CRA know
// this is a CSS Module

$my-red: #ff0000;

:export {
  myRed: $my-red;
}

The exported values are imported like much like any other JavaScript module:

// MyComponent.js
// assuming this is within Create React App

import * as React from 'react';
import * as colors from 'theme/colors.module.scss';

export function MyComponent() {
  return <p>myRed's value: {colors.myRed}</p>
}

The above should work in Create React App out of the box. If you are rolling your own Webpack configuration (may God have mercy on your soul), you'll need to configure modules with a compileType of icss:

module.exports = {
  module: {
    rules: [
      {
        test: /\.css$/i,
        loader: "css-loader",
        options: {
          modules: {
            compileType: "icss",
          },
        },
      },
    ],
  },
};

CSS is the source of truth
Great solution if you're using Create React App
Webpack configuration could be a challenge
Aimed more at library authors than app developers
Non-standard CSS

Setting `@value`

CSS Modules also offers the @value directive, which explicitly defines module values. @value can also be used to import values from other CSS modules. It's a catchall solution for passing values to and from CSS modules to anywhere.

// breakpoints.module.css

@value larry: (max-width: 599px);
@value moe: (min-width: 600px) and (max-width: 959px);
@value curly: (min-width: 960px);

// MyComponent.module.css
// this is one of the multiple ways you can import @value definitions
// see https://github.com/css-modules/postcss-modules-values

@value larry, moe, curly from "theme/breakpoints.module.css";

@media larry {
  ...
}

@media moe {
  ...
}

@media curly {
  ...
}

// MyComponent.module.js

import * as React from 'react';
import Media from 'react-media';
import { larry, moe, curly } as bp from 'theme/breakpoints.module.css';

export function MyComponent() {
  return (
    <Media queries={{ larry, moe, curly }}>
      {matches =>
        matches.larry 
          ? (
            <p>Oh, a wise guy, eh?</p>
          ) 
          : matches.moe ? (
            <p>Why I outta...</p>
          ) : (
            <p>Nyuk nyuk</p>
        )
      }
    </Media>
  );
}

CSS is the source of truth
Easy to implement in Create React App
Again, Webpack (meh)
Appears to be more of a dev-friendly solution
Allows you to share values between CSS modules
Non-standard CSS

Sass compiler

Sass's JavaScript API can add custom functions by defining the functions option of render. You can use this to define getter functions that return your theme's values directly in Sass. I implemented this on our website using node-sass, which exposes the functions option in its CLI:

node-sass src/styles/ -o build/styles --functions path/to/sass-functions.js

And the sass-functions.js file looks like this:

// sass-functions.js

const sass = require('node-sass');
const theme = require('../theme/index.js');

module.exports = {
  'getColorMap()': function () {
    return Object.entries(theme.colors).reduce(
      toSassMap,
      new sass.types.Map(Object.keys(theme.colors).length)
    );
  },
  'getMqMap()': function () {
    return Object.entries(theme.mqs).reduce(
      toSassMap,
      new sass.types.Map(Object.keys(theme.mqs).length)
    );
  },
};

function toSassMap(list, [key, value], idx) {
  list.setKey(idx, new sass.types.String(key));
  list.setValue(idx, new sass.types.String(value));
  return list;
}

Note that I'm having to define Sass types. The getColorMap() and getMqMap() functions return Sass maps that include all of our theme variables. Very handy!

Unfortunately, LibSass, the core engine of node-sass, has been deprecated, along with node-sass. The canonical Dart version of Sass lacks a nice CLI option for custom functions. If you want to recreate this functionality, you're stuck building a compiler using Dart Sass's JavaScript API.

JavaScript (or JSON) is the source of truth
Requires Sass
Easy to implement with node-sass, but it's deprecated¹
You have to role your own compilation if you want to define custom functions in Dart Sass

CSS-in-JS

A common variable sharing solution in React is to simply let JavaScript do all the work. And as controversial as CSS-in-JS seems to be, it presents an easy way to share variables simply because you are defining CSS in a JavaScript file.

Here's how you might share a variable in the library Emotion:

import { css, cx } from '@emotion/css';
import * as colors from './theme.colors.js';

render(
  <div
    className={css`
      color: ${colors.primary};
      &:hover {
        color: ${colors.secondary};
      }
    `}
  >
    I get so emotional, baby.
  </div>
)

I mean, it's easy. It's so easy that I'd debate whether or not this is classified as sharing variables between JavaScript and CSS, but I'm throwing it in anyway.

I've already mentioned Emotion, but other CSS-in-JS libraries to check out include Styled Components, JSS, Theme-UI, Radium, and Aprhodite.

JavaScript (or JSON) is the source of truth
Good option for shared React component libraries
Requires JavaScript to apply styles (no JS, no styles)
Non-standard CSS

Custom Properties

If you need a lightweight, "proper" way to share variables between JavaScript and CSS, look no further than Custom Properties. Custom Properties allow you to create arbitrary CSS properties and set them to any value you want.

:root {
  --color-brand: #BADA55;
  --color-secondary: #005DAB;
}

import * as React from 'react';

function MyComponent() {
  const brandColor = getComputedStyle(document.documentElement)
    .getPropertyValue('--color-brand');

  return <p style={{ color: brandColor }}>I'm brand color!</p>
}

If you access these properties a lot, you may want to create a utility function to save on typing:

function cssValue(property) {
  return getComputedStyle(document.documentElement)
    .getPropertyValue(property);
}

Custom Properties are completely standard CSS spec, and this is the only solution that is dynamic, meaning properties can change based on context:

:root {
  --color-brand: #BADA55;
  --color-secondary: #005DAB;
}

@media (prefers-color-scheme: dark)
  :root {
    --color-brand: white;
    --color-secondary: #ccc;
  }
}

When you access those properties, they'll be different depending on the user's preferences. This is incredibly powerful.

CSS is the source of truth
Context-specific (CSS updates custom properties live based on the context)
Easy to implement
Not supported in Internet Explorer 11, but you can sort of polyfill it
Can't use Custom Properties for breakpoints 😩
Standard CSS

Lots of options

Sharing variables between CSS and JavaScript can help reduce toil and cut down on unintentional tech debt. And if you need to, you have no shortage of options. Just make sure you understand what you want to act as the source of truth and know your technical requirements.

If you found that helpful, please let me know by liking this post on DEV Community and sharing it. And if you want more articles like this, make sure you follow me on Twitter so you'll know when I post new ones.

Until next time!

Trust me when I say you should not use node-sass. It's so buggy that it can't process newer CSS. ↩

How I write my posts

Ryan Boone — Sat, 27 Feb 2021 20:13:50 +0000

I've been posting a new article every day this month, and it's been interesting. I'll write about that soon, but today I want to share how I put these posts together. Hopefully, you'll learn something new from my process, or see how terrible my process is and give me some advice.

Idea backlog

If you're going to create content, you need a steady stream of ideas. I keep a backlog so I can store notes, write drafts, and constantly reassess what to post next. This post you're reading? It started out in my backlog.

You can keep an idea backlog in whatever tool you use. I use Notion for a few reasons. First, I can access Notion on anything that's connected to the internet, so I can capture an idea before I forget it. Second, Notion gives me the flexibility to organize my content however I want.

For Blogruary, I created a special post in Notion with a list view of all posts tagged "blograry" (each view can have its own special filtering and sorting). This allows me to get a quick look at all the ideas available to me.

For more information on using Notion as a project manager, check out this Notion masterclass video from Thomas Frank.

Writing the post

After adding an idea to the backlog, I paste links to relevant material as well as notes into the created entry. This eventually becomes the blog post itself. Depending on how far along the information is, I'll go ahead and schedule the publish date.

If I'm being honest, this process has been all over the place. Sometimes I'll start the post without any notes, or the post is a long list of notes until the day I have to post. Many times I'm stuck writing and editing the entire post the day I'm supposed to publish (like today).

I've also noticed some issues with writing blog posts in Notion, mainly because of all the manual changes I have to make to the exported Markdown. I'm still trying to figure this part of the process out.

Publishing

After I've written a post, I'll export it from Notion as Markdown, drop it into my blog's source code, and manually format the front matter for Eleventy. Unfortunately, Notion doesn't output front matter, nor does it allow me to customize how associated data is displayed. This would be a welcome feature.

I've started to run the post content through Grammarly to correct any grammar mistakes. Grammarly has extensions for all the major browsers, as well as a desktop app that allows you to create a new document for analysis (big thanks to Stephanie Eckles for that tip). It's free to use the basic features, but I'm considering upgrading.

After making corrections in Grammarly, I'll paste the corrections back into the Markdown file in VS Code, commit the changes, and push them up to GitHub.

After creating a pull request, Netlify runs a series of checks. While that happens, I create a duplicate of the post on DEV Community. I have to add a canonical URL back to my website so I don't get penalized for duplicate content, but in order to do that, I need to publish on my personal blog first.

By the time I've set up a draft in DEV, my pull request has been verified and is ready to merge. The merge kicks off a deployment to Netlify (yay Netlify!). After merging, I grab the post's URL, add it to the DEV post, then I hit publish.

Thoughts on the process

So that's what I've been doing this entire month. I learned that Notion is a great tool for organizing and writing, but I need a tool that's closer to the end product. I'm starting to look at Sanity as a viable option.

I've also been thinking about streamlining the publishing process by automating the duplicate post to DEV. Challenges include differences in front matter and markup. If I can limit myself to only shared markup, that would make the automation much easier.

Finally, if you're thinking about starting a blog, a good place to start is signing up for the Blogging for Devs newsletter from Monica Lent. New subscriptions start with a 7-day blogging course sent directly to your inbox, followed by regular emails filled with tips for content makers.

I will be expanding on the rest of what I've learned in a future post, so if you want to know when that comes out, follow me on Twitter. And if you found this post helpful, please let me know by liking it on DEV Community.

Until next time!

Understand the context of code you copy

Ryan Boone — Fri, 26 Feb 2021 23:43:14 +0000

If a problem is too difficult to solve on our own, sometimes the only course of action is to search, copy, and paste. It's something all developers have done regardless of their experience level.

While there is no shame in copying and pasting code, it can lead to a mess. That's why I have one copy-paste rule that I follow: understand the context.

A reason for everything

Requirements, constraints, and assumptions all play a role in how we write code. Unless you've found a generic solution, the code you copy comes with a context that may not apply to your situation.

The wrong context could cause you to miss story requirements or cause other code to break (e.g. variable name collisions). Taking time to understand the context can help save you and your teammates a headache down the road.

Learning the context

Throughout my experience of dealing with copied and pasted code, I've seen a few common problems. These can be avoided by asking yourself some questions as you carefully read the code.

Does this code rely on global state? This is a common issue with legacy JavaScript codebases that rely on the global Window object to pass data and functions around. If you can, move this code out of global scope. It will help you answer the remaining questions.
Is there anything that looks unfamiliar? Are there APIs used that don't look familiar to you? Look them up and make sure you understand what they are used for and why. Identifying unfamiliar APIs and methods informs the code's context, but it's also an opportunity for you to learn something new.
Is there anything unnecessary? Dead code in a large codebase is scary. No one will touch it, either out of fear or because of the amount of work involved in tracking down usage. Hastily copying and pasting dead code multiplies this tech debt immeasurably. Trim unused code.
Do variable names match the domain? If you're copying from an online source, variables will tend to have generic names. Taking the time to find better names helps the code communicate better, and captures the context.
Does this code have any dependencies? There are swaths of our codebase that use Require.js and therefore...require...it to be present. Sometimes it's better to remove the need for that dependency by copying and pasting even more code, and sometimes it's better to add the dependency. It all depends on the context (ah, see what I did there?).
Are there any new errors logged after pasting? The moment you paste code into your codebase, you should check your logging. This reduces the dev feedback loop and informs you of any incompatibilities immediately.

This looks like a lot of work

You may be thinking, Geez, Ryan, this sounds like it's going to take forever, and the reason I'm copying and pasting code is to save time. And you're right, this will add time to your solution. But that extra time will ensure that you solve the right problem, meet requirements, and reduce tech debt.

Copying existing code can supercharge your team's velocity, but remember this comes with a cost. If you don't slow down and ask questions, chances are you'll pay the price further down the road, and you'll lose any short-term gains over the long term.

Take the time to save time

Sometimes copying and pasting existing code is the best course of action. But before do, take the time to understand and adapt the context. The time you spend will save you in the long run.

If you're still reading this, thanks for sticking around to the end! Unless you just skipped to the end. In which case, thanks for at least reading this? If you found this post helpful, please consider liking over on DEV Community, and make sure you follow me so you know when I release a new post.

Until next time!

13 fantastic web development blogs

Ryan Boone — Thu, 25 Feb 2021 18:54:53 +0000

There are some amazing web development blogs out there (Smashing Magazine, CSS-Tricks and Codrops come to mind), but today I want to pay homage to the humble personal blog. Here are some of my favorite web developer blogs in no particular order:

Modern CSS - Do you still struggle with vertical centering in CSS? This series from Stephanie Eckles is for you.
Dan Mall - Dan, the founder of the design collaborative SuperFriendly, is a generous source for all things design systems and client relations.
Stuff & Nonsense - Andy Clark has been building websites for a while, and he has a thing or two to teach about writing bulletproof CSS. His Inspired Design Decisions series is a must-read.
Sara Soueidan - I started following Sara a while back thanks to her amazing contributions to the Codrops blog. She is currently focusing on accessibility, but her SVG filter articles will blow your mind.
Sarah Higley - Sarah is a developer at Microsoft with a passion for accessibility. I learned about her through the fantastic A11y Slack group.
Adrian Roselli - I read Adrian's blog to learn how bad I am at accessibility.
Ben Meyers - I am lucky to know Ben personally through a local Meetup. His blog is filled with tons of great accessibility information. Oh, and make sure you check out his Twitch channel Some Antics!
Josh Comeau - In addition to posting some great frontend content, Josh has created a truly fun website. I want my blog to be like Josh's when it grows up.
Frank Chimero - Frank is an accomplished web designer and writer. This site features dense engaging writing that will make you think. My favorite is The Web's Grain.
Brad Frost - He created Atomic Design. He plays bass. If you want to dive more into design systems, you need to follow Brad.
Mark Boulton - Mark's writing has helped me bridge the gap between print and screen design. I highly recommend for developers and designers.
2ality - Dr. Axel Rauschmayer's blog is a JavaScript developer's dream. He features deep dives into the ES spec and explorations into brand-new JavaScript features.
Rachel Andrew - Rachel is an accomplished speaker, writer, and web developer. If you are passionate about CSS, this blog's for you.

Didn't see your favorite? Please let me know on Twitter who I need to add. And if you just discovered a new blog to follow from this post, please let me know by liking this on DEV Community. Likes, much like food, sustain me and give me the strength I need to face the day.

Until next time!

How to get your pull request merged

Ryan Boone — Wed, 24 Feb 2021 21:45:23 +0000

When I started my first job as a professional developer, one of my biggest challenges was learning how to create helpful pull requests. I had been using git for a few years at that point, but my experience was limited to merging and pushing directly to the default remote branch. As a result, my first code reviews were fraught with answering questions, rewriting code, and (gulp) interactive rebasing.

What follows is what I've learned from the past few years of crafting pull requests. My hope is they'll help you whether you're starting your first job in development or trying to contribute to your favorite open source project.

Use atomic commits

Effective pull requests start with atomic commits. Atomic commits add value, don't break tests, and are the smallest unit of work possible. A list of such commits may look something like this:

Add product metadata HTML
Style product metadata
Add product metadata JavaScript

Each step in that list focuses on a particular domain of the overall task of adding product metadata, first the markup, then the CSS, and finally the behavior.

Why use atomic commits? First of all, they're easier to read in a code review (more on that in a minute). Second, since they're self-contained, they're easy to revert without breaking anything.

Now that we have well-structured commits, we need to think about the commit message.

Follow commit message standards

As anyone who has ever plugged a lamp in a wall can tell you, standards are important¹. Different projects may have different commit message standards. Make sure you read and understand them before you contribute.

If you can't find any standards, here's a great article on how to write commit messages. My work more or less follows these standards. Here's a high-level summary:

The subject line should be 50 characters or less to prevent wrapping
The subject line should be a statement written in imperative voice
Add a commit message two carriage returns after the subject line
Commit message lines should be limited to 72 characters

And here's an example commit following these guidelines:

Add new awesome feature

Use this space for anything that needs further explanation. You can 
add a list here as well:

- Added the thing
- Had to pull the other thing out into a separate module for reasons

It's hard to know what your line character count is when staring into the black abyss of the terminal so you may want to change your default text editor to something you're more comfortable with. I personally like to use VS Code as my editor:

git config --global core.editor "code --wait"

Running that command in your terminal should set up VS Code as the default git editor. The above command assumes you're using git as your version control and have the VS Code CLI installed.

Keep it short and sweet

I cannot tell you how many pull requests I've personally submitted with 20+ files changed and thousands of lines touched². If you've ever tried reviewing a PR like that, you'll know how exhausting it is to simply read the entire thing, let alone reason about what's going on.

Pull requests should be kept short. If they can't be kept short, use atomic commits and make sure to arrange your commits in a way that logically tells a story.

Let's imagine we need to add a new form to a project that uses existing logic. The commit history might look something like this:

Reformat file to match standards
Refactor variable names for readability
Refactor form submission to extract logic
Add form markup
Style form
Share form logic with the new form

This history is arranged to tell a story. The beginning sets up the change with some reformatting and refactoring of existing files. The middle adds and styles the new form. Finally, the previous work is combined to complete the functionality.

Review and clarify if necessary

Your commits are atomic, you've followed the project's standards, and you've arranged your commits in a logical order. The next step is to push your code up to the remote repository and review your pull request. I will usually save my pull request as a draft on GitHub at this stage.

After posting a draft pull request, step through each commit, look through the changes, and ask yourself if any potential areas could cause a reviewer to get tripped up. I recommend taking a break before so you can have fresh eyes.

If you find any trip hazards, add a comment to explain why you did what you did. If you can't explain why you did what you did, this is a good time to say so and ask for any suggestions. These comments give reviewers much-needed context to help inform the review.

Listen to the reviewer

The final step to getting your pull request merged is listening to the reviewer. This can prove challenging sometimes, especially if the reviewer has difficulty communicating in a cordial manner (every team has that one dev...). Aim to receive and consider every comment with equal respect.

Even if you disagree with the comment or request, there is always value in re-examining what you've written from someone else's perspective. That doesn't mean you should blindly do what the reviewer is suggesting. Sometimes it helps to get a second opinion.

I have had to remind myself not to take each comment personally. In a discussion with Chantastic at a local meetup, he suggested to hold off replying to a review until you can start with "Thank you." This will help put you in the right frame of mind when responding to a particularly harsh review.

In summary and summation

Creating helpful pull requests is a useful skill to develop, whether you're contributing to a team or open source software. Creating atomic, standards-based commits in a reasonable order and taking the review process seriously will get you a long way to getting that new feature merged.

If you'd like more information on how to make your pull requests the best they can be, check out the Creative Commons PR guidelines. And if you found this post helpful, please let me know by liking it over on DEV Community, and follow me on Twitter for random thoughts and occasional blog updates.

Until next time!

True story. Did you know there are 15 different outlet plug design standards in use throughout the world today? ↩
Let me assure you karma is a thing. ↩

Talk to your React components with custom events

Ryan Boone — Tue, 23 Feb 2021 20:33:31 +0000

I build pages with both React and non-React components, and sometimes all these components need to talk to each other. Examples include opening a React modal when a customer clicks a button or updating a text block when a customer adds a product from a React stepper. There are many ways to do this, but in my opinion, the best way is to use custom events.

What are custom events?

Custom events are just like regular browser events (e.g. "click", "keyup", etc.) except they're manually created. You can create a simple synthetic event with a custom type using the Event constructor¹:

const event = new Event('build');
document.dispatchEvent(event);

If you need to pass arbitrary data, you can use the CustomEvent interface²:

const customEvent = new CustomEvent('build', { detail: { name: 'primary' } });
document.dispatchEvent(customEvent);

I use the document element as the single event handler for all custom events because it centralizes all event methods and decouples custom events from specific nodes on the page.

document.addEventListener('build', function({ detail }) {
  const { name } = detail;
  ...
}

Using a single entity to manage events makes this approach act like a browser-native publish-subscribe pattern. Benefits to this pattern include decoupling (previously mentioned) and scalability.

Example time!

I've built an example app with Create React App to illustrate this. The App component includes a modal built with React Modal:

// App.js

import * as React from "react";
import Modal from "react-modal";
import "./style.css";

export default function App() {
  const [isOpen, setIsOpen] = React.useState(false);

  function closeModal() {
    setIsOpen(false);
 }

 return (
   <div>
    <h1>Trigger modal outside React</h1>
    <p>Custom events are AWESOME!</p>
    <Modal isOpen={isOpen} onRequestClose={closeModal}>
      <p>I was opened by a modal outside of React. How cool is that?</p>
      <button onClick={closeModal}>Close</button>
    </Modal>
  </div>
 );
}

The isOpen prop determines the Modal component open state. We then control this state using the useState hook.

We will create a button outside of the React component that opens the React app modal. Let's add the button to the page:

<!-- public/index.html -->

<!-- ... -->
<button id="open-button">I'm outside React</button>
<div id="root"></div>
<!-- ... -->

To make things a bit easier and reduce event boilerplate, I've put our event functions into a module:

// events.js

function on(eventType, listener) {
  document.addEventListener(eventType, listener);
}

function off(eventType, listener) {
  document.removeEventListener(eventType, listener);
}

function once(eventType, listener) {
  on(eventType, handleEventOnce);

  function handleEventOnce(event) {
    listener(event);
    off(eventType, handleEventOnce);
  }
}

function trigger(eventType, data) {
  const event = new CustomEvent(eventType, { detail: data });
  document.dispatchEvent(event);
}

export { on, once, off, trigger };

You could go crazy and make this look more like traditional pub-sub implementations³, or you could completely emulate the EventEmitter interface if you want. Here I've tried to capture the most common functions.

Now that we have all the pieces in place we need to wire everything up.

Putting it together

The next step is to publish an event when the open button is clicked. For this example app, I'm going to do that in the index.js file Create React App provides:

import React from "react";
import ReactDOM from "react-dom";
import { trigger } from "./events";

import App from "./App";

const openButton = document.getElementById("open-button");
openButton.addEventListener("click", function() {
  trigger("openButton:click");
});

ReactDOM.render(<App />, document.getElementById("root"));

I've named the event openButton:click. I typically follow a pattern of subject:verb, mainly because that's what I learned way back in my jQuery days. A nice benefit of this pattern is it reduces the possibility of event name collisions.

Finally, we'll listen for that event inside the App component and set the isOpen state to true when it's triggered. Since adding event listeners is a side effect, we'll use useEffect to do that.

import * as React from "react";
import Modal from "react-modal";
import { on } from "./events";
import "./style.css";

export default function App() {
  const [isOpen, setIsOpen] = React.useState(false);

  React.useEffect(() => {
    on("openButton:click", () => setIsOpen(true));
  });

  function closeModal() {
    setIsOpen(false);
  }

  return (
    <div>
      <h1>Trigger modal outside React</h1>
      <p>Custom events are AWESOME!</p>
      <Modal isOpen={isOpen} onRequestClose={closeModal}>
        <p>I was opened by a modal outside of React. How cool is that?</p>
        <button onClick={closeModal}>Close</button>
      </Modal>
    </div>
  );
}

And now it works (hopefully)! You can test it for yourself over on StackBlitz.

Custom events are awesome indeed

Custom events are great when you need two completely separate entities to talk to each other, which is a common problem in UI design. Be aware, though, this pattern's not all sunshine and rainbows. Drawbacks include an increased difficulty of maintenance (ghost events, or published events that are no longer listened to) and a higher degree of reasoning (indeterminate order of execution).

I hope I've at the very least piqued your interest in custom events, and maybe even given you a solution to a problem you're dealing with right now. If that's you, please do me a favor and like this article on DEV Community. And while you're at it, follow me on Twitter so I don't get lonely.

Until next time!

Note this code will not work in Internet Explorer (what does, amirite?). You will need to use the old-fashioned event constructor. ↩
The CustomEvent constructor is also unsupported in Internet Explorer (whomp whomp). They are created the same way as Events, but initialize with initCustomEvent. ↩
One addition could be a method to remove all event listeners for a particular event. You would need to manually track listeners in an object since there's no way of directly accessing event listeners in native browser event handling. ↩

Tips for vanilla JavaScript DOM manipulation

Ryan Boone — Mon, 22 Feb 2021 21:30:45 +0000

If you need to go au naturale with your JavaScript DOM manipulation, here are some tips for improving performance.

Use `DocumentFragment`s to add multiple elements

Here's one way you might add multiple DOM nodes to a mounted node:

var root = document.getElementById('fruit-list');
var fruitItems = ['apple', 'orange', 'banana'].map(function(fruit) {
    var item = document.createElement('li');
    item.innerText = fruit;
    return item;
});

for (var i = 0; i < fruitItems.length; i++) {
    root.appendChild(fruitItems[i]); // page reflows every time
}

This code works, but the issue is the page will reflow every time appendChild is called. If you have a long list of items to add, you're going to end up in a serious performance bottleneck, and an unhappy boss. The solution is to use a [DocumentFragment](https://developer.mozilla.org/en-US/docs/Web/API/DocumentFragment):

var root = document.getElementById('fruit-list');
var fragment = document.crateDocumentFragment();
var fruitItems = ['apple', 'orange', 'banana'].map(function(fruit) {
    var item = document.createElement('li');
    item.innerText = fruit;
    return item;
});

for (var i = 0; i < fruitItems.length; i++) {
    fragment.appendChild(fruitItems[i]); // no page reflow!
}

root.appendChild(fragment);

The appendChild method is only called once, and this makes browsers (and my boss) very happy.

But if you can, use `ParentNode.append`

You can think of the [ParentNode.append](https://developer.mozilla.org/en-US/docs/Web/API/ParentNode/append) method as appendChild on steroids (sans the rage and adult acne). Unlike its puny cousin appendChild, append can take multiple nodes, automatically converts string arguments to text nodes, and it utilizes DocumentFragment for us:

// the `consts` are my way of letting you know this is newer...🙃

const root = document.getElementById('fruit-list');
const fragment = document.crateDocumentFragment();
const fruitItems = ['apple', 'orange', 'banana'].map(function(fruit) {
    const item = document.createElement('li');
    item.innerText = fruit;
    return item;
});

root.append(...fruitItems);

This is the most convenient way to add multiple nodes to a parent node. Support is great if you don't have to prop up Internet Explorer. Luckily, if you do, there's a polyfill for that.

Create `DocumentFragment`s from strings with `Range`s

Imagine a world where you want to create HTML from a string. You might do something like this:

// orange you getting tired of this example yet?

const root = document.getElementById('fruit-list');

root.innerHTML = `
    <li>apple</li>
    <li>orange</li>
    <li>banana</li>
`;

This is nice if you're trying to recreate JSX, but it's not as performant as using DocumentFragments. Luckily there's a way to directly create a DocumentFragment from a string. Contrived code warning:

const root = document.getElementById('fruit-list');
const fragment = document.createRange().createContextualFragment(`
    <li>apple</li>
    <li>orange</li>
    <li>banana</li>
`);

root.appendChild(fragment);

The createRange method returns a Range, which is a representation of a sliver of the current DOM document. The createContextualFragment creates a DocumentFragment using a parsing algorithm based on the current document's context (in this case, HTML). Range methods are meant to be convenience methods built on top of common node editing patterns with optimization in mind, and I'm quite interested to learn more about them.

Memorize the DOM properties that trigger layout

The DOM API is tricky because just observing certain node properties can trigger page layout. Doing this multiple times in a row can be a performance problem. Doing this inside a loop can cause layout thrashing (trust me, it's as bad as it sounds).

You'll want to be aware of what DOM properties cause the browser to trigger layout, so you need to get to memorizing. Or you could simply bookmark this convenient list of properties that cause layout.

This is only scratching the proverbial surface

There's more to DOM layout with vanilla JavaScript, to be sure. I'm interested in looking at some of the performance optimizations VDOM libraries employ to eek the most out of DOM manipulation. I kinda like that sort of thing.

I hope you learned something new today. And if you did, please consider liking this post on DEV Community, and let me know on Twitter. I get lonely sometimes.

Until next time!

11 podcasts for the frontend developer

Ryan Boone — Sun, 21 Feb 2021 20:53:46 +0000

I'm a huge fan of continuing education, and one of the ways I binge on information is through podcasts. Here's a list of 11 podcasts that I find not only educational but entertaining as well.

JS Party - From the folks at Changelog, this weekly, hour-ish podcast focusing on JavaScript features a rotating panel and format.
Front End Happy Hour - A bunch of developers drinking and talking about development. What could go wrong?
Developer Tea - This podcast is more about the human element of development. I recommend this to developers of all levels, but especially beginners.
FSJam Podcast - Fullstack Jamstack conversations with developers, library maintainers, and industry thought leaders.
99% Invisible - It's not all dev-centric podcasts here. 99% Invisible peels back the curtain on the design of everyday things. The flag episode is a classic.
Full Stack Radio - Adam Wathan, creator of (among other things) Tailwind, hosts this podcast with a focus on all the things happening on the front end.
Hidden Brain - This fascinating podcast delves into why we do the things we do and how we can learn from that. It's honestly one of my favs.
React Podcast - It's about React. So...
ShopTalk Show - Chris Coyier (CSS-Tricks) and Dave Rupert (Paravel) host this quirky podcast (mostly) about frontend. This podcast was my first developer podcast ever and still one of my favorites.
Syntax - Hosted by Wes Bos and Scott Tolinski, I highly recommend this podcast if you are new to JavaScript. It's chock-full of tips and sick picks.
Freakonomics Radio - Again, a podcast about humans for humans. This one has a strong focus on Behavioral Economics, the cross-section of psychology and econ.

Don't see your favorite here? Let me know on Twitter. And if you found this post helpful, please let me know by liking it on DEV Community.

Until next time!

DEV Community: Ryan Boone

Misadventures in web components

Lessons learned

Progressive enhancement...sort of

Native form functionality

Accessibility

Styling

Final thoughts

Resources

Native form validation with JavaScript

Enter the humble login form

Requiring fields

Styling error state

Validation, final form

Marking invalid inputs

Our new validation pattern

Validating on user input

Custom inline errors

Better form validation

Keep exploring

Hold off on optimizing JavaScript performance

Make it work

Make it always work

Make it work for everyone

Make it right

Make it fast (if needed)

Summary

What I learned blogging daily for a month

Worked: Setting deadlines

Worked: Having a healthy backlog

Worked: Cross-publishing on DEV

Did not work: My website styling is lacking

Did not work: My publishing process sucks

What next?

Most popular posts

Share variables between JavaScript and CSS

ICSS

Setting @value

Sass compiler

CSS-in-JS

Custom Properties

Lots of options

How I write my posts

Idea backlog

Writing the post

Publishing

Thoughts on the process

Understand the context of code you copy

A reason for everything

Learning the context

This looks like a lot of work

Take the time to save time

13 fantastic web development blogs

How to get your pull request merged

Use atomic commits

Follow commit message standards

Keep it short and sweet

Review and clarify if necessary

Listen to the reviewer

In summary and summation

Talk to your React components with custom events

What are custom events?

Example time!

Putting it together

Custom events are awesome indeed

Tips for vanilla JavaScript DOM manipulation

Use DocumentFragments to add multiple elements

But if you can, use ParentNode.append

Create DocumentFragments from strings with Ranges

Memorize the DOM properties that trigger layout

This is only scratching the proverbial surface

11 podcasts for the frontend developer

Setting `@value`

Use `DocumentFragment`s to add multiple elements

But if you can, use `ParentNode.append`

Create `DocumentFragment`s from strings with `Range`s