Gatsby RSS feed

Animating Lightning Web Components on first render

Mon, 12 Oct 2020 00:00:00 GMT

With this post I hopefully am going to explain how and why CSS animations behave the way they do with Lightning Web Components. The scope of this project is simple, we want to make an element within a LWC animate it’s width when it is first placed into the DOM. We are not relying on any data being provided via a remote request or a method of this component being called by a parent.

The HTML is really simple;

<template>
  <div class="bar"></div>
</template>

And the CSS we are going to apply;

.bar {
  background: hotpink;
  height: 20px;
  width: 0px;
}
.bar.bar-grow {
  width: 100%;
  transition: width 1s linear;
}

We are going to use the renderedCallback to start our animation after the component is rendered for the first time. Update the HTML template to use a getter for the class property.

<template>
  <div class="{barClass}"></div>
</template>

import { LightningElement } from 'lwc'
export default class Bar extends LightningElement {
  animate = false
  renderedCallback() {
    if (!this._firstRender) {
      this._firstRender = true
      this.animate = true
    }
  }
  get barClass() {
    return `bar ${this.animate ? 'bar-gow' : ''}`
  }
}

But wait, theres a problem. If you run this code what you will see is the bar will be full width and the animation has not run, instead it has immediately been set to the end state of the transition.

A common approach I have seen is to use a timeout to change the animation property, like so;

renderedCallback() {
    if (!this._firstRender) {
        this._firstRender = true;
        setTimeout(() => {
            this.animate = true;
        });
    }
}

Before I attempt to explain what is going on here here is another way to achieve this result without the setTimeout.

renderedCallback() {
    if (!this._firstRender) {
        this._firstRender = true;
        this.animate = true;
        this.template.querySelector('.bar').offsetLeft;
    }
}

So what is going on here?

LWC rerenders using a microtask, changing a reactive property is not immediate, this is why you can change a reactive property multiple times in a piece of code like an event handler but only the last value that was set is what is actually rendered.

So when our component initially is inserted into the DOM and animate is set to false this is done during a microtask. By changing the animate property we are triggering another microtask to be executed to potentially rerender the element.

By enqueing another microtask the event loop has not proceeded therefore the rendering stage has not happened and the UI thread which handles paint etc has not done anything.

Once the second microtask has happened we have updated the DOM again and now the queue is empty therefore the event loop continues and we render the changed DOM. This is why the first example just immediately showed the bar as being 100% width.

Now with the setTimeout example we are enqueing the property change to a task, not a microtask. This means once the microtask queue is empty the render stage will happen and then the next available task will be picked up an executed. We’ve effectively created a delay in changing the property.

And finally the working version without a timeout, what is going on here. Certain properties cause the immediate invalidation and recalculation of layout. This is called layout thrashing and this helps us in our example by ensuring that the layout knows about the element having zero width. So when we apply the transition class it correctly causes the transition to happen.

Layout thrashing generally is something you want to avoid, it is a common cause of application performance problems, especially large single page applications.

As always the most important thing is to understand the concepts so you know when it makes sense to use them and when they will cause you issues.

Mocking the initial state of the Lightning Web Component

Tue, 14 Apr 2020 00:00:00 GMT

Jest is a great tool for testing, there are so many different ways to solve testing problems. I want to talk about a problem I have encountered and go over a solution to it while testing lightning web components.

Now this technique has a specific use case which I want to make clear. It should not be how you test components by default, there are already loads of examples of that specifically in the LWC documentation and LWC recipes.

My simple use case is this; we have a existing component which is a simple form with multiple inputs. We already have tests to ensure our wiring and validation works etc.

So for this example I have initially created a simple component which an obvious issue.

<template>
    <div>
        <input
            name="firstName"
            value={state.firstName}
            placeholder="Enter your first name"
            onchange={handleChange}
        />
        <input
            name="surname"
            value={state.surname}
            placeholder="Enter your surname"
            onchange={handleChange}
        />
        <button
            class={buttonClasses}
            disabled={invalid}
            onclick={handleSave}
        >
            Save
        </button>
    <div>
</template>

import { LightningElement } from 'lwc';
const setState = (state, newState) = ({ ...state, ...newState });
export default class App extends LightningElement {
    state = {
        firstName: '',
        surname: ''
    }
    handleChange(event) {
        this.updateState({
            [event.target.name]: event.target.value
        });
    }
    handleSave(event) {
        if (this.state.firstName === 'A') {
            throw new Error('BOOM');
        }
    }
    updateState(newState) {
        this.state = setState(this.state, newState);
    }
}

We’ve had a bug reported that when the form is filled in with specific values and it is submitted it causes an error.

Normally when you are testing these kind of state interactions you would do something like this in your test.

const input = root.querySelector('input');
input.dispatchEvent(new CustomEvent('change'), { ... });

Now this works fine for a simple component but when you get more complex components you will need to dispatch more of these changes and potentially in specific orders.

In order to effectively test this issue however, we would want to have our components initial state be set to what the reported values are. That way we don’t need find all the inputs and dispatch events for each one. Again my example is simple so this step of dispatching events could be fairly complex.

This is not to say don’t think about appropriate composition of your components but you may be inheriting bad practice etc.

So with that in mind we want a simple way of setting some default state values for our component which could be complex in nature.

The first thing we are going to need to do is to create a module which will provide the default values for our state object and also a means of mocking them to be something else.

export const DEFAULT_STATE = {
    firstName: '',
    surname: '',
};

We’ll make some tweaks to our component to consume it.

import { LightningElement } from 'lwc';
import { DEFAULT_STATE } from './constants';
...
export default class App extends LightningElement {
    state = DEFAULT_STATE;
    ...
}

Now that we have done this we can now write our test using jest.doMock

let createElement;
const createComponent = (config = {}, cmpClass) => {
    const component = createElement('my-app', {
        is: cmpClass
    });
    Object.assign(component, config);
    document.body.appendChild(component);
    return {
        component,
        root: component.shadowRoot
    };
}
describe('my-app', () => {
    afterEach(() => {
        while (document.body.firstChild) {
            document.body.removeChild(document.body.firstChild);
        }
    });
    beforeEach(async () => {
        // we need to ensure module mocks are reset per test
        jest.resetModules();
        // resetting modules means we need to re-import createElement
        let { createElement: create } = await import('lwc');
        createElement = create;
    });
    it('Should not throw and error when firstName is A', () => {
        jest.doMock('../constants.js', () => {
            const originalModule = jest.requireActual('../constants.js');
            return {
                ...originalModule,
                DEFAULT_STATE: {
                    ...originalModule.DEFAULT_STATE,
                    firstName: 'A'
                }
            };
        });
        const MyApp = await import('my/app');
        const { root } = createComponent({}, MyApp.default);
        expect(root.querySelector('input').value).toEqual('A');
        // Now we can test our failing logic when we call `handleSave`
    });
});

I have created a much more comprehensive repo with further test examples showing how you would blend these technique with a standard way of testing your component. You could also always have separate test files for these so that you do not need to modify all you existing tests too.

Running Siesta tests from Atom or Sublime

Sat, 20 Dec 2014 00:00:00 GMT

This post is not about how to use Siesta for unit testing, more a quick guide on how to get setup using PhatomJS to run your tests from Atom or Sublime.

The main benefit to using this over the standard web ui is speed. From a keyboard shortcut you can have your test pass or fail within a second.

Atom

My current IDE of choice so i’ll go over the setup for this one first.

Firstly install this package which allows you to build your current project directly from atom.

Once you have done that all you no need to do is create a .atom-build.json file which tells the package how to build your project.

Example .atom-build.json file.

{
  "cmd": "PATH_TO_SIESTA/bin/phantomjs",
  "args": [ "LOCALHOST/test.html", "--filter {FILE_ACTIVE_NAME}"],
  "sh": true
}

By using —filter we are telling PhantomJS to only run the test we are looking at within our IDE.

Sublime

Luckily Sublime supports build systems out of the box so no packages are needed to be installed.

To create a new build system go tools > build systems > new build system.

Example siesta.sublime-build.

{
  "cmd" : ["PATH_TO_SIESTA/bin/phantomjs LOCALHOST/test.html --filter $file_name"],
  "shell": true
}

Now you just need to ensure you are using this build system for your project and you can now run a single test just like in Atom.