Forem: CoderPad Team

Web Components 101: History

CoderPad Team — Thu, 07 Apr 2022 23:06:19 +0000

Web components enjoy large-scale usage today. From YouTube to GitHub and many other major organizations, it’s safe to say they’ve made their way into commonplace frontend development practices.

That wasn’t always the case. After all, web components had to start somewhere. And web development can be particularly picky with what succeeds and what doesn’t.

So then, how did web components succeed? What was their path to broad adoption? And what are the origins behind the APIs used for modern web components?

Let’s walk through a short history of web components and the related ecosystem to answer these questions.

2010: The Early Days of MVC in JS

While the concept of “Model View Controller”, also commonly called MVC, has been around for some time, in JavaScript itself it failed to take hold early on.

However, in 2010, there was an explosion around MVC and it’s related cousin: Model View View-Controller (MVVC) ). This explosion came courtesy of a slew of new frameworks that launched only a few months apart from one-another.

Knockout was one of the first to introduce strict MVC patterns inside of JavaScript in July 2010. Knockout supported observable-based UI binding. Here, you could declare a Model, and bind data from said model directly to your HTML.

<!-- Demo of KnockoutJS -->
<table class="mails" data-bind="with: chosenFolderData">
    <thead><tr><th>Subject</th></tr></thead>
    <tbody data-bind="foreach: mails">
        <tr><td data-bind="text: subject"></td></tr>
    </tbody>
</table>
<script>
function WebmailViewModel() {
    // Data
    var self = this;
    self.chosenFolderData = ko.observable();

    $.get('/mail', { folder: 'Inbox'}, self.chosenFolderData)
};

ko.applyBindings(new WebmailViewModel());
</script>

While this works great for UI binding, it lacks the componentization aspect we’ve come to expect from modern frameworks.

This was improved in the ecosystem when Backbone saw its first release in October 2010. It introduced a View, similar to what we might expect a component to be like today.

var DocumentRow = Backbone.View.extend({
  tagName: "li",
  className: "document-row",
  events: {
    "click .icon":          "open",
    "click .button.edit":   "openEditDialog",
    "click .button.delete": "destroy"
  },
  initialize: function() {
    this.listenTo(this.model, "change", this.render);
  },
  render: function() {
    ...
  }
});

Here, we can see that we can now bind events, classes, and more to a single tag. This aligns better with the types of components we’d see in, say, React or Lit.

But that’s not all we saw in October that year. We also saw the initial release of Angular.js only 10 days after Backbone’s release.

Here, we can see that it introduced a concept of controllers into the document, similar to the Models of Knockout. It allowed two-way bindings from UI to data and back.

<div ng-controller="TodoListController as todoList">
  <ul>
    <li ng-repeat="todo in todoList.todos">{{todo.text}}</li>
  </ul>
  <form ng-submit="todoList.addTodo()">
    <input
      type="text"
      ng-model="todoList.todoText"
    />
    <input class="btn-primary" type="submit" value="add" />
  </form>
</div>
<script>
  angular
    .module("todoApp", [])
    .controller("TodoListController", function () {
      var todoList = this;
      todoList.todos = [
        { text: "learn AngularJS" },
        { text: "build an AngularJS app" },
      ];

      todoList.addTodo = function () {
        todoList.todos.push({ text: todoList.todoText });
        todoList.todoText = "";
      };
    });
</script>

While Angular was the last of the three mentioned here, it had a huge impact. It was the first time Google released a JavaScript-based MVC based library into the wild.

Not only did they build the library, they used it to build Google’s Feedback tool - which powers almost all of Google’s products today. This represented a shift from their prior Java-based “Google Web Toolkit” (GWT) that was widely used before.

Later, with the acquisition of DoubleClick, the team that was working on the migration of the DoubleClick platform for Google decided to use Angular.js as well.

2011: A Glimmer in W3C Standard’s Eye

With Angular.js continuing to grow within Google, it’s no surprise that they continued researching in-JavaScript HTML bindings.

On this topic, Alex Russel - then a Senior Staff Engineer at Google, working on the web platform team - gave a talk at the Fronteers conference.

In this talk, he introduces a host of libraries that allow building custom elements with experimental new APIs.

<script>
class Comment extends HTMLElement {

  constructor(attrs = {}) {
    super(attrs);
    this.textContent = attrs.text || lorem;
    this.shadow = new ShadowRoot(this);
    this.buildUI();
  }

  buildUI() { ... }
}

HTMLElement.register('x-comment', Comment);

var c = new Comment("Howdy, pardner!");
document.body.appendChild(c);
</script>

<x-comment>...</x-comment>

Here, he utilized the TraceUR compiler (a precursor to Babel) to add classes (remember, class wouldn’t land in JavaScript stable until ES6 in 2015) to build a new “custom element”.

This combined with their new MDV library in order to create a similar development environment to what we have in browser APIs today.

It’s important to note that at this stage, nothing was formalized inside of a specification - It was all experimental libraries acting as playgrounds for APIs.

That would change soon after.

2013: Things Start Heating Up

In early 2013 the Google team created a Working Draft of a specification for Custom Elements. Alongside similar working drafts for Shadow DOM APIs, they were colloquially called “Custom Elements v0”.

With Google Chrome’s release in 2008, they had the ability to quickly implement these non-standard APIs into Chrome in order to allow application developers to utilize them before specification stabilization.

One such example of this was Polymer, which was a component library based on v0 APIs to provide two-way UI binding using MVC. It’s initial alpha release was announced in early 2013, alongside the specifications.

At Google Dev Summit 2013, they walked through its capabilities and how it was able to run in other browsers by utilizing polyfills.

Facebook, not one to be outdone on the technical engineering front, introduced React into public in 2013

While Polymer went deeper into the MVC route, React relied more heavily on unidirectionality in order to avoid state mutations.

2016 & 2017: Formative Years

While only the year prior, Polymer 1.0 was released with the usage of v0 custom element spec, 2016 saw the release of the custom element v1 specification.

This new version of the specification was not backwards compatible, and as a result required a shift to the new version of the specification in order to function properly. Polyfills were continued to be used as a stop-gate for browsers that didn’t have a v0 implementation.

While v1 was already implemented into Chrome in late 2016, it wasn’t until 2017 with the release of Polymer 2.0 that it would be adopted back into the library that helped draft the specification.

Because of this, while YouTube’s new Polymer rewrite theoretically was a huge step towards the usage of web components, it posed a problem. Browsers like Firefox without a v0 implementation were forced to continue to use Polyfills, which are slower than native implementations.

2018 and Beyond: Maturity

2018 is where Web Components really found their foothold.

For a start, Mozilla implemented the v1 specification APIs into their stable release of Firefox, complete with dedicated devtools. Finally, developers could use all of the web components’ APIs in their app, cross-browser, and without any concern for non-Chrome performance.

On top of that, React’s unidirectionality seemed to have won over the Polymer team. The Polymer team announced that it would migrate away from bidirectional binding and towards a one-way bound LitElement

That LitElement would then turn into a dedicated framework called “Lit”, developed to replace Polymer as its successor, that would hit v1 in 2019 and v2 in 2021.

Timeline

Whew! That’s a lot to take in. Let’s see it all from a thousand foot view:

2010:
2011:
- MDV (Polymer predecessor) introduced at a conference
2013:
2015:
- Polymer 1.0 released
2016:
- Custom elements v1 spec released
- YouTube rewritten in Polymer
2017:
- Polymer 2.0 released
2018:
- Polymer announces start of migration to “LitElement”
- Firefox enables web components (Polyfills no longer needed)
2019:
- Lit framework 1.0 released
2021
- Lit 2.0 released

Conclusion

In the past 10 years we’ve seen massive changes to the web development ecosystem. No more is this more apparent than the development and continued growth of web components.

Hopefully this should put any future learnings about web components and framework comparisons into perspective.

We’ve waited a long time to see many of these ideas fully standardized into the web platform, and, now that they’re here, they’re helping accelerate growth of many platforms.

Want to learn how to build them yourself?

We have articles about how to build web components without a framework as well as using Google’s Lit framework.

Web Components 101: Framework Comparison

CoderPad Team — Mon, 04 Apr 2022 17:30:40 +0000

Alright alright, I know for a lot of the last article seemed like a big ad for Lit. That said, I promise I’m not unable to see the advantages of other frameworks. Lit is a tool in a web developer’s toolbox. Like any tool, it has its pros and cons: times when it’s the right tool for the job, and other times when it’s less so.

That said, I’d argue that using an existing framework is more often the better tool for the job than vanilla web components.

To showcase this, let’s walk through some of these frameworks and compare and contrast them to home-growing web components.

Pros and Cons of Vanilla Web Components

While web frameworks are the hot new jazz - it’s not like we couldn’t make web applications before them. With the advent of W3C standardized web components (without Lit), doing so today is better than it’s ever been.

Here are some pros and cons of Vanilla JavaScript web components:

Pros

No framework knowledge required
Less reliance on framework
Maintenance
Bugs
Security issues
Smaller “hello world” size
More control over render behavior

Cons

Re-rendering un-needed elements is slow
Handling event passing is tricky
Creating elements can be overly verbose
Binding to props requires element query
You’ll end up building Lit, anyway

To the vanilla way of doing things’ credit, there’s a bit of catharsis knowing that you’re relying on a smaller pool of upstream resources. There’s also a lessened likelihood of some bad push to NPM from someone on the Lit team breaking your build.

Likewise - for smaller apps - you’re likely to end up with a smaller output bundle. That’s a huge win!

For smaller applications where performance is critical, or simply for the instances where you need to be as close to the DOM as possible, vanilla web components can be the way to go.

That said, it’s not all roses. After all, this series has already demonstrated that things like event passing and prop binding are verbose compared to Lit. Plus, things may not be as good as they seem when it comes to performance.

Incremental Rendering

On top of the aforementioned issues with avoiding a framework like Lit, something we haven’t talked about much is incremental rendering. A great example of this would come into play if we had an array of items we wanted to render, and weren’t using Lit.

Every time we needed to add a single item to that list, our innerHTML trick would end up constructing a new element for every single item in the list. What’s worse is that every subelement would render as well!

This means that if you have an element like this:

<li><a href=”https://example.com”><div class=”flex p-12 bg-yellow”><span>Go to this location</span></div></a></li>

And only needed to update the text for a single item in the list, you’d end up creating 4 more elements for the item you wanted to update… On top of recreating the 5 nodes (including the Text Node) for every other item in the list.

Building Your Own Framework

As a result of the downsides mentioned, many that choose to utilize vanilla web components often end up bootstrapping their own home-grown version of Lit.

Here’s the problem with that: You’ll end up writing Lit yourself, sure, but with none of the upsides of an existing framework.

This is the problem with diving headlong into vanilla web components on their own. Even in our small examples in the article dedicated to vanilla web components, we emulated many of the patterns found within Lit. Take this code from the article:

<script>
  class MyComponent extends HTMLElement {
    todos = [];

    connectedCallback() {
      this.render();
    }

    // This function can be accessed in element query to set internal data externally
    setTodos(todos) {
      this.todos = todos;
      this.clear();
      this.render();
    }

    clear() {
      for (const child of this.children) {
        child.remove();
      }
    }

    render() {
      this.clear();

      // Do logic
    }

  }

  customElements.define('my-component', MyComponent);
</script>

Here, we’re writing our own clear logic, handling dynamic value updates, and more.

The obvious problem is that we’d then have to copy and paste most of this logic in many components in our app. But let’s say that we were dedicated to this choice, and broke it out into a class that we could then extend.

Heck, let’s even add in some getters and setters to make managing state easier:

<script>
  // Base.js
  class OurBaseComponent extends HTMLElement {
    connectedCallback() {
      this.doRender();
    }

    createState(obj) {
        return Object.keys(obj).reduce((prev, key) => {
            // This introduces bugs
            prev["_" + key] = obj[key];
            prev[key] = {
                get: () => prev["_" + key],
                set: (val) => this.changeData(() => prev["_" + key] = val);
            }
        }, {})
    }

    changeData(callback) {
      callback();
      this.clear();
      this.doRender();
    }

    clear() {
      for (const child of this.children) {
        child.remove();
      }
    }

    doRender(callback) {
      this.clear();
      callback();
    }   
  }
</script>

Now our usage should look fairly simple!

<script>
  // MainFile.js
  class MyComponent extends OurBaseComponent {
    state = createState({todos: []});

    render() {
        this.doRender(() => {
            this.innerHTML = `<h1>You have ${this.state.todos.length} todos</h1>`
        })
    }
  }

  customElements.define('my-component', MyComponent);
</script>

That’s only 13 lines to declare a UI component!

Only now you have a bug with namespace collision of state with underscores, your doRender doesn’t handle async functions, and you still have many of the downsides listed below!

You could work on fixing these, but ultimately, you’ve created a basis of what Lit looks like today, but now you’re starting at square one. No ecosystem on your side, no upstream maintainers to lean on.

Pros and Cons of Lit Framework

With the downsides (and upsides) of vanilla web components in mind, let’s compare the pros and cons of what building components using Lit looks like:

Pros

Faster re-renders* that are automatically handled
More consolidated UI/logic
More advanced tools after mastery
Smaller footprint than other frameworks

Cons

Framework knowledge required
Future breaking changes
Not as widely known/used as other frameworks (Vue, React, Angular)

While there is some overlap between this list of pros and cons and the one for avoiding Lit in favor of home-growing, there’s a few other items here.

Namely, this table highlights the fact that Lit isn’t the only framework for building web components. There’s huge alternatives like React, Vue, and Angular. These ecosystems have wider adoption and knowledge than Lit, which may make training a team to use Lit more difficult.

However, Lit has a key advantage over them, ignoring being able to output to web components for a moment - we’ll come back to that.

Even compared to other frameworks, Lit is uniquely lightweight.

Compare the bundle sizes of Vue - a lightweight framework in it’s own right - compared to Lit.

While tree shaking will drastically reduce the bundle size of Vue for smaller applications, Lit will still likely win out for a simple component system.

Other Frameworks

Lit framework isn’t alone in being able to output to web components, however. In recent years, other frameworks have explored and implemented various methods of writing code for a framework that outputs to web components.

For example, the following frameworks have official support for creating web components without changing implementation code:

Vue 3, in particular, has made massive strides in improving the web component development experience for their users.

What’s more is that these tools tend to have significantly larger ecosystems. Take Vue for example.

Want the ability to change pages easily? Vue Router

Want a global store solution? VuexPrefer similar class based components? Vue Class Component Library

Prebuilt UI components? Ant Design

While some ecosystem tools might exist in Lit, they certainly don’t have the same breadth.

That’s not to say it’s all good in the general web component ecosystem. Some frameworks, like React, have issues with Web Component interop, that may impact your ability to merge those tools together.

Why Web Components?

You may be asking - if you’re going to use a framework like Vue or React anyway, why even bother with web components? Couldn’t you instead write an app in one of those frameworks, without utilizing web components?

You absolutely can, and to be honest - this is how most apps that use these frameworks are built.

But web components play a special role in companies that have multiple different projects: Consolidation.

Let’s say that you work for BigCorp - the biggest corporation in Corpville.

BigCorp has dozens and dozens of full-scale applications, and not all of them are using the same frontend framework. This might sound irresponsible of BigCorp’s system architects, but in reality, sometimes a framework is better geared towards specific applications. Additionally, maybe some of the apps were part of an acquisition or merger that brought them into the company.

After all, the user doesn’t care (or often, know) about what framework a tool is built with. You know what a user does care about? The fact that each app in a collection all have vastly different UIs and buttons.

While this is clearly a bug, if both codebases implement the buttons on their own, you’ll inevitably end up with these types of problems; this being on top of the work-hours your teams have to spend redoing one-another’s work for their respective frameworks.

And that’s all ignoring how difficult it can be to get designers to have consistency between different project’s design components - like buttons.

Web Components solve this problem.

If you build a shared component system that exports web components, you can then use the same codebase across multiple frameworks.

Once the code is written and exported into web components, it’s trivial to utilize these new web components in your application. Like, it can be a single line of code trivial.

From this point, you’re able to make sure the logic and styling of these components are made consistent between applications - even if different frameworks.

Conclusion

While web components have had a long time in the oven, they came out swinging! And while Lit isn’t the only one at the table, they’ve certainly found a strong foothold in capabilities.

Lit’s lightweightness, paired with web component’s abilities to integrate between multiple frameworks is an incredible one-two punch that makes it a strong candidate for any shared component system.

What’s more, the ability to transfer knowledge from other frameworks makes it an easy tool to place in your toolbox for usage either now or in the future.

Regardless; whether you’re using Vue, React, Angular, Lit, Vanilla Web Components, or anything else, we wish you happy engineering!

Why React 18 Broke Your App

CoderPad Team — Thu, 31 Mar 2022 21:32:17 +0000

You’ve just gotten done with your React 18 upgrade, and, after some light QA testing, don’t find anything. “An easy upgrade,” you think.

Unfortunately, down the road, you receive some internal bug reports from other developers that make it sound like your debounce hook isn’t working quite right. You decide to make a minimal reproduction and create a demo of said hook.

You expect it to throw an “alert” dialog after a second of waiting, but weirdly, the dialog never runs at all.

See and run the related code sample in the sandbox

This is strange because it was working just last week on your machine! Why did this happen? What changed?

The reason your app broke in React 18 is that you’re using StrictMode.

Simply go into your index.js (or index.ts) file, and change this bit of code:

render(
  <StrictMode>
    <App />
  </StrictMode>
);

To read like this:

render(
    <App />
);

All of the bugs that were seemingly introduced within your app in React 18 are suddenly gone.

Only one problem: These bugs are real and existed in your codebase before React 18 - you just didn’t realize it.

Proof of broken component

Looking at our example from before, we’re using React 18’s createRoot API to render our App inside of a StrictMode wrapper in lines 56 - 60.

See and run the related code sample in the sandbox

Currently, when you press the button, it doesn’t do anything. However, if you remove the

StrictMode and reload the page, you can see an Alert after a second of being debounced.

Looking through the code, let’s add some console.logs into our useDebounce, since that’s where our function is supposed to be called.

function useDebounce(cb, delay) {
  const inputsRef = React.useRef({ cb, delay });
  const isMounted = useIsMounted();
  React.useEffect(() => {
    inputsRef.current = { cb, delay };
  });
  return React.useCallback(
    _.debounce((...args) => {
        console.log("Before function is called", {inputsRef, delay, isMounted: isMounted()});
          if (inputsRef.current.delay === delay && isMounted())
                      console.log("After function is called");
                  inputsRef.current.cb(...args);
        }, delay),
    [delay]
  );
}

Before function is called Object { inputsRef: {…}, delay: 1000, isMounted: false }

Oh! It seems like isMounted is never being set to true, and therefore the inputsRef.current callback is not being called: that’s our function we wanted to be debounced.

Let’s take a look at the useIsMounted() codebase:

function useIsMounted() {
  const isMountedRef = React.useRef(true);
  React.useEffect(() => {
    return () => {
          isMountedRef.current = false;
    };
  }, []);
  return () => isMountedRef.current;
}

This code, at first glance, makes sense. After all, while we’re doing a cleanup in the return function of useEffect to remove it at first render, useRef's initial setter runs at the start of each render, right?

Well, not quite.

What changed in React 18?

In older versions of React, you would mount a component once and that would be it. As a result, the initial value of useRef and useState could almost be treated as if they were set once and then forgotten about.

In React 18, the React developer team decided to change this behavior and re-mount each component more than once in strict mode. This is in strong part due to the fact that a potential future React feature will have exactly that behavior.

See, one of the features that the React team is hoping to add in a future release utilizes a concept of “reusable state”. The general idea behind reusable state is such that if you have a tab that’s un-mounted (say when the user tabs away), then re-mounted (when the user tabs back), React will recover the data that was assigned to said tab component. This data being immediately available allows you to render the respective component immediately without hesitation.

Because of this, while data inside of, say, useState may be persisted, it’s imperative that effects are properly cleaned up and handled properly. To quote the React docs:

This feature will give React better performance out-of-the-box but requires components to be resilient to effects being mounted and destroyed multiple times.

However, this behavior shift in Strict Mode within React 18 isn’t just protective future-proofing from the React team: it’s also a reminder to follow React’s rules properly and to clean up your actions as expected.

After all, the React team themselves have been warning that an empty dependent array ([] as the second argument) should not guarantee that it only runs once for ages now.

In fact, this article may be a bit of a misnomer - the React team says they’ve upgraded thousands of components in Facebook’s core codebase without significant issues. More than likely, a majority of applications out there will be able to upgrade to the newest version of React without any problems.

All that said, these React missteps crawl their way into our applications regardless. While the React team may not anticipate many breaking apps, these errors seem relatively common enough to warrant an explanation.

How to fix the remounting bug

The code I linked before was written by me in a production application and it's wrong. Instead of relying on useRef to initialize the value once, we need to ensure the initialization runs on every instance of useEffect.

function useIsMounted() {
  const isMountedRef = React.useRef(true);
  React.useEffect(() => {
  isMountedRef.current = true; // Added this line  
  return () => {
      isMountedRef.current = false;
    };
  }, []);
  return () => isMountedRef.current;
}

This is true for the inverse as well! We need to make sure to run cleanup on any components that we may have forgotten about before.

Many ignore this rule for App and other root elements that they don’t intend to re-mount, but with new strict mode behaviors, that guarantee is no longer a safe bet.

To solve this application across your app, look for the following signs:

Side effects with cleanup but no setup (like our example)
A side effect without proper cleanup
Utilizing [] in useMemo and useEffect to assume that said code will only run once

One this code is eliminated, you should be back to a fully functioning application and can re-enable StrictMode in your application!

Conclusion

React 18 brings many amazing features to the table, such as new suspense features, the new useId hook, automatic batching, and more. While refactor work to support these features may be frustrating at times, it’s important to remember that they a serve real-world benefit to the user.

For example, React 18 also introduces some functionality to debounce renders in order to create a much nicer experience when rapid user input needs to be processed.

For more on the React 18 upgrade process, take a look at our instruction guide on how to upgrade to React 18

Web Components 101: Lit Framework

CoderPad Team — Mon, 28 Mar 2022 16:46:08 +0000

Recently we talked about what web components are and how you can build a web app utilizing them with only vanilla JavaScript.

While web components are absolutely usable with only vanilla JavaScript, more complex usage, especially pertaining to value binding, can easily become unwieldy.

One potential solution might be using a web component framework such as VueJS or React. However, web-standard components can still be a massive boon to development.

As such, there’s a framework called “Lit” that is developed specifically to leverage web components. With Lit 2.0 recently launching as a stable release, we thought we’d take a look at how we can simplify web component development.

HTML

One of the greatest strengths of custom elements is the ability to contain multiple other elements. This makes it so that you can have custom elements for every scale: from a button to an entire page.

To do this in a vanilla JavaScript custom element, you can use innerHTML to create new child elements.

<script>
class MyComponent extends HTMLElement {
  connectedCallback() {
      this.render();
  }

  render() {
      this.innerHTML = '<p>Hello!</p>';
  }
}

customElements.define('hello-component', MyComponent);
</script>

<hello-component></hello-component>

This initial example looks fairly similar to what the Lit counterpart of that code looks like:

<script type="module">
import { html, LitElement } from "https://cdn.skypack.dev/lit";

export class HelloElement extends LitElement {
    render() {
        return html`
              <p>Hello!</p>
        `;
    }
}

window.customElements.define('hello-component', HelloElement);
</script>

<hello-component></hello-component>

Run this code sample in an interactive playground

There are two primary differences from the vanilla JavaScript example. First, we no longer need to use the connectedCallback to call render. The LitElement’s render function is called by Lit itself whenever needed - such as when data changes or for an initial render - avoiding the need to manually re-call the render method.

That said, Lit components fully support the same lifecycle methods as a vanilla custom elements.

The second, easier-to-miss change from the vanilla JavaScript component to the Lit implementation, is that when we set our HTML, we don’t simply use a basic template literal:

`<p>test</p>`

We pass the function html to the template literal:

html`<p>test</p>`

This leverages a somewhat infrequently used feature of template literals called tagged templates. Tagged templates allow a template literal to be passed to a function. This function can then transform the output based on the string input and expected interpolated placeholders.

Because tagged templates return a value like any other function, you can assign the return value of html to a variable.

render {
    const el = html`
            <p>Hello!</p>
      `;
    return el;
}

If you were to console.log this value, you’d notice that it’s not an HTMLElement. Instead, it’s a custom value that Lit utilizes to render to proper DOM nodes.

Event Binding

“If the syntax is so similar, why would I add a framework to build custom elements?”

Well, while the Vanilla JavaScript and Lit custom element code look similar for a small demo: The story changes dramatically when you look to scale up.

For example, if you wanted to render a button and add a click event to the button with vanilla JavaScript, you’d have to abandon the innerHTML element assignment method.

First, we’ll create an element using document.createElement, then add events, and finally utilize an element method like append to add the node to the DOM.

<script>
class MyComponent extends HTMLElement {
  connectedCallback() {
    this.render();
  }

  sayHello() {
    alert("Hi there!");
  }

  render() {
    const button = document.createElement('button');
    button.innerText = "Say Hello!";
    button.addEventListener('click', this.sayHello);
    this.append(button);
  }
}

window.customElements.define('hello-component', MyComponent);
</script>

<hello-component></hello-component>

While this works for the initial render, it doesn’t handle any of the edgecases that,at scale,can cause long-term damage to your app’s maintainability & performance.

For example, future re-renders of the element will duplicate the button. To solve this, you must iterate through all of the element’s children and remove them one-by-one.

Further, once the element is removed from the DOM, the click listener is not implicitly removed in the background. Because of this, it’s never released from memory and is considered a memory leak. If this issue continued to occur during long-term usage of your app, it would likely bloat memory usage and eventually crash or hang.

To solve this, you’d need to assign a variable for every addEventListener you had present. This may be simple for one or two events, but add too many and it can be difficult to keep track.

And all of this ignores the maintenance standpoint: What does that code do at a glance?

It doesn't look anything like HTML and as a result, requires you to consistently context shift between writing standard HTML in a string and using the DOM APIs to construct elements.

Luckily, Lit doesn’t have these issues. Here’s the same button construction and rendering to a custom element using Lit instead of vanilla JavaScript:

<script type="module">
import { html, LitElement } from "https://cdn.skypack.dev/lit";

export class HelloElement extends LitElement {
    sayHello() {
          alert("Hi there!");
    }

    render() {
        return html`
            <button @click=${this.sayHello}>Say Hello!</button>
        `;
    }
}

window.customElements.define('hello-component', HelloElement);
</script>

<hello-component></hello-component>

Run this code sample in an interactive playground

Yup, that’s all. Lit allows you to bind elements by using the @ sign and passing the function as a placeholder to the html tagged template. Not only does this look much HTML-like, it handles event cleanup, re-rendering, and more.

Attributes & Properties

As we learned before, there are two ways to pass values between and into components: attributes and values.

Previously, when we were using vanilla JavaScript, we had to define these separately. Moreover, we had to declare which attributes to dynamically listen to value changes of.

class MyComponent extends HTMLElement {
  connectedCallback() {
      this.render();
  }

  static get observedAttributes() {
      return ['message'];
  }

  attributeChangedCallback(name, oldValue, newValue) {
      this.render();
  }

  render() {
      const message = this.attributes.message.value || 'Hello world';
      this.innerHTML = `<h1>${message}</h1>`;
  }
}

In Lit, we declare attributes and properties using a static getter and treat them as normal values in any of our functions.

import { html, LitElement } from "https://cdn.skypack.dev/lit";

export class HelloElement extends LitElement {
  static get properties() {
      return {
          message: {type: String},
      };
  }

  constructor() {
      super();
      this.message = 'Hello world';
  }

  render() {
      return html`
    <h1>${this.message}</h1>
  `;
  }
}

window.customElements.define('hello-component', HelloElement);

For starters, we no longer have to manually call “render” when a property’s value is changed. Lit will re-render when values are changed.

That’s not all, though: Keen eyed readers will notice that we’re declaring a type associated with the message property.

Unlike the React ecosystem’s PropTypes, the type subproperty doesn’t do runtime type validation. Instead, it acts as an automatic type converter.

This can be of great help as the knowledge that attributes can only be strings can be difficult to remember while debugging.

For example, we can tell Lit to convert an attribute to a Number and it will migrate from a string that looks like a number to an actual JavaScript type number.

<script type="module">
import { html, LitElement } from "https://cdn.skypack.dev/lit";

export class HelloElement extends LitElement {
  static get properties() {
      return {
          val: {type: Number},
      };
  }

  render() {
      return html`
    <h1>${this.val} is typeof ${typeof this.val}</h1>
  `;
  }
}

window.customElements.define('hello-component', HelloElement);
</script>

<!-- This will show "123 is typeof number"  -->
<hello-component val="123"></hello-component>
<!-- This will show "NaN is typeof number"  -->
<hello-component val="Test"></hello-component>

Run this code sample in an interactive playground

Attribute Reactivity

One of the biggest benefits of not having to call render manually is that Lit is able to render contents when they need to update.

For example, given this example, the contents will render properly to update with new values.

import { html, LitElement } from "lit";

export class ChangeMessageElement extends LitElement {
  static get properties() {
      return {
          message: {type: String},
      };
  }

  changeSelectedMsg() {
      const newMsg = msgs[Math.floor(Math.random() * msgs.length)];
      this.message = newMsg;
  }

  constructor() {
      super();
      this.message = 'Hello world';
  }

  render() {
      return html`
    <button @click="${this.changeSelectedMsg}">Toggle</button>
    <hello-component message=${this.message}></hello-component>
  `;
  }
}

Run this code sample in an interactive playground

Reactive Data Binding

This reactivity comes with its own set of limitations. While numbers and strings are able to be set fairly trivially, objects (and by extension arrays) are a different story.

This is because, in order for Lit to know what properties to update in render, an object must have a different reference value from one to another. This is just how React and other frameworks detect changes in state as well.

export class FormElement extends LitElement {
  constructor() { /* ... */ }
  static get properties() {
      return {
          todoList: {type: Array},
          inputVal: {type: String},
      };
  }

  _onSubmit(e) {
      e.preventDefault();       /* This works, because we’re changing the object reference */
      this.todoList = [...this.todoList, this.inputVal];       /* But this would not, because we aren’t */
      // this.todoList.push(this.inputVal);       this.inputVal = '';
  }

  _onChange(e) {
      this.inputVal = e.target.value;
  }

  render() {
      return html`
    <form @submit="${this._onSubmit}">
      <input .value="${this.inputVal}" @change="${this._onChange}" type="text" />
      <button type="submit">Add</button>
    </form>
    <todo-component todos=${this.todoList}></todo-component>
  `;
  }
}

You may also notice that we’re binding both the user’s input and output to set and reflect the state. This is exactly how other frameworks like React also expect you to manage user state.

Run this code sample in an interactive playground

Prop Passing with Lit’s Dot Synax

HTML attributes are not the only way to pass data to a web component. Properties on the element class are a way to pass more than just a string to an element.

While the type field can help solve this problem as well, you’re still limited by serializability, meaning that things like functions won’t be able to be passed by attributes.

While properties are a more robust method of data passing to web components, they’re seldomly used in vanilla JavaScript due to their complexity in coding.

For example, this is a simple demonstration of passing an array.

<html>
  <head>
    <!-- Render object array as "ul", passing fn to checkbox change event -->
    <script>
      class MyComponent extends HTMLElement {
        property = [];

        connectedCallback() {
          this.render();
        }

        render() {
          this.innerHTML = `<h1>${this.property.length}</h1>`;
        }
      }

      customElements.define('my-component', MyComponent);
    </script>

    <script>
      function changeElement() {
        const compEl = document.querySelector('#mycomp');
        compEl.property = [
          'Testing',
          'Second',
          'Another'
        ];      
        compEl.render();
      }
    </script>

  </head>
  <body>
    <my-component id="mycomp"></my-component>
    <button onclick="changeElement()">Change to 3</button>
  </body>
</html>

First, you have to get a reference to the element using an API like querySelector. This means you need to introduce a new reference to the component and make sure the IDs match in both parts of code.

Then, just as is the case with updating attribute values, we need to manually call the “render” function in order to update the UI.

But those complaints aside, there’s still one more: It places your data and component tags in two different areas. Because of this, it can be more difficult to debug or figure out what data is being passed to what component.

Lit takes a different approach. Within a Lit html tagged template, add a period before an attribute binding and suddenly it will pass as a property instead.

<script type="module">
import { html, LitElement } from "https://cdn.skypack.dev/lit";

class MyElement extends LitElement {
  static get properties() {
    return {
      property: {type: Array},
    };
  }

  render() {
    return html`
      <h1>${this.property.length}</h1>
    `;
  }
}

window.customElements.define('my-component', MyElement);

class ChangeMessageElement extends LitElement {
    static get properties() {
      return {
        array: {type: Array},
      };
    }

    constructor() {
      super();
      this.array = [];
    }

    changeElement() {
      this.array = [
        'Testing',
        'Second',
        'Another'
      ];      
    }

    render() {
        return html`
      <!-- If "property" didn't have a period, it would pass as attribute -->
      <my-component .property=${this.array}></my-component>
      <button @click=${this.changeElement}>Change to 3</button>
    `;
    }
}

window.customElements.define('change-message-component', ChangeMessageElement);
</script>

<change-message-component></change-message-component>

Run this code sample in an interactive playground

This works because properties and attributes are both created at the same time with Lit.

However, due to the period binding not being HTML standard, it comes with the side effect of having to use a Lit template in order to bind properties. This tends not to be a problem in applications - since many tend to use and compose components throughout their applications.

Array Rendering

In our article about vanilla JavaScript web components, we built a simple todo list. Let’s take another look at that example, but this time using Lit for our component code. We’ll get started with a parent FormElement, which will manage the data and user input.

class FormElement extends LitElement {
  static get properties() {
      return {
          todoList: {type: Array},
          inputVal: {type: String},
      };
  }

  _onSubmit(e) {
      e.preventDefault();
      this.todoList = [...this.todoList, {name: this.inputVal, completed: false}];
      this.inputVal = '';
  }

  // ...

  render() {
      return html`
    <button @click=${this.toggleAll}>Toggle all</button>
    <form @submit=${this._onSubmit}>
      <input .value=${this.inputVal} @change=${this._onChange} type="text" />

      <button type="submit">Add</button>
    </form>
    <!-- Notice the period in ".todos" -->
    <todo-component .todos=${this.todoList}></todo-component>
  `;
  }
}

Now that we have a form that contains an array, an important question arises: how do we iterate through an array in order to create individual elements for a list?

Well, while React has Array.map and Vue has v-for, Lit uses a repeat function. Here’s an example:

class TodoElement extends LitElement {
  // ...

  render() {
      return html`
    <ul>
      ${repeat(this.todos, (todo) => html`
        <li>
          <input type="checkbox" .checked=${todo.completed}/>
          ${todo.name}
        </li>
      `)}
    </ul>
  `;
  }
}

Run this code sample in an interactive playground

Passing Functions

Before we step away from code to talk pros and cons about Lit itself (shh, spoilers!); let’s take a look at a code sample that demonstrates many of the benefits over vanilla JavaScript web components we’ve talked about today.

Readers of the previous blog post will remember that when passing an array of objects to a web component, things looked pretty decent.

It wasn’t until we tried binding event listeners to an array of objects that things got complex (and messy). Between needing to manually create elements using document, dealing with querySelector to pass properties, manually calling “render”, and needing to implement a custom “clear” method - it was a messy experience.

Let’s see how Lit handles the job.

class TodoElement extends LitElement {
  // ...

  render() {
      const headerText = this.todos
          .filter(todo => todo.completed).length;

      return html`
    <h1>${headerText}</h1>
    <ul>
      ${repeat(this.todos, (todo) => html`
        <li>
          <input type="checkbox" @change=${todo.onChange} .checked=${todo.completed}/>
          ${todo.name}
        </li>
      `)}
    </ul>
  `;
  }
}

Run this code sample in an interactive playground

You will notice that we’re using a filter within our render method. Because this logic is within the render method, it will run on every UI update. This is important to note in case you have expensive operations: you should avoid running those within the render method.

Outside of this, however - that’s all there is! It reads just like HTML would (with the added benefit of cleanup and prop passing), handles dynamic data, and more!

Conclusion

The ability to leverage Lit in an application makes maintaining and improving a project easier than rolling web components yourself.

Lit demonstrates significant growth in web components from the early days of Polymer. This growth is in no small part due to the Lit team themselves, either!

Before it was a fully fledged framework, the project started from the lit-html package, which was an offshoot of Polymer. The Polymer team was instrumental in standardizing the modern variant of web components.

The ability to use Lit can strongly enhance web component development, but there are other options out there. Next time, we’ll talk about what the competitors are doing, what the pros and cons of each are, and how you can make the best choice for your applications.

Web Components 101: Vanilla JavaScript

CoderPad Team — Thu, 24 Mar 2022 22:19:38 +0000

Many modern web apps today are built using components. While frameworks like React exist to add an implementation, web components seek to make those practices standardized and part of your browser.

In this article, we’ll touch on what web components are, how we can build them without a framework, and some limitations to keep in mind during development. Later, in a follow-up article, we’ll show how a lightweight framework (such as Lit) can provide quality-of-life improvements for those looking to build larger scale applications.

What are Web Components?

There are a lot of misconceptions about what web components even are. While some might assume that it’s simply the ability to make custom elements with dedicated UI, style, and logic in one consolidated place (more on that later), there’s definitely more to it

Web components are a mix of 3 different web standards that, when utilized together, can offer a viable alternative to using a framework like React which offers similar functionality. These web standards consist of:

Custom elements - the ability to create new elements that will provide unique UI and app logic when the related HTML tag is added
Shadow DOM - the ability to keep specific elements segmented off from your main document DOM, allowing you to avoid document collision issues
HTML templates - elements that allow you to write HTML that is not drawn to the page, but can be used as a template for markup to reuse elsewhere

While the Shadow DOM and HTML templates are undoubtedly useful in applications, we’ll be focusing on custom elements today, as we feel they’re the easiest place to start in introducing web components as a whole.

While these are the only official specifications part of Web Components, they’re often utilized with other JavaScript and browser features to create a cohesive development experience.

One of these features often used is JavaScript Modules. While the concept of breaking your app into multiple files has been commonplace with bundlers like Webpack for a while, being built into the browser has been game changing.

What are Custom Elements?

At their core, custom elements essentially allow you to create new HTML tags. These tags are then used to implement custom UI and logic that can be used throughout your application.

<!-- page.html -->

<!-- These are custom elements, combined to make a page -->
<page-header></page-header>
<page-contents></page-contents>
<page-footer></page-footer>

These components can be as simple as a styled button or as complex as an entire page of your application, complete with your business logic.

While we tend to think of HTML tags as directly mapping to a single DOM element, that’s not always the case with custom elements. For example, the “page-header” tag in the example above might contain “nav” and “a” elements as a list of their children.

Because of this, we’re able to improve an app’s organization by reducing the amount of tags visible in a single file to read with better flow.

But custom elements aren’t just made up of HTML - you’re able to associate JavaScript logic with these tags as well! This enables you to keep your logic alongside it’s associated UI. Say your header is a dropdown that’s powered by JavaScript. Now you can keep that JavaScript inside of your “page-header” component, keeping your logic consolidated.

Finally, a significant improvement that components provide is composability. You’re able to use these components on different pages, allowing you to keep your header code in sync between pages. This reduces the potential for having variations in standard components - like having multiple differently sized buttons in a page - that might confuse your users. As long as you’re vigilant about utilizing your existing components, you’re able to make your app more consistent this way.

History

But web components didn’t come from nowhere. While web components enjoy large-scale usage now, that wasn’t always the case. Let’s walk through a short history of web components and the related ecosystem.

2010:
- Angular.js made open-source
2011:
- Web components are announced at a conference by Alex Russell (then Sr Staff Engineer at Google, working on web platform team)
2013:
- Polymer (Google’s web component framework) public development began
- React open-sourced
2016:
- YouTube rewritten in Polymer
2018:
- Polymer announces start of migration to “LitElement”
- Firefox enables web components (Polyfills no longer needed)

While JavaScript frameworks with similar concepts have been around since at least 2010, web components have found a way to standardize those concepts in the browser.

it’s clear that the core concepts at play in web components have allowed for dramatic adoption since then. For example React, which has a lot of the same ideas at play, now has a major market share of websites and applications written in JavaScript.

Now that we’ve seen a short history of web components, let’s take a look at how to build custom elements without using a framework.

Lifecycle Methods

While many implementations of components have differences, one concept that is fairly universal is “lifecycle methods”. At their core, lifecycle methods enable you to run code when events occur on an element. Even frameworks like React, which haved moved away from classes, still have similar concepts of doing actions when a component is changed in some way.

Let’s take a look at some of the lifecycle methods that are baked into the browser’s implementation.

Custom elements have 4 lifecycle methods that can be attached to a component.

Callback Name	Description
`connectedCallback`	Ran when attached to the DOM
`disconnectedCallback`	Ran when unattached to the DOM
`attributeChangedCallback`	Ran when one of the web component’s attributes is changed. Must explicitly track
`adoptedCallback`	Ran when moved from one HTML document to another

While each of them has their uses, we’ll primarily be focusing on the first 3. adoptedCallback is primarily useful in niche circumstances and is therefore difficult to make a straightforward demo of.

Now that we know what the lifecycle methods are, let’s see an example of them in action.

Connection Lifecycles

The first two lifecycle methods we’ll be talking about are typically used as a pair together: connectedCallback and disconnectedCallback

connectedCallback is ran when a component is mounted onto the DOM. This means that when you want the element to be shown, you can change your innerHTML, add event listeners to elements, or do any other kind of code logic meant to setup your component.

Meanwhile, disconnectedCallback is run when the element is being removed from the DOM. This is often used to remove event listeners added during the connectedCallback, or do other forms of cleanup required for the element.

Here’s a simple web component that renders a header with the text “Hello world”.

class MyComponent extends HTMLElement {
  connectedCallback() {
      console.log("I am connecting");
      this.innerHTML = `<h1>Hello world</h1>`;
  }

  disconnectedCallback() {
      console.log("I am leaving");
  }
}

customElements.define('my-component', MyComponent);

Run this code sample in a playground

Attribute Changed

While there are other methods to pass data to an element (which we’ll touch on shortly), the undeniable simplicity of attributes is hard to deny. They’re widely utilized in HTML-spec tags, and most display custom elements should be able to utilize attributes to pass data from a parent trivially.

While attributeChangedCallback is the lifecycle method used to detect when an attribute’s value is changed, you must tell the component which attributes to track.

For example, in this example we’re tracking the message attribute. If the message attribute value changes, it will run this.render(). However, any other attribute’s value changing will not trigger attributeChangedCallback because nothing else is marked to be tracked.

class MyComponent extends HTMLElement {
  connectedCallback() {
      this.render();
  }

   // Could also be:
  // static observedAttributes = ['message'];
  static get observedAttributes() {
      return ['message'];
  }

  attributeChangedCallback(name, oldValue, newValue) {
      this.render();
  }

  render() {
      const message = this.attributes.message.value || 'Hello world';
      this.innerHTML = `<h1>${message}</h1>`;
  }
}

customElements.define('my-component', MyComponent);

Run this code sample in a playground

You’ll notice that the “attributeChangedCallback” receives the name of the attribute changed, it’s previous value, and it’s current value. This is useful for granular manual change detection optimizations.

However, utilizing attributes to pass values to a component has its limitations. To explain these limitations, we must first start by talking about serializability.

Serializability

Serialization is the process of turning a data structure or object into a format that can be stored and reconstructed later. A simple example of serialization is using JSON to encode data.

JSON.stringify([
    {hello: 1},
    {other: 2}
])

// "[{\"hello\": 1}, {\"other\":2}]"

Because this JavaScript object is simple and only utilizes primitive data types, it’s relatively trivial to turn into a string. This string can then be saved to a file, sent over HTTP to a server (and back), and be reconstructed when the data is needed again.

This simplicity of serialization to JSON is one reason why JSON is such a popular format for transferring data over REST endpoints.

Serializing Limitations

While simple objects and arrays can be serialized relatively trivially, there are limitations. For example, take the following code:

const obj = {
    method() {
        console.log(window);
    }
}

While this code’s behavior may seem simple to us reading it as developers, think about it from a machine’s perspective.

If we wanted to send this object to a server from a client remotely with the method intact, how should we do that?

window, while available in the browser, is not available in NodeJS, which the server may likely be written in. Should we attempt to serialize the window object and pass it along with the method? What about methods on the window object? Should we do the same with those methods?

On the other end of the scale, while console.log **is** implemented in both NodeJS and browsers alike, it’s implemented using native code in both runtimes. How would we even begin to serialize native methods, even if we wanted to? Maybe we could pass machine code? Even ignoring the security concerns, how would we handle the differences in machine code between a user’s ARM device and a server’s x86_64 architecture?

All of this becomes a problem before you even consider that your server may well not be running NodeJS. How would you even begin to represent the concept of this in a language like Java? How would you handle the differences between a dynamically typed language like JavaScript and C++?

Let’s Stringify Some Functions

Now knowing the problems with serializing functions, you may wonder what happens if you run JSON.stringify() on obj?

const obj = {
    method() {
        console.log(this, window);
    }
}

JSON.stringify(obj); // "{}"

It simply omits the key from the JSON string. This is important to keep in mind as we go forward.

HTML Attribute Strings

Why are we talking about serialization in this article? To answer that, I want to mention two truths about HTML elements.

HTML attributes are case insensitive
HTML attributes must be strings

The first of these truths is simply that for any attribute, you can change the key casing and it will respond the same. According to HTML spec, there is no difference between:

<input type="checkbox"/>

And:

<input tYpE="checkbox"/>

The second truth is much more relevant to us in this discussion. While it might seem like you can assign non-string values to an attribute, they’re always parsed as strings under-the-hood.

You might think about being tricky and using JavaScript to assign non-string values to an attribute:

const el = document.querySelector('input');
el.setAttribute('data-arr', [1, 2, 3, 4]);

However, the attribute’s assigned value may not match your expectations:

<input type="checkbox" data-arr="1,2,3,4">

You’ll notice the lack of brackets in the attribute. This is because JavaScript is implicitly running toString on your array, which turns it into a string before assigning it to the attribute.

No matter how you spin it - your attribute will be a string.

This is also why when trying to use attributes for non-string values you may run into otherwise unexpected behavior. This is true even for built-in elements, such as input.

<input type="checkbox" checked="false"/>

Without being aware of this HTML attribute limitation, you may well expect the checkbox to be unchecked. However, when rendered, it appears checked.

Run this code sample in a playground

This is because you’re not passing the boolean false, you’re passing the string "false", which is (confusingly) truthy.

console.log(Boolean("false")); // true

Some attributes are smart enough to know when you’re intending to assign a number or other primitive value to an element via an attribute, but the implementation internally might look something like:

class NumValidator extends HTMLElement {
  connectedCallback() {
      this.render();
  }

  static get observedAttributes() {
      return ['max'];
  }

  attributeChangedCallback(name, oldValue, newValue) {
      this.render();
  }

  render() {
      // Coerce "attribute.value" to a number. Again, attributes
      // can only be passed as a string
      const max = Number(this.attributes.max.value || Infinity);
      // ...
  }
}

While this tends to be the extent of HTML element’s deserializing of attributes, we can extend this functionality much further.

Pass Array of Strings

As we touched on shortly, if we simply try to pass an array to an attribute using JavaScript’s setAttribute, it will not include the brackets. This is due to Array.toString()’s output.

If we attempted to pass the array ["test", "another", "hello"] from JS to an attribute, the output would look like this:

<script>
  class MyComponent extends HTMLElement {
      connectedCallback() {
          this.render();
      }

      static get observedAttributes() {
          return ['todos'];
      }

      attributeChangedCallback(name, oldValue, newValue) {
          this.render();
      }

      render() {
          const todos = this.attributes.todos.value || '';
          this.innerHTML = `<p>${todos}</p>`;
      }
  }

  customElements.define('my-component', MyComponent);
</script>

<my-component id="mycomp" todos="test,another,hello"></my-component>

Run this code sample in a playground

Because of the output of toString, it’s difficult to convert the attribute value back into a string. As such, we only display the data inside of a <p> tag. But lists don’t belong in a single paragraph tag! They belong in a ul with individual lis per item in the list. After all, semantic HTML is integral for an accessible website!

Lets instead use JSON.stringify to serialize this data, pass that string to the attribute value, then deserialize that in the element using JSON.parse.

<script>
  class MyComponent extends HTMLElement {
      connectedCallback() {
          this.render();
      }

      static get observedAttributes() {
          return ['todos'];
      }

      attributeChangedCallback(name, oldValue, newValue) {
          this.render();
      }

      render() {
          const todosArr = JSON.parse(this.attributes.todos.value || '[]');
          console.log(todosArr);
          const todoEls = todosArr.map(todo => `<li>${todo}</li>`).join('\n');
          this.innerHTML = `<ul>${todoEls}</ul>`;
      }
  }

  customElements.define('my-component', MyComponent);
</script>

<my-component todos="[&quot;hello&quot;,&quot;this&quot;]">
</my-component>

Run this code sample in a playground

Using this method, we’re able to get an array in our render method. From there, we simply map over that array to create li elements, then pass that to our innerHTML.

Pass Array of Objects

While an array of strings is a straightforward demonstration of serializing attributes, it’s hardly representative of real-world data structures.

Let’s start working towards making our data more realistic. A good start might be to turn our array of strings into an array of objects. After all, we want to be able to mark items “completed” in a todo app.

For now, we’ll keep it small, and we’ll grow it later. Let’s keep track of the “name” of the todo item, and whether or not it’s been completed:

const data = [{name: "hello", completed: false}];

Let’s take a look at how we can display this in a reasonable manner using our custom element:

<script>
  class MyComponent extends HTMLElement {
      connectedCallback() {
          this.render();
      }

      static get observedAttributes() {
          return ['todos'];
      }

      attributeChangedCallback(name, oldValue, newValue) {
          this.render();
      }

      render() {
          const todosArr = JSON.parse(this.attributes.todos.value || '[]');
          const todoEls = todosArr
              .map(todo => `
              <li>                 
                <!-- checked=”false” doesn’t do what you might think -->
                <input type="checkbox" ${todo.completed ? 'checked' : ''}/>
                ${todo.name}
              </li>
          `)
              .join('\n');
          this.innerHTML = `<ul>${todoEls}</ul>`;
      }
  }

  customElements.define('my-component', MyComponent);
</script>

<my-component
  id="mycomp"
  todos="[{&quot;name&quot;:&quot;hello&quot;,&quot;completed&quot;:false}]">
</my-component>

Remember, checked=”false” will leave a checkbox checked. This is because “false” is a truthy string. Reference our “serializing limitations” sections for more reading.

Now that we’re displaying these checkboxes, let’s add a way to toggle them!

var todoList = [];

function toggleAll() {
  todoList = todoList.map(todo => ({...todo, completed: !todo.completed}));
  changeElement();
}

function changeElement() {
  const compEl = document.querySelector('#mycomp');
  compEl.attributes.todos.value = JSON.stringify(todoList);     
}

Now, all we need to do is run the function “toggleAll” on a button press and it will update the checkboxes in our custom element.

Run this code sample in a playground

Now that we have a way to toggle all checkboxes, let’s look at how we can toggle individual todo items.

Pass Objects with Functions

While there are many ways to have user input in a custom element interact with a parent’s data set, let’s store a method in each todo object and pass it into the custom element.

This pattern follows best practices for components by keeping the data passing unidirectional. In the past, we’ve touched on how to keep your components unidirectional for React and Web Components alike.

Let’s change a todo object to reflect something similar:

todoList.push({
  name: inputEl.value,
  completed: false,
  id: todoId,
  onChange: () => {
    toggleTodoItem(todoId)
  }
});

Then, we’ll simply implement our toggleTodoItem method using the ID to modify the related todo object:

function toggleTodoItem(todoId) {
  thisTodo = todoList.find(todo => todo.id == todoId);
  thisTodo.completed = !thisTodo.completed;
  changeElement();
}

function changeElement() {
  const compEl = document.querySelector('#mycomp');
  compEl.attributes.todos.value = JSON.stringify(todoList);
}

With these changes, we have all of the logic we need from our parent to handle the checkbox logic. Now we need to update our custom element to trigger the onChange method when the checkbox is checked. In order to bind an event listener the “input” element, we need to access the underlying HTMLElement reference. To do this, we’ll need to migrate away from the innerHTML logic we were using previously in favor of document.createElement.

render() {
  this.clear();

  // Create list element
  const todosArr = JSON.parse(this.attributes.todos.value || '[]');
  const todoEls = todosArr
      .map(todo => {
          // Use `createElement` to get access to the element. We can then add event listeners
          const checkboxEl = document.createElement('input');
          checkboxEl.type = "checkbox";

          // This doesn't work, we'll explain why shortly
          checkboxEl.addEventListener('change', todo.onChange);

          checkboxEl.checked = todo.completed;

          const liEl = document.createElement('li');
          liEl.append(checkboxEl);
          liEl.append(todo.name);
          return liEl;
      });

  const ulEl = document.createElement('ul');
  for (const liEl of todoEls) {
      ulEl.append(liEl);
  }

  // Add header. This should update to tell us how many items are completed
  const header = document.createElement('h1');
  header.innerText = todosArr.filter(todo => todo.completed).length;

  // Reconstruct logic
  this.append(header);
  this.append(ulEl);
}

Awesome! Now we’ve made all of the changes required, let’s see if it all works together!

Run this code sample in a playground

Oh… Weird… While our checkboxes seem to be updating, our h1 is not. What’s more, if we look in our developer console, we don’t see the console.logs we would expect to see during a re-render.

Why is that?

Well, as we mentioned in our section about serialization limitations, functions are not serializable. Because of this, when an object with methods are passed to JSON.parse, those keys are removed. When we’re adding our event listener, the function is undefined, and therefore doesn’t do anything.

checkboxEl.addEventListener('change', todo.onChange); // onChange is undefined

The checkbox’s state visually updating without being reflected in our data is an example of a misalignment between the DOM and the data we used to build the DOM.

However, we can verify that our code is correct outside of serialization issues. If we change that line of code to utilize the global function toggleTodoItem directly, it functions as expected:

checkboxEl.addEventListener('change', () => toggleTodoItem(todo.id))

Update this line of code in the sandbox above to see the correct behavior!

While this works for our current setup, one of the advantages of building custom elements is the ability to split out your application to multiple files in order to keep your app’s codebase organized. As soon as toggleTodoItem is no longer in the same scope as the custom element, this code will break.

If this isn’t a good long-term solution, what can we do to fix our issue with serialization?

Pass via Props, not Attributes

Attributes provide a simple method of passing primitive data to your custom elements. However, as we’ve demonstrated, it falls flat in more complex usage due to the requirement to serialize your data.

Knowing that we’re unable to bypass this limitation using attributes, let’s instead take advantage of JavaScript classes to pass data more directly.

Because our components are classes that extend HTMLElement, we’re able to access our properties and methods from our custom element’s parent. Let’s say we want to update todos and render once the property is changed.

To do this, we’ll simply add a method to our component’s class called “setTodos”. This method will then be accessible when we query for our element using document.querySelector.

class MyComponent extends HTMLElement {
  todos = [];

  connectedCallback() {
      this.render();
  }

  setTodos(todos) {
      this.todos = todos;
      this.clear();
      this.render();
  }

  render() {
      // ...
  }
}

// ...

function changeElement() {
  const compEl = document.querySelector('#mycomp');
  compEl.setTodos(todoList);
}

Run this code sample in a playground

Now, if we toggle items in our todo list, our h1 tag updates as we would expect: we’ve solved the mismatch between our DOM and our data layer!

Because we’re updating the properties of our custom elements, we call this “passing via properties”, which solves the serialization issues of “passing via attributes”.

But that’s not all! Properties have a hidden advantage over attributes for data passing as well: memory size.

When we were serializing our todos into attributes, we were duplicating our data. Not only were we keeping the todo list in-memory within our JavaScript, but the browser keeps loaded DOM elements in memory as well. This means that for every todo we added, not only were we keeping a copy in JavaScript, but in the DOM as well (via attribute string).

But surely, that’s the only way memory is improved when migrating to properties, right? Wrong!

Because keep in mind, on top of being loaded in-memory in JS in our main script tag, and in the browser via the DOM, we were also deserializing it in our custom element as well! This meant that we were keeping a third copy of our data initialized in-memory simultaneously!

While these performance considerations might not matter in a demo application, they would add significant complications in production-scale apps.

Conclusion

We’ve covered a lot today! We’ve introduced some of the core concepts at play with web components, how we’re able to best implement various functionality, and the limitations of the DOM.

While we spoke a lot about passing data by attributes vs. properties today, there are pros and cons to both. Ideally, we would want the best of both worlds: the ability to pass data via property in order to avoid serialization, but keep the simplicity of attributes by reflecting their value alongside the related DOM element.

Something else we’ve lost since the start of this article is code readability in element creation. Originally, when we were using innerHTML, we were able to see a visual representation of the output DOM. When we needed to add event listeners, however, we were required to switch to document.createElement. Preferably, we could attach event listeners without sacrificing the in-code HTML representation of our custom element’s rendered output.

While these features may not be baked into the web component specifications themselves, there are other options available. In our next article, we’ll take a look at a lightweight framework we can utilize to build better web components that can integrate with many other frontend stacks!

GitHub Copilot Breaks Bad Interviews

CoderPad Team — Tue, 22 Mar 2022 12:37:42 +0000

GitHub Copilot was recently announced! In the past few years, we’ve seen artificial intelligence (AI) revolutionize aspects of technology such as image recognition, recommendation algorithms, and more. With Copilot, GitHub is hoping to add “code generation” to that list of items. In this article, we’ll explain what GitHub Copilot is, why some people are concerned with allowing its usage in technical interviews, and how to build your interviews to be better in general and therefore more resilient to auto-generated code.

What is GitHub Copilot?

GitHub Copilot is a VSCode extension that’s able to autocomplete code snippets. While we've had some form of code completion for some time now, they've been relatively limited in one way or another. Usually, they tend to rely on existing code in your files or can only suggest a tiny amount of code per suggestion. Other times, code completion can be no more than a predefined snippet of code without considering any additional context.

Copilot offers the ability to suggest multi-line and contextually aware code suggestions - powered by AI. GitHub says this tool is available for most programming languages and can implement entire functions off of their names alone.

They’re not alone in this endeavor, however. GitHub is working in collaboration with OpenAI, the company behind the extremely powerful GPT-3 AI tool. Between the training dataset consisting of GitHub’s public source code and OpenAI’s expertise in AI generation, it has the potential to provide impressive results.

Taking an example from their website, it’s able to generate an implementation of a date utility from nothing more than the function name.

It’s incredible that given the simple input of:

function calculateDaysBetweenDates(date1, date2) {

It’s able to generate the following code which functions how you might expect:

function calculateDaysBetweenDates(date1, date2) {
  var oneDay = 24 * 60 * 60 * 1000;
  var date1InMillis = date1.getTime();
  var date2InMillis = date2.getTime();
  var days = Math.round(Math.abs(date2InMillis - date1InMillis) / oneDay);
  return days;
}

While every new tech has its naysayers, and even some on our team are skeptical of its true utility, it’s undoubtedly a powerful tool that will, for some, change the way they write code.

GitHub’s not alone in this venture of AI-powered code generation, either! Other companies, such as Kite or TabNine are working hard at this problem space as well! Whether we want it to or not, AI-generated code helpers are here to stay.

How does Copilot Threaten Tech Interviews?

In the current tech interview landscape, algorithms reign as the leading method of technical assessment. While we’ve touched on why this shouldn’t be the case before, Copilot in particular breaks algorithm questions in significant ways by being able to rapidly generate solutions to algorithmic problems.

Let’s see how Copilot interacts with some common interview questions.

One common question that’s a favorite of interviewers hoping to quickly glean mathematical competency is a function to check if a given number is prime or not.

Well, it’s been a few years since I’ve refreshed my math skills, so they might be a little shakey. I should be able to figure it out all the same.

Let’s open VSCode and start implementing the function.

Wow! I hadn’t even had a chance to add the parameters to the “isPrime” function before Copilot had already made a suggestion!

Looking through the suggested code, it seems clean and functions as expected!

function isPrime(n) {
    if (n < 2) return false;
    for (var i = 2; i < n; i++) {
        if (n % i == 0) return false;
    }
    return true;
}

Sure, we could change the var to a const, but this is code that I wouldn’t blink twice at in a code review!

While this may seem like an outlier, Copilot seems to excel in these algorithm-based questions.

But surely isPrime would be too trivial for a real interview question, right? Perhaps, but watch what happens when a popular coding YouTuber attempts to utilize Copilot to solve Leetcode interview questions

https://www.youtube.com/watch?v=FHwnrYm0mNc

Without fail, Copilot is able to generate usable code for each difficulty level of algorithms given to it. Further, the solutions are all more performant than the average of submissions. For the permutation question, it’s able to be faster than 88% of other submissions!

“Given how predominant these types of interview questions are, we could be in big trouble if some candidates are less-than-forthcoming with their usage of Copilot in coding exercises.”

While this may be true for some interviews, if your interviews are susceptible to collapse with Copilot in the picture, you’re already facing this problem whether you’re aware of it or not.

Algorithms Are Breaking Your Interviews

On paper, algorithm based interview questions sound like a great way to assess a candidate's skills. They can help give guidance on a candidate's understanding of logic complexity, how efficient (or inefficient) a specific solution is, and is usually an insight into a candidate’s ability to think in abstract manners.

However, in practice algorithm questions tend to go against the grain of real-world engineering. Ideally, an interview process should act as a way to evaluate a candidate’s ability to do the same kind of engineering they’d be using in their projects at your company. While a developer may, with resources, implement an algorithm once in a while, they’re more than likely doing things like refactoring significantly more often.

We’ve written more about how algorithms aren’t often effective as interview questions in the past.

But more than being unrepresentative of the job, algorithm questions are often easy to cheat - without the use of GitHub Copilot. Because most algorithm questions are significantly similar to each other, there’s often a small selection of tips and tricks a candidate can memorize in order to drastically improve their output in these styles of interviews.

There’s even the potential for a candidate to be able to output an algorithm verbatim. There are hundreds of sites that will give a candidate one algorithm question after another in the hopes of improving their understanding of these algorithms.

But with GitHub Copilot, the propensity for cheating on an algorithm question rises significantly. As we’ve demonstrated previously in the article, it’s capable of generating significant portions of code at a time. In fact, Copilot is so proficient at algorithm questions that a non-trivial number of algorithm questions we asked it to solve were done before we could even finish the function signature. All it takes is a candidate to give Copilot the name of the function and paste the results into their assessment editor.

Further, folks wanting to cheat have had the ability to do something similar for some time now in the form of forum questions. Simply lookup any algorithm on a code forum or site like StackOverflow and you can find hundreds of answers at your disposal.

In fact, many have pointed out that Copilot’s process of looking up code based on its expected constraints is similar to one that a developer might experience by searching StackOverflow for code snippets. Funnily, some thought the idea so similar they decided to build an alternative VSCode plugin to Copilot that simply looks up StackOverflow answers as suggestions.

Regardless of how the question is answered, a candidate’s skill at these types of questions might not reflect their capabilities in other aspects of the codebase. That’s why, in order to access candidates properly, it might be the right move to move away from these questions.

How to Fix Your Interviews

While you could simply require candidates to use a non-VSCode IDE for your technical assessments, there are no guarantees that your take-home projects will be spared the same fate. Further, while VSCode is the launch platform for Copilot, it’s more than likely to gain plugins for other IDEs in the future as well.

But what of it? Let’s say your company doesn’t do take-home projects (even though you totally should), what of it? Well, even if restricting VSCode would work to avoid Copilot for a while, you ideally want to be able to standardize your IDE platform for all candidates.

Plus, as we touched on in the previous section, algorithm-based interview questions are still able to be manipulated - with or without Copilot.

The solution to fixing your interviews should be two-fold:

More representative questions of the job
- Require more thought process than memorization
Better communication with candidates

For the first, make sure your questions are examples of real-world challenges you’ve seen in your project’s codebase. Some great examples of this might be “setting up a backend endpoint connected to your database” or “refactor this React component to be unidirectional”.

If you’re using CoderPad, we have a great selection of questions available in our Question Bank that you can personalize to fix the unique needs of your team

The second point might sound obvious, but look at it this way: Engineering often utilizes more “soft” skills than we usually credit. In any engineering team you’ll need to do code review, create technical documentation, and communicate with others on your team. Being able to program is well and good, but without soft skills your ability to leverage those skills goes flat.

Even if a candidate does end up using Copilot to generate a non-trivial portion of a candidates’ submitted code, you should be able to ask them what their review process of the generated code looked like. Does it follow their code standards? What alternatives did it suggest and why did they choose that one? How maintainable is said code? Are there edge-cases not yet covered?

Conclusion

GitHub Copilot is a remarkable piece of technology. It will be interesting to watch as it continues to develop and see how developers will utilize it in their day-to-day. As it becomes more and more relevant, we need to make sure our interviews are structured to handle(and prevent) its capabilities.

In fact, we’ve created a GitHub repo to showcase a wide range of interview questions that Copilot has been able to successfully generate, given little input.

Feel free to open a PR if you find a question that you think should be present. If you’re worried about your interview question being susceptible to Copilot, maybe drop by the repo and see if it’s in the list.

Introduction to Web Accessibility (A11Y)

CoderPad Team — Fri, 18 Mar 2022 17:24:09 +0000

If you’ve come across this article but haven't heard about web accessibility (often shortened to "A11Y") before, that's okay. We're all learning at different speeds and come across new things all the time. That said, accessibility is a critical component of any frontend engineer's responsibilities. We implore you to explore what that means, not just in this blog post but beyond with your teams and communities.

First, let's define what "accessibility" is. Accessibility in engineering is "the process of creating products that are usable by people with the widest possible range of abilities."

One example of accessibility is the needs of blind or low-vision users. They may rely on screen readers or other assistive technologies, which allows them to navigate their computer with their other senses. These methods may be used in tandem with the visual experience for some or used independently to navigate their computer auditorily or tactilely.

Another example is users with limited mobility who utilize specialty hardware, such as buttons, to trigger different behaviors on their machine.

If you're a visual learner who would like to see some short-and-quick workflows from users like this, one of Apple's ads displays a few use cases that proper accessibility support can enable.

Something to keep in mind is that these disabilities may not be permanent. For instance, if you fall and break your arm, you may be only using one arm while healing. Likewise, there are situational impairments as well. If you're holding a cup of coffee in one hand, you'll only be using the other for device usage. Here's a chart that outlines a few more of these examples:

	Permanent	Temporary	Situational
Touch	One arm	Arm injury	New parent
See	Blind	Cataract	Distracted driver
Hear	Deaf	Ear infection	Bartender
Speak	Non-verbal	Laryngitis	Heavy accent

Microsoft originally created this chart as part of their Inclusive Toolkit manual

Creating an application that's accessible means that you're making a better experience for all of your users.

In addition to both moral and financial incentives (by opening the door to more users), many organizations have a legal requirement to meet accessibility. U.S. government software is subject to Section 508, which requires compliance to the Web Content Accessibility Guidelines (also known as WCAG, which we'll touch on later). Likewise, private US companies may be subject to compliance due to the "Americans with Disabilities Act" (shortened to "ADA"). The U.S. isn't the only country with these requirements, either. According to WCAG's reference page for various legal laws, there are at least 40 such laws in place around the world.

Please note that we are not giving legal advice. This article is simply meant for educational purposes for individuals. Consult legal authorities for the appropriate jurisdiction

Accessibility isn't a pure science, however. If you aren’t a user of assistive technology, this may be an abstract idea at first. However, think of it like this: the colors an app uses or a button's visual placement may convey different messages and meanings depending on their context. This same problem applies to users of screen-readers and other accessible tech as well, just with different constraints. If the screen is visually cluttered, the content may be more difficult to read. Likewise, different accessibility methods will lead to different experiences for users of assistive technology. In both of these scenarios, there may not be objectively correct answers - some may prefer a button placed visually to the left, while others might advocate for it on the right. Similarly, how something is read using a screen reader may make sense to some, but might be confusingly expressed to others.

Sensible Standards

While accessibility has some levels of subjectivity, it's important to note that there are standards surrounding web application's accessibility support. "Web Content Accessibility Guidelines" (shortened to "WCAG") are guidelines to follow when considering your app's accessibility. These guidelines are published by a subgroup of the World Wide Web Consortium (shortened to "W3C"), the main international standards organization for the Internet. WCAG acts as the de-facto standard for accessibility guidelines.

There are different scales of accessibility as well. WCAG includes three different levels of conformance:

Level A is the minimum level.
Level AA includes all Level A and AA requirements. Many organizations strive to meet Level AA.
Level AAA includes all Level A, AA, and AAA requirements.

Meeting AA requirements is typically seen as a good commitment to accessibility, but AAA will open more doors to your users and is the gold standard for accessible user experience.

Far from a comprehensive list, A requires:

Meanwhile, AA covers things like:

Screen reader experience
Minimum contrast guidelines
Text resize support
Video captions
Basic support for keyboard navigation

Finally, AAA includes support for:

Enhanced contrast
Reduced/restricted animations
Video sign language support
Full website functionality with keyboard

Interested in reading the full list? Read the quick reference to WCAG 2.1.

Smartly using Semantic HTML Tags

One of the easiest things you can do for your application's accessibility is to use semantic HTML tags.

Let's say we have HTML to display fruits in a list:

<!-- Inaccessible -->
<div>
    <div>Orange</div>
    <div>Banana</div>
    <div>Grapefruit</div>
</div>

While this will display the contents, and you may be able to use CSS to add styling to make this look like a list, the browser has no way of knowing that this is a list. This is reflected in how screen readers read that HTML output.

Voiceover reading of the content above

Likewise, search engine crawlers won't know that this is a list. If you're only using div tags as far as Google's concerned, you have no lists, no headings, nothing. This makes the page significantly less engaging and therefore rank more poorly.

Let's compare that to using the correct HTML tags for a list.

<!-- Accessible -->
<ul aria-label="Fruits">
    <li>Orange</li>
    <li>Banana</li>
    <li>Grapefruit</li>
</ul>

Voiceover reading of the content above

As you may be able to hear, this screen reader is now able to read out that it's a list and its name. It makes navigation of that list easier for those users by allowing them to quickly skip to the next list item and hear the index of an item in the list.

Not only does this enhance the experience of assistive technology users browsing your list, but because search engine crawlers rely on HTML tags to inform what's what, your site may rank better in search engine queries as well! This is a massive boon to your site's SEO score.

Understand `aria-` properties

In our previous example, we used an HTML attribute aria-label on our ul. ARIA is collection of HTML attributes that allow you to enhance the accessibility in applications. That said, it is highly encouraged to use the suggested HTML tags instead of aria attributes whenever possible. Think of aria as a complex low level API that can enhance your experience when done properly, but drastically harm user experience when improperly utilized.

No ARIA is better than Bad ARIA WCAG WAI-ARIA Authoring Practices

A super small small subsection of aria- attributes includes:

aria-labelledby — Associate the element with another element's text as the label
aria-expanded — A Boolean value meant to communicate when a dropdown is expanded
aria-valuemin — The minimum allowed value in a numerical input
aria-valuemax — The maximum allowed value of a numerical input

Additional to aria props, the role property allows to tell the browser what an element's intended purpose is, thus changing it's behavior with accessible tech. Again, this is a highly advanced (and often incorrectly deployed) API for complex apps. To learn more, read through Mozilla's ARIA basics article.

Classy CSS

While HTML relays a significant amount of information to assistive technologies like screen readers, it's not the only thing used to inform those tools. Certain CSS rules can change the functionality as well. After all, screen readers (and other tools) don't look through the source code of a website. Instead, they're looking at the accessibility tree: a modified version of the DOM. The accessibility tree and the DOM are both constructed by the browser from the website's source code.

Want to learn more about the DOM, how the browser constructs it, and what it's used for internally? This article helps explain this in detail.

Because the DOM is influenced by CSS, it impacts the accessibility tree as well. For example, display: none removes the element from the accessibility tree and from the browsers visual output. This means that screen readers won't read the contents of an element with that rule applied. However, visibility: hidden or width: 0px will hide an element visually, but will still be read by screen readers.

For this reason, there's a frequently used CSS class used to hide elements visually but not from screen readers:

.sr-only {
    position: absolute;
    width: 1px;
    height: 1px;
    padding: 0;
    margin: -1px;
    overflow: hidden;
    clip: rect(0, 0, 0, 0);
    white-space: nowrap;
    border-width: 0;
}

There are many ways which CSS can influence assistive technologies. Ben Myers covers this more in his blog post.

Contrast is Cool

While screen readers are imperative to frontend accessibility testing, a site's visuals can help provide a good experience for many users. While a certain color palette may be aesthetically pleasing, it may be difficult to read for a colorblind user. Colorblind users aren't the only ones impacted, however.

While there are various reasons a user might not be able to see weakly contrasted color, everyone is different. See if you can distinguish the text from the background in the displayed image with poor contrast:

Now, compare that to highly contrasting colors:

The contents are not only easier to distinguish from the background, but it's made easier to focus on as a result of the increased contrast.

This said, not all contrasts are the same. Per WCAG guidelines, you may have a different ratio of contrast for different compliance levels. These contrast ratios depend on both font size as well as compliance level.

In this example you can see that the text passes the WCAG AA requirements for large text, but fails the same requirements for small text.

Fantastic Fonts

One of the most widely used accessibility features is font scaling. While many browsers default to a font size of 16px, the user is actually able to change settings on their device to configure websites to use a larger font size.

Many phones using iOS and Android allow users to change the font size on their mobile devices. This feature is so commonplace that it often prompts users to change this setting when the phone is being set up.

iOS font size settings screen

Android font size settings screen

Not only do you have these settings on mobile devices, but they're available on desktop as well.

Using Chrome, go to your settings page, and you should be able to set your font size.

You can do the same in Firefox in your preferences.

Implementation

While browsers have the ability to set the font size, if you're using px, vw, vh, or other unit values for your fonts, the browser will not update these font sizes for you. In order to have your application rescale the font size to match the browser settings, you'll need to use the rem unit.

You can think of rem as a multiplier to apply to the default font size. When the browser's font size is set to 16px:

1rem will be 16px (1 * 16px)
1.5rem will be 24px (1.5 * 16px)
3rem will be 48px (3 * 16px)

Likewise, when the browser's font size is set to 20px:

1rem will be 20px (1 * 20px)
1.5rem will be 30px (1.5 * 20px)
3rem will be 60px (3 * 20px)

Something to keep in mind is that rem is a relative font size. It's relative to the root element's font size. This means that you cannot set a default px value font size in CSS to the <html> tag or to the :root selector, as it will disable font scaling, even if the rest of your page is using rem values.

It's highly encouraged to keep body text size standardized around the 1rem value. While this may seem like a frustrating limitation at first, see it from the user's perspective. Font sizes can, of course, be larger than this for things like headers or callouts, but the primary content of your site should default to this sizing.

Say site "A" sets their font size to 1rem, and site "B" sets their font size to 0.8rem. When the user switches from "A" to "B", the font size drastically decreases, requiring the user to change their font size. Then, when they switch back to site "A", they're left with too large of font size. By respecting the user's setting of font size, you're ensuring that their experience jumping from site to site is more consistent and a nicer experience.

Want to learn more about rem and font sizing? Take a look at this in-depth blog post that covers even more.

Keyboard is King

Just as developers have preferences with keyboard or mouse, so too do your end-users. Some people may only be able to utilize the keyboard to navigate the digital world. Not only is keyboard navigation critical for accessibility, but it enables power users of your application to be more efficient as well.

While you may immediately think of "keyboard shortcuts" to trigger different applications, it's often easy to forget about smaller interactions as well.

This isn't to say that keyboard shortcuts aren't helpful - they can serve as shorthand for operations that might otherwise take considerable more effort using only the keyboard. Do consider implementing them in your app when they make sense.

Consider a site with a large number of navigation links like The New York Times.

Their site has 30+ individual items in their header that you'd need to tab through in order to get to the main portion of the website. Safe to say that most users of the site are likely to want to access that main content quickly. Additionally, users that rely on a screen reader that aren't familiar with the site's layout wouldn't know when to stop tabbing without slogging through every item in the header.

As such, many sites (including New York Times) include a "Skip to Content" button that doesn't become visible until you've tabbed into it. Unless you were navigating the site by keyboard, you wouldn't know it was there.

This is far from the only considerations that should be made when considering a site's keyboard navigability, but is a prime example of a solution to a problem that might not be immediately obvious to users that primarily use the mouse.

Focus Indicators

Something to keep in mind is that not all keyboard users use screen readers. Because of this, it's important to have an outline around the element you're currently focused on. Without this outline, how would a sighted person know where they are on the page?

Imagine trying to use your mouse without being able to see your cursor or hover effects on elements — it would be nearly impossible to know what you were doing!

Luckily, the browser provides a default outline out-of-the-box. That said, some developers unfamiliar with accessibility requirements may disable the outline, as they "don't like the look of the outline when using a mouse" or "think the outline is too obtrusive visually". They often do this by adding an outline: none rule to the element, which breaks the behavior of the browser.

Instead, it's suggested to either:

Style the outline to be more consistent with your project's visuals (similarly to how The New York times made their outline styling black to match their site)
Style the element in some other way to indicate focus (avoid only using colors to differentiate, as colorblind users may not be able to distinguish the differences)
Use JavaScript to disable the behavior when mouse-events are detected (and re-enable if keyboard events are detected)

To learn more about the focus indicator and how to work alongside it, check out this blog post from The A11Y Project.

Humans Can’t Be Automated

The perception for some is that accessibility is something that can be 1:1 adapted from an existing design. This is often untrue. You may want to add a "Skip to contents" button that only shows up with tabbing for some sites, while the visual order and tab order might need to be flipped for a better experience for screen-reader users. Remember, accessibility is a form of user experience that has to be crafted by hand. Each decision has nuance to it, and there are rarely objectives of which experience is better than others. Because of this, many companies will have dedicated accessibility specialists alongside their design and engineering teams.

You also need to make sure to test your application as you would any other part of your app. Automation is helpful here, but humans are still critical. We'll touch on this more in a future section.

If anyone is ever advertising to you that your inaccessible project can be made accessible (or prevent lawsuits) without any changes to your codebase, they're either lying to you or don't understand accessibility.

Assistance is Amicable

While full automation will never be possible for improving a project's accessibility, not everyone proposing assistance in the process is trying to sell snake oil.

For example, Deque's open-source Axe project can help identify issues such as common HTML semantic errors, contrast problems, and more. There are even libraries that help integrate Axe into your project's linters, such as one for React called eslint-plugin-jsx-a11y.

However, keep in mind that these tools are not infallible and are meant to supplement accessibility experts working with your engineering team, not replace them.

Test, Test, Test Again

Testing is a critical component of any application release. Whether using automated testing solutions or QA teams, they help ensure that your users are getting the best experience possible without regressions in an application's behavior.

As a developer working on the frontend, you should be regularly using an assistive technology like a screen reader to analyze your site and navigating your application with only your keyboard. This will help enforce the feedback loop between building the functionality and getting it shipped to users. Make it part of your code review process — have other members of your team test with a screen reader as they would visually analyze new features.

You're also able to include automated tests that will help with accessibility regressions. Either using integration tests or end-to-end tests, you can use real-world behavior such as "search for an element with this label" or "tab over to this button" to ensure your application is functioning as intended.

As mentioned in a previous section, the process to make your app accessible cannot be fully automated. This extends to testing as well. While real-world automated tests are fine and well, you need someone to experience the application on a broader scale to make sure the experience is as fluid as it can be. While a specific component might be accessible by default, perhaps in specific usages, it falls flat. Displaying an accessibility statement while transforming your users' reported problems into bug tickets and performing user testing with disabled users are great ways to close the loop with the real people affected.

Fantastic Features

While there is plenty you can do to make existing functionality accessibility friendly, it's often forgotten that a strongly accessible app may opt to add specific functionality for its users with disabilities.

Some great examples of things like this are sites with lots of user-generated content. For example, Twitter allows its users to add alternative (alt) text to their uploaded images and GIFs. Likewise, YouTube has the ability to add subtitles and captions to uploaded videos on their platform.

Oftentimes, you'll find that these features benefit everyone, not just assistive technology users. You may want to watch a video in a crowded area; with closed captions, that's a much easier sell than trying to hear over others and interrupting everyone around you.

Radical Research

While we've done our best to have this article act as a starting point for accessibility, there's always more to cover. Let's talk about some of the ways you can continue learning more.

Terminology

During your journey to learn more, you may run into terms that you're not familiar with. Let's take a look at some of the more predominant ones. We'll start this discussion of terminology with a common question:

What's "A11Y"?

A11Y is a nymeronym which stands for "accessibility". It's used as shorthand for the word in conversations about the subject.

Some other terms that might helpful are:

"UI" — "User interface". The visual styling of an app
"UX" — "User experience". The interaction the user has with the app that defines their experience. This extends to assistive technology
"WCAG" — "W3C Accessibility Guidelines", the standard guidelines for applications' accessibility support
"W3C" — "World Wide Web Consortium", the organization that publishes WCAG
"ADA" — "Americans with Disabilities Act", regulations in the US for businesses and governments which prohibits discrimination based on disability
"Alternative text"/"Alt text" — Short text used to describe images and other non-text assets

Tools

People in need of a screen reader have multiple options at their disposal. Just a few of them include:

JAWS — An incredibly popular paid Windows screen reader
NVDA — A Windows screen reader
VoiceOver — The screen reader for iOS and macOS
TalkBack — The screen reader for Android

It's important to keep in mind that just as browsers may have differing behaviors for CSS or JavaScript, so too may these screen readers. Be sure to test with more than one of them as you would with different browsers.

Screen readers aren't the only accessible tech, however. A small example of them might be:

Additional Resources

Additionally, there are a few sites that contain extensive lists of additional resources:

Conclusion

We hope you've enjoyed learning from our accolade-worthy alliterative headlines.

There are so many things that we wanted to include in this article but couldn't. Like most parts of engineering, the field of accessible design and the nuances within can be incredibly complex in fringe scenarios. Getting accessibility in a great place for your users takes active effort - just like any other part of building your app. Because of this, we encourage you to do further research on the topic. Don't be afraid to ask questions of community members, either! Many in the community are incredibly helpful and friendly.

Speaking of community, we'd love to hear your thoughts on this article. Did you learn something from it? Have questions about something accessibility-related? Think we missed something? Join our Slack community and chat with us or send us a Tweet!

Python List Comprehension – The Comprehensive Guide

CoderPad Team — Thu, 15 Jul 2021 06:02:14 +0000

Python list comprehensions allow for powerful and readable list mutations. In this article, we'll learn many different ways in how they can be used and where they're most useful.

Python is an incredibly powerful language that’s widely adopted across a wide range of applications. As with any language of sufficient complexity, Python enables multiple ways of doing things. However, the community at large has agreed that code should follow a specific pattern: be “Pythonic”. While “Pythonic” is a community term, the official language defines what they call “The Zen of Python” in PEP 20. To quote just a small bit of it:

Explicit is better than implicit.

Simple is better than complex.

Complex is better than complicated.

Flat is better than nested.

Introduced in Python 2.0 with PEP 202, list comprehensions help align some of these goals for common operations in Python. Let’s explore how we can use list comprehensions and where they serve the Zen of Python better than alternatives.

What is List Comprehension?

Let’s say that we want to make an array of numbers, counting up from 0 to 2. We could assign an empty array, use range to create a generator, then append to that array using a for loop

numbers = []
for x in range(3):
    numbers.append(x)

Alternatively, we could use list comprehension to shorten that to one line of code.

numbers = [x for x in range(3)]

Confused on the syntax? Let’s outline what’s happening token-by-token.

The first and last brackets simply indicate that this is a list comprehension. This is also how I remember that a list comprehension outputs an array - it looks like we’re constructing an array with logic inside.

Second, we have the “x” before the “for”. This is the return value. This means that if we change the comprehension to:

numbers = [x*2 for x in range(3)]

Instead of “0, 1, 2”, we’d get “0, 2, 4”.

Next up, we have a declaration of a for loop. This comprises of three separate parts:

“for” - the start of the loop
“x” - declaring the name of the variable to assign in each iteration
“in” - denoting the start of listening for the iterator

Finally, we have the range. This acts as the iterator for the for loop to iterate through. This can be replaced with anything a for loop can go through: a list, a tuple, or anything else that implements the iterator interface.

Are List Comprehension Pythonic?

While it might seem counterintuitive to learn a new syntax for manipulating lists, let’s look at what the alternative looks like. Using map, we can pass an anonymous function (lambda) to multiply a number by 2, pass the range to iterate through. However, once this is done, we’re left with a map object. In order to convert this back to a list, we have to wrap that method in list.

numbers = list(map(lambda x: x*2, range(3)))

Compare this to the list comprehension version:

numbers = [x*2 for x in range(3)]

Looking at the comprehension, it’s significantly more readable at a glance. Thinking back to The Zen of Python, “Simple is better than complex,” list comprehensions seem to be more Pythonic than using map.

While others might argue that a “for” loop might be easier to read, the Zen of Python also mentions “Flat is better than nested”. Because of this, list comprehensions for simple usage like this are more Pythonic.

Now that we’re more familiar with basic usage of list comprehension, let’s dive into some of it’s more powerful capabilities.

Filtering

While it might seem like list comprehension is only capable of doing a 1:1 match like map, you’re actually able to implement logic more similar to filter to change how many items are in the output compared to what was input.

If we add an if to the end of the statement, we can limit the output to only even numbers:

even_numbers = [x for x in range(10) if x%2==0] #[0, 2, 4, 6, 8]

This can of course be combined with the changed mutation value:

double_even_numbers = [x*2 for x in range(10) if x%2==0] #[0, 4, 8, 12, 16]

Conditionals

While filtering might seem like the only usage of if in a list comprehension, you’re able to use them to act as conditionals to return different values from the original.

number_even_odd = ["Even" if x % 2 == 0 else "Odd" for x in range(4)]
# ["Even", "Odd", "Even", "Odd"]

Keep in mind, you could even combine this ternary method with the previous filtering if:

thirds_even_odd = ["Even" if x % 2 == 0 else "Odd" for x in range(10) if x%3==0]
# [0, 3, 6, 9] after filtering numbers
# ["Even", "Odd", "Even", "Odd"] after ternary to string

If we wanted to expand this code to use full-bodied functions, it would look something like this:

thirds_even_odd = []
for x in range(10):
    if x%3==0:
        if x%2==0:
            thirds_even_odd.append("Even")
        else:
            thirds_even_odd.append("Odd")

Nested Loops

While we explained that you’re able to have less items in the output than the input in our “filtering” section, you’re able to do the opposite as well. Here, we’re able to nest two “for” loops on top of each other in order to have a longer output than our initial input.

repeated_list = [y for x in ["", ""] for y in [1, 2, 3]]
# [1, 2, 3, 1, 2, 3]

This logic allows you to iterate through two different arrays and output the final value in the nested loop. If we have to rewrite this, we’d write it out as:

repeated_list = []
for x in ["", ""]:
    for y in [1, 2, 3]:
        repeated_list.append(y)

This allows us to nest the loops and keep the logic flat. However, you’ll notice in this example, we’re not utilizing the “x” variable. Let’s change that and do a calculations based on the “x” variable as well:

numbers_doubled = [y for x in [1, 2] for y in [x, x*2]]
# 1, 2, 2, 4

Now that we’ve explored using hard-coded arrays to nest loops, let’s go one level deeper and see how we can utilize list comprehensions in a nested manner.

Nested Comprehensions

There are two facts that we can combine to provide list comprehension with a super power:

You can use lists inside of a list comprehension
List comprehensions returns lists

Combining these leads to the natural conclusion that you can nest list comprehensions inside of other list comprehensions.

For example, let’s take the following logic that, given a two-dimensional list, returns all of the first index items in one list and the second indexed items in a second list.

row_list = [[1, 2], [3,4], [5,6]]
indexed_list = []
for i in range(2):
    indexed_row = []
    for row in row_list:
        indexed_row.append(row[i])
    indexed_list.append(indexed_row)

print(indexed_list)
# [[1, 3, 5], [2, 4, 6]]

You’ll notice that the first indexed items (1, 3, 5) are in the first array, and the second indexed items (2, 4, 6) are in the second array.

Let’s take that and convert it to a list comprehension:

row_list = [[1, 2], [3,4], [5,6]]
indexed_list = [[row[i] for row in row_list] for i in range(2)]
print(indexed_list)
# [[1, 3, 5], [2, 4, 6]]

Readable Actions and Other Operators

Something you may have noticed while working with list comprehension is how close some of these operators are to a typical sentence. While basic comprehensions serve this well on their own, they’re advanced by the likes of Python’s other grammatical-style operators. For example, operators may include:

and - Logical “and”
or - Logical “or”
not - Logical “not”
is - Equality check
in - Membership check/second half of for loop

These can be used for great effect. Let’s look at some options we could utilize:

vowels = 'aeiou'
word = "Hello!"

word_vowels = [letter for letter in word if letter.lower() in vowels]

print(word_vowels)

# ['e', 'o']

Alternatively we could check for consonants instead, simply by adding one “not”:

word_consonants = [letter for letter in word if letter.lower() not in vowels]
# ['H', 'l', 'l']

Finally, to showcase boolean logic, we’ll do a slight contrived check for numbers that mod 2 and 3 perfectly but are not 4:

restricted_number = 4

safe_numbers = [x for x in range(6) if (x%2==0 or x%3==0) and x is not restricted_number]

# [0, 2, 3]

Conclusion & Challenge

We’ve covered a lot about list comprehension in Python today! We’re able to build complex logic into our applications while maintaining readability in most situations. However, like any tool, list comprehension can be abused. When you start including too many logical operations to comfortably read, you should likely migrate away from list comprehension to use full-bodied for loops.

For example, given this sandbox code pad of a long and messy list comprehension, how can you refactor to remove all usage of list comprehensions? Avoid using map, filter or other list helpers, either. Simply use nested for loops and if conditionals to match the behavior as it was before.

See the code challenge here

This is an open-ended question meant to challenge your skills you’ve learned throughout the article!

Stuck? Wanting to share your solution? Join our community Slack, where you can talk about list comprehensions and the challenge in-depth with the CoderPad team!

5 Tips for Better Tech Recruiting

CoderPad Team — Wed, 07 Jul 2021 18:39:57 +0000

Tech recruiting is difficult. Interviews are tricky for candidates - and for interviewers. One of the untold challenges of interviewing is knowing how to set up good candidates for success. After all, you want a process that tests the right skills, and filters out the noise that is not helpful to evaluating candidates.

This can be done in many ways, but let’s talk about a few today.

Don’t Be Afraid To Help

Something to keep in mind while interviewing candidates is that they’re just like you and me: people. People that make mistakes from time-to-time or might get stuck on a certain phrasing of a question. This should never leave your mind while tech recruiting.

Oftentimes, lending a gentle helping hand can be the ticket to a successful interview. It can be as simple as rephrasing the question in a way that points towards the solution, or providing a structural bit of code that needs tweaking in order to be solved.

This is particularly beneficial for junior engineers, who’s interviews should focus more on “thought process” and “ability to learn and communicate” than existing skill sets. However, even senior engineers can have the solution escape them until it finally clicks with some small assistance.

While this all might seem counterintuitive to assist a candidate (even in small ways) during an interview, you have to remember that they need support. In their future role with your company, they won’t (and shouldn’t) be working in isolation. Instead, they will have a team to lean on. By giving a small hint here and there, you’re able to understand how they receive feedback and when they need help.

Allow for Resources

As mentioned earlier, candidates are just people. Because of that, you will never find an all-knowing candidate who only ever relies solely on their existing knowledge to fix an issue (no matter what big-ego Jim says). Time-and-time again we’ve heard from seasoned developers that research and cheat-sheets are part of their daily engineering work.

While it might not be immediately obvious, knowing how to search for and find the relevant content is incredibly important. Not only that, it’s something that’s developed gradually alongside a developer’s journey - just like any other skill.

After all, the point of coding interviews as part of tech recruiting is to see how capable a developer is at the job they’re applying for. You want to test in real-world situations, not in an isolated environment that doesn’t represent the daily aspects of the job.

Less Algorithms, More Demos

Speaking of representing a job in a more realistic light: think about the last time you had a ticket in your backlog that required discussion of tree reversal (or similar algorithm). Now think of the last time you asked a question like that in your interviews. See where I’m going here? I’m not implying that algorithm questions are inherently bad for every position, but in this industry they’ve been used as a stop-gap for more relevant questions. This is the number one complaint I've heard against most tech recruiting.

Many engineers can attest to being asked algorithmic questions in an interview - only to be working with styling and application state management in their day jobs. The usage of complex algorithms are far-and-few between - especially in front-end engineering.

Even when algorithms are relevant, there’s usually a team to discuss with, research to be done, and benchmarking to verify the usage of a given algorithm for key application logic. These discussions can take significantly longer than an hour long interview.

Not only are these questions rarely representative of the actual job, they’re also easy to cheat with someone with enough free-time to dedicate towards algorithm memorization. Googling “interview algorithm questions” provides over 17 million results. Even the first page of results promises to teach you how to instantly solve dozens of common algorithm questions.

Not only is possible cheating unhelpful in reflecting a candidate’s problem solving skills, it actively biases your results towards those who’ve put more time into interview prep (which may discourage those who’ve been long-term employees for a single employer). It actively harms those with children or other time constraints that limit their ability to continually practice algorithm questions.

Even with all of this, I’m only scratching the surface of the issues with algorithm-based “whiteboarding” interviews that’ve been written about before.

Fixing the Problem with Tech Recruiting Questions

That said, interview questions are important, so what should we be replacing these algorithm questions with technical assessments?

Ideally, we should be asking questions based in the real-world. For example, if you’ve got an older class-style React codebase that is being rewritten into functional hooks components, let them do that for the interview!

In other scenarios, where styling is important to the role, you might want to provide a functioning app and ask the candidate to match an existing design.

While real-world code samples provide many upsides, setting up a real-world example may take a candidate a little longer to read through the code and orient themselves. How can we reduce the dead-air for interviewers and candidates alike?

Take-Homes

We at CoderPad are strong advocates of take-home interviews for technical assessments. While we’ve written about many of the benefits of take-homes before, we’ll touch on some of the advantages here:

Lower stress environment for candidate
- We’ve heard a lot from the autistic community and those with anxiety that this helps a lot
More flexibility and creativity in candidate solutions
Removes biases
Kills dead air while candidate is doing initial thought process of a problem

Level the Playing Field

As mentioned previously, time isn’t the same for everyone. Some folks look for work while they’re still working full-time for another employer. Those same people may have kids or other priorities in their lives. This makes time a rare commodity for some. Good tech recruiting should take this into account and help level the playing field.

A good solution of this can be setting a time limit for take-home projects. However, if a time-limit is softly set and on the honor system, engineers may feel the pressure to go outside of that time-range to add “polish” in order to compete with other candidates. This places us back at the original problem without much done.

CoderPad allows you to limit the amount of time a candidate is able to spend in assessment. the interview pad Once the timer is done, the candidate is removed from the take-home and their work is submitted.

I encourage you to keep the time limit to 2 hours max. Any longer and you risk alienating the candidates without that much time to do assessments. Keep in mind - you’re likely not the only role that candidate has applied for.

Find Their Speciality

Not only do take-homes improve the balance of “stress” vs “capabilities” you look for in an interview, they also allow candidates with specialties focus on their strengths and show you what they’re most capable of.

Think about it this way: You’re hiring for a team - ideally a team should have a good balance of skills. Even in small-scale applications, there are lots of jobs to do: styling, internal documentation to write, code organization, boilerplate writing, application logic, testing, etc.. While it’s possible to have someone capable of doing more than one of these - it’s impossible to be a true universal expert at all of them at once. Engineers are likely to lean more in some directions than others. Don’t discourage this - it’s what allows a team of diverse people to build a better product through combined individual expertise.

Wrap Up

Most of these tips are meant to make your tech recruiting more representative of real-world experiences and enable a more diverse pool of candidates to succeed in your process. I hope these tips help give you better insights into your candidates and enable a team that’s more well-rounded, ultimately bringing more value to your company and teams.

Hungry for more interviewing tips? Check out our blog about 3 other tips for technical interviewing.

Have more you’d like to add? Join our Slack, where we talk about interviewing and programming. We’re curious what your tips and tricks are!

Master React Unidirectional Data Flow

CoderPad Team — Sat, 22 May 2021 04:06:57 +0000

As with any form of programming, there are dozens of ways to manage data inside a React application. That said, not all methods are equally capable of scaling. There are some "suggested patterns" for your React applications to follow that will ensure you're not forced to pause in order to reorganize or re-evaluate your existing code when you’re building the application.

Today, we'll be covering one of the most important structural best practices to follow when building your React applications: Unidirectional data flow.

What is Unidirectional Data Flow?

Unidirectional data flow is the idea that components should only receiveraise data in one direction. Child components should only call functions from parent components, while parent components should only set/pass data to their children.

In order to explain how both of these look in real code, let's start with how a properly unidirectional parent and child component would be written.

Unidirectional Demo

A great example of a set of components we'll use to demonstrate unidirectionality is a parent "App" component and a child "Form" component.

Let's take a look at a code sample that follows this unidirectionality first:

View the code sample on CoderPad

As you can see we're passing the onChange and value props to SimpleForm. This keeps our state consolidated inside of the App component rather than split between App and SimpleForm. Once you "submit" the form, SimpleForm calls onDone which changes the state stored inside of App. This in turn causes a re-render of SimpleForm.

While SimpleForm is displaying the data to the user, the logic itself stays within App. SimpleForm contains no state or application logic; we call components like these "dumb" components. "Dumb" components are utilized for styling and composability, but not for app logic or state.

This is what a set of proper React components should look like. This pattern of raising state out of the component itself and leaving "dumb" component comes from the guidance of the React team itself. This pattern is called "lifting state up".

Now that we have a better understanding of the patterns to follow let's take a look at the wrong way to do things.

Breaking from Suggested Patterns

Now that we've "lifted" the state, let's drop back down into SimpleForm. We'll start by changing SimpleForm to a class component and adding state.

class SimpleForm extends React.Component {
// State is now a part of the SimpleForm component
  state = {
    input: ""
  }

  onChange(e) {
    this.setState({
      input: e.target.value
    })
  }

  render() {
    return (
      <div>
        <label>
          <div>Username</div>
          <input onChange={this.onChange.bind(this)} value={this.state.input}/>
        </label>
        <button onClick={this.props.onDone}>Submit</button>
      </div>
    )
  }
}

Now, we can use ref in App to access the class methods and state.

export default function App() {
  const simpleRef = React.useRef()
  const [displayTxt, setDisplayTxt] = React.useState("")

  const onDone = () => {
    // Reach into the Ref to access the state of the component instance
    setDisplayTxt(simpleRef.current.state.input)
  }

  return (
    <div>
      <SimpleForm
        onDone={onDone}
        ref={simpleRef}
      />
      <p>{displayTxt}</p>
    </div>
  )
}

View the code sample on CoderPad

This code works, but has some inherent complexity issues. When you start expanding this component, this idea of separating your state and having to inspect the child reference from the parent makes development more difficult. Let's take a look visually how following the application logic is now more difficult with this pattern.

Visualizing the Problem

First, let's start by taking a look at the simpleRef component, where the state is "lowered down" to the SimpleForm component:

In this example, the flow of the application state is as follows:

App (and its children, SimpleForm) render
The user makes changes to the data stored in SimpleForm
The user triggers the onDone action, which triggers a function in App
The App onDone method inspects the data from SimpleForm
Once the data is returned to App, it changes its own data, thus triggering a re-render of App and SimpleForm both

As you can see from the chart above and the outline of the data flow, one action goes back and forth between the parent and child as App attempts to access the data stored in SimpleForm. This is a prime example of a bi-directional component action. This code sample gets even more complex when onDone is expected to change the state in SimpleForm.

Now, let's contrast that to the mental model needed to work with unidirectionality enforced.

App (and its children, SimpleForm) render
The user makes changes in SimpleForm, the state is raised up to App through callbacks
The user triggers the onDone action, which triggers a function in App
The App onDone method already contains all of the data it needs in it's own component, so it simply re-renders App and SimpleForm without any additional logic overhead

As you can see, while the number of steps is similar between these methods (but may not be in a less trivial example), the unidirectional flow is much more streamlined and easier to follow.

This is why the React core team (and the community at large) strongly suggests you use unidirectionality as often as possible.

Conclusion & Challenge

Understanding React unidirectional data flow is integral to scaffolding scalable applications. Unidirectionality doesn't just apply to React, either - Angular and Vue applications often require similar patterns for large scale codebases to be easier to follow and more performant.

Now that we have a deeper understanding of React unidirectional data flow, here's a challenge for you: Refactor the following components to better reflect unidirectionality in this coding pad.

View the code sample on CoderPad

The functionality of the app should be consistent with the previous version. Stuck?

Start with:

Move the getNewActivity into a React.useEffect in App
Move the state.activity into a React.useState in App
Pass all props to DisplayActivities, making it a "dumb" component

Still stuck? Maybe you're excited to share your solution? Send us a Tweet @CoderPad or ask us in our community Slack. We'd be excited to hear from you!

Forem: CoderPad Team

Web Components 101: History

2010: The Early Days of MVC in JS

2011: A Glimmer in W3C Standard’s Eye

2013: Things Start Heating Up

2016 & 2017: Formative Years

2018 and Beyond: Maturity

Timeline

Conclusion

Web Components 101: Framework Comparison

Pros and Cons of Vanilla Web Components

Incremental Rendering

Building Your Own Framework

Pros and Cons of Lit Framework

Other Frameworks

Why Web Components?

Conclusion

Why React 18 Broke Your App

Proof of broken component

What changed in React 18?

How to fix the remounting bug

Conclusion

Web Components 101: Lit Framework

HTML

Event Binding

Attributes & Properties

Attribute Reactivity

Reactive Data Binding

Prop Passing with Lit’s Dot Synax

Array Rendering

Passing Functions

Conclusion

Web Components 101: Vanilla JavaScript

What are Web Components?

What are Custom Elements?

History

Lifecycle Methods

Connection Lifecycles

Attribute Changed

Serializability

Serializing Limitations

Let’s Stringify Some Functions

HTML Attribute Strings

Pass Array of Strings

Pass Array of Objects

Pass Objects with Functions

Pass via Props, not Attributes

Conclusion

GitHub Copilot Breaks Bad Interviews

What is GitHub Copilot?

How does Copilot Threaten Tech Interviews?

Algorithms Are Breaking Your Interviews

How to Fix Your Interviews

Conclusion

Introduction to Web Accessibility (A11Y)

Sensible Standards

Smartly using Semantic HTML Tags

Understand aria- properties

Classy CSS

Contrast is Cool

Fantastic Fonts

Implementation

Keyboard is King

Focus Indicators

Humans Can’t Be Automated

Assistance is Amicable

Test, Test, Test Again

Fantastic Features

Radical Research

Terminology

Tools

Additional Resources

Conclusion

Python List Comprehension – The Comprehensive Guide

What is List Comprehension?

Are List Comprehension Pythonic?

Filtering

Conditionals

Nested Loops

Nested Comprehensions

Understand `aria-` properties