Tag: Managing


Deprecated: Function create_function() is deprecated in /home2/thebrand/public_html/wp-content/plugins/wp-spamshield/wp-spamshield.php on line 1884
03 Jun

Managing Shared State In Vue 3

by TBSCategories: News

State can be hard. When we start a simple Vue project, it can be simple to just keep our working state on a particular component:

setup() {   let books: Work[] = reactive([]);    onMounted(async () => {     // Call the API     const response = await bookService.getScienceBooks();     if (response.status === 200) {       books.splice(0, books.length, ...response.data.works);     }   });    return {     books   }; },

When your project is a single page of showing data (perhaps to sort or filter it), this can be compelling. But in this case, this component will get data on every request. What if you want to keep it around? That’s where state management comes into play. As network connections are often expensive and occasionally unreliable, it would be better to keep this state around as you navigate through an application.

Another issue is communicating between components. While you can use events and props to communicate with direct children-parents, handling simple situations like error handling and busy flags can be difficult when each of your views/pages are independent. For example, imagine that you had a top-level control was wired up to show error and loading animation:

// App.vue <template>   <div class="container mx-auto bg-gray-100 p-1">     <router-link to="/"><h1>Bookcase</h1></router-link>     <div class="alert" v-if="error">{{ error }}</div>     <div class="alert bg-gray-200 text-gray-900" v-if="isBusy">       Loading...     </div>     <router-view :key="$  route.fullPath"></router-view>   </div> </template>

Without an effective way to handle this state, it might suggest a publish/subscribe system, but in fact sharing data is more straightforward in many cases. If want to have shared state, how do you go about it? Let’s look at some common ways to do this.

Note: You’ll find the code for this section in the “main” branch of the example project on GitHub.

Shared State In Vue 3

Since moving to Vue 3, I’ve migrated completely to using the Composition API. For the article, I’m also using TypeScript though that’s not required for examples I’m showing you. While you can share state any way you want, I’m going to show you several techniques that I find the most commonly used patterns. Each has it’s own pros and cons, so don’t take anything I talk about here as dogma.

The techniques include:

Note: Vuex 5, as of the writing of this article, it’s in the RFC (Request for Comments) stage so I want to get you ready for where Vuex is going, but right now there is not a working version of this option.

Let’s dig in…

Factories

Note: The code for this section is in the “Factories” branch of the example project on GitHub.

The factory pattern is just about creating an instance of the state you care about. In this pattern, you return a function that is much like the start function in the Composition API. You’d create a scope and build the components of what you’re looking for. For example:

export default function () {    const books: Work[] = reactive([]);    async function loadBooks(val: string) {       const response = await bookService.getBooks(val, currentPage.value);       if (response.status === 200) {         books.splice(0, books.length, ...response.data.works);       }   }    return {     loadBooks,     books   }; }

You could ask for just the parts of the factory created objects you need like so:

// In Home.vue   const { books, loadBooks } = BookFactory();

If we add an isBusy flag to show when the network request happens, the above code doesn’t change, but you could decide where you are going to show the isBusy:

export default function () {    const books: Work[] = reactive([]);   const isBusy = ref(false);    async function loadBooks(val: string) {     isBusy.value = true;     const response = await bookService.getBooks(val, currentPage.value);     if (response.status === 200) {       books.splice(0, books.length, ...response.data.works);     }   }    return {     loadBooks,     books,     isBusy   }; }

In another view (vue?) you could just ask for the isBusy flag without having to know about how the rest of the factory works:

// App.vue export default defineComponent({   setup() {     const { isBusy } = BookFactory();     return {       isBusy     }   }, })

But you may have noticed an issue; every time we call the factory, we’re getting a new instance of all the objects. There are times when you want to have a factory return new instances, but in our case we’re talking about sharing the state, so we need to move the creation outside the factory:

const books: Work[] = reactive([]); const isBusy = ref(false);  async function loadBooks(val: string) {   isBusy.value = true;   const response = await bookService.getBooks(val, currentPage.value);   if (response.status === 200) {     books.splice(0, books.length, ...response.data.works);   } }  export default function () {  return {     loadBooks,     books,     isBusy   }; }

Now the factory is giving us a shared instance, or a singleton if you prefer. While this pattern works, it can be confusing to return a function that doesn’t create a new instance every time.

Because the underlying objects are marked as const you shouldn’t be able to replace them (and break the singleton nature). So this code should complain:

// In Home.vue   const { books, loadBooks } = BookFactory();    books = []; // Error, books is defined as const

So it can be important to make sure mutable state can be updated (e.g. using books.splice() instead of assigning the books).

Another way to handle this is to use shared instances.

Shared Instances

The code for this section is in the “SharedState” branch of the example project on GitHub.

If you’re going to be sharing state, might as well be clear about the fact that the state is a singleton. In this case, it can just be imported as a static object. For example, I like to create an object that can be imported as a reactive object:

export default reactive({    books: new Array<Work>(),   isBusy: false,    async loadBooks() {     this.isBusy = true;     const response = await bookService.getBooks(this.currentTopic, this.currentPage);     if (response.status === 200) {       this.books.splice(0, this.books.length, ...response.data.works);     }     this.isBusy = false;   } });

In this case, you just import the object (which I’m calling a store in this example):

// Home.vue import state from "@/state";  export default defineComponent({   setup() {      // ...      onMounted(async () => {       if (state.books.length === 0) state.loadBooks();     });      return {       state,       bookTopics,     };   }, });

Then it becomes easy to bind to the state:

<!-- Home.vue --> <div class="grid grid-cols-4">   <div     v-for="book in state.books"     :key="book.key"     class="border bg-white border-grey-500 m-1 p-1"   >   <router-link :to="{ name: 'book', params: { id: book.key } }">     <BookInfo :book="book" />   </router-link> </div>

Like the other patterns, you get the benefit that you can share this instance between views:

// App.vue import state from "@/state";  export default defineComponent({   setup() {     return {       state     };   }, })

Then this can bind to what is the same object (whether it is a parent of the Home.vue or another page in the router):

<!-- App.vue -->   <div class="container mx-auto bg-gray-100 p-1">     <router-link to="/"><h1>Bookcase</h1></router-link>     <div class="alert bg-gray-200 text-gray-900"             v-if="state.isBusy">Loading...</div>     <router-view :key="$  route.fullPath"></router-view>   </div>

Whether you use the factory pattern or the shared instance, they both have a common issue: mutable state. You can have accidental side effects of bindings or code changing state when you don’t want them to. In a trivial example like I’m using here, it isn’t complex enough to worry about. But as you’re building larger and larger apps, you will want to think about state mutation more carefully. That’s where Vuex can come to the rescue.

Vuex 4

The code for this section is in the “Vuex4” branch of the example project on GitHub.

Vuex is state manager for Vue. It was built by the core team though it is managed as a separate project. The purpose of Vuex is to separate the state from the actions you want to do to the state. All changes of state has to go through Vuex which means it is more complex, but you get protection from accidental state change.

The idea of Vuex is to provide a predictable flow of state management. Views flow to Actions which, in turn, use Mutations to change State which, in turn, updates the View. By limiting the flow of state change, you should have fewer side effects that change the state of your applications; therefore be easier to build larger applications. Vuex has a learning curve, but with that complexity you get predictability.

Additionally, Vuex does support development-time tools (via the Vue Tools) to work with the state management including a feature called time-travel. This allows you to view a history of the state and move back and forward to see how it affects the application.

There are times, too, when Vuex is important too.

To add it to your Vue 3 project, you can either add the package to the project:

> npm i vuex

Or, alternatively you can add it by using the Vue CLI:

> vue add vuex

By using the CLI, it will create a starting point for your Vuex store, otherwise you’ll need to wire it up manually to the project. Let’s walk through how this works.

First, you’ll need a state object that is created with Vuex’s createStore function:

import { createStore } from 'vuex'  export default createStore({   state: {},   mutations: {},   actions: {},   getters: {} });

As you can see, the store requires several properties to be defined. State is just a list of the data you want to give your application access to:

import { createStore } from 'vuex'  export default createStore({   state: {     books: [],     isBusy: false   },   mutations: {},   actions: {} });

Note that the state shouldn’t use ref or reactive wrappers. This data is the same kind of share data that we used with Shared Instances or Factories. This store will be a singleton in your application, therefore the data in state is also going to be shared.

Next, let’s look at actions. Actions are operations that you want to enable that involve the state. For example:

  actions: {     async loadBooks(store) {       const response = await bookService.getBooks(store.state.currentTopic,       if (response.status === 200) {         // ...       }     }   },

Actions are passed an instance of the store so that you can get at the state and other operations. Normally, we’d destructure just the parts we need:

  actions: {     async loadBooks({ state }) {       const response = await bookService.getBooks(state.currentTopic,       if (response.status === 200) {         // ...       }     }   },

The last piece of this are Mutations. Mutations are functions that can mutate state. Only mutations can affect state. So, for this example, we need mutations that change change the state:

  mutations: {     setBusy: (state) => state.isBusy = true,     clearBusy: (state) => state.isBusy = false,     setBooks(state, books) {       state.books.splice(0, state.books.length, ...books);     }  },

Mutation functions always pass in the state object so that you can mutate that state. In the first two examples, you can see that we’re explicitly setting the state. But in the third example, we’re passing in the state to set. Mutations always take two parameters: state and the argument when calling the mutation.

To call a mutation, you’d use the commit function on the store. In our case, I’ll just add it to the destructuring:

  actions: {     async loadBooks({ state, commit }) {       commit("setBusy");       const response = await bookService.getBooks(state.currentTopic,        if (response.status === 200) {         commit("setBooks", response.data);       }       commit("clearBusy");     }   },

What you’ll see here is how commit requires the name of the action. There are tricks to make this not just use magic strings, but I’m going to skip that for now. This use of magic strings is one of the limitations of using Vuex.

While using commit may seem like an unnecessary wrapper, remember that Vuex is not going to let you mutate state except inside the mutation, therefore only calls through commit will.

You can also see that the call to setBooks takes a second argument. This is the second argument that is calling the mutation. If you were to need more information, you’d need to pack it into a single argument (another limitation of Vuex currently). Assuming you needed to insert a book into the books list, you could call it like this:

commit("insertBook", { book, place: 4 }); // object, tuple, etc.

Then you could just destructure into the pieces you need:

mutations: {   insertBook(state, { book, place }) => // ...     }

Is this elegant? Not really, but it works.

Now that we have our action working with mutations, we need to be able to use the Vuex store in our code. There are really two ways to get at the store. First, by registering the store with application (e.g. main.ts/js), you’ll have access to a centralized store that you have access to everywhere in your application:

// main.ts import store from './store'  createApp(App)   .use(store)   .use(router)   .mount('#app')

Note that this isn’t adding Vuex, but your actual store that you’re creating. Once this is added, you can just call useStore to get the store object:

import { useStore } from "vuex";  export default defineComponent({   components: {     BookInfo,   },   setup() {     const store = useStore();     const books = computed(() => store.state.books);     // ...

This works fine, but I prefer to just import the store directly:

import store from "@/store";  export default defineComponent({   components: {     BookInfo,   },   setup() {     const books = computed(() => store.state.books);     // ...

Now that you have access to the store object, how do you use it? For state, you’ll need to wrap them with computed functions so that changes will be propagated to your bindings:

export default defineComponent({   setup() {      const books = computed(() => store.state.books);      return {       books     };   }, });

To call actions, you will need to call the dispatch method:

export default defineComponent({   setup() {      const books = computed(() => store.state.books);      onMounted(async () => await store.dispatch("loadBooks"));      return {       books     };   }, });

Actions can have parameters that you add after the name of the method. Lastly, to change state, you’ll need to call commit just like we did inside the Actions. For example, I have a paging property in the store, and then I can change the state with commit:

const incrementPage = () =>   store.commit("setPage", store.state.currentPage + 1); const decrementPage = () =>   store.commit("setPage", store.state.currentPage - 1);

Note, that calling it like this would throw an error (because you can’t change state manually):

const incrementPage = () => store.state.currentPage++;   const decrementPage = () => store.state.currentPage--;

This is the real power here, we’d want control where state is changed and not have side effects that produce errors further down the line in development.

You may be overwhelmed with number of moving pieces in Vuex, but it can really help manage state in larger, more complex projects. I would not say you need it in every case, but there will be large projects where it helps you overall.

The big problem with Vuex 4 is that working with it in a TypeScript project leaves a lot to be desired. You can certainly make TypeScript types to help development and builds, but it requires a lot of moving pieces.

That’s where Vuex 5 is meant to simplify how Vuex works in TypeScript (and in JavaScript projects in general). Let’s see how that will work once it’s released next.

Vuex 5

Note: The code for this section is in the “Vuex5” branch of the example project on GitHub.

At the time of this article, Vuex 5 isn’t real. It’s a RFC (Request for Comments). It’s a plan. It’s a starting point for discussion. So a lot of what I may explain here likely will change somewhat. But to prepare you for the change in Vuex, I wanted to give you a view of where it’s going. Because of this the code associated with this example doesn’t build.

The basic concepts of how Vuex works have been somewhat unchanged since it’s inception. With the introduction of Vue 3, Vuex 4 was created to mostly allow Vuex to work in new projects. But the team is trying to look at the real pain-points with Vuex and solve them. To this end they are planning some important changes:

  • No more mutations: actions can mutate state (and possibly anyone).
  • Better TypeScript support.
  • Better multi-store functionality.

So how would this work? Let’s start with creating the store:

export default createStore({   key: 'bookStore',   state: () => ({     isBusy: false,     books: new Array<Work>()   }),   actions: {     async loadBooks() {       try {         this.isBusy = true;         const response = await bookService.getBooks();         if (response.status === 200) {           this.books = response.data.works;         }       } finally {         this.isBusy = false;       }     }   },   getters: {     findBook(key: string): Work | undefined {       return this.books.find(b => b.key === key);     }   } });

First change to see is that every store now needs it own key. This is to allow you to retrieve multiple stores. Next you’ll notice that the state object is now a factory (e.g. returns from a function, not created on parsing). And there is no mutations section any more. Lastly, inside the actions, you can see we’re accessing state as just properties on the this pointer. No more having to pass in state and commit to actions. This helps not only in simplifying development, but also makes it easier to infer types for TypeScript.

To register Vuex into your application, you’ll register Vuex instead of your global store:

import { createVuex } from 'vuex'  createApp(App)   .use(createVuex())   .use(router)   .mount('#app')

Finally, to use the store, you’ll import the store then create an instance of it:

import bookStore from "@/store";  export default defineComponent({   components: {     BookInfo,   },   setup() {     const store = bookStore(); // Generate the wrapper     // ...

Notice that what is returned from the store is a factory object that returns thsi instance of the store, no matter how many times you call the factory. The returned object is just an object with the actions, state and getters as first class citizens (with type information):

onMounted(async () => await store.loadBooks());  const incrementPage = () => store.currentPage++; const decrementPage = () => store.currentPage--;

What you’ll see here is that state (e.g. currentPage) are just simple properties. And actions (e.g. loadBooks) are just functions. The fact that you’re using a store here is a side effect. You can treat the Vuex object as just an object and go about your work. This is a significant improvement in the API.

Another change that’s important to point out is that you could also generate your store using a Composition API-like syntax:

export default defineStore("another", () => {    // State   const isBusy = ref(false);   const books = reactive(new Array≷Work>());    // Actions   async function loadBooks() {     try {       this.isBusy = true;       const response = await bookService.getBooks(this.currentTopic, this.currentPage);       if (response.status === 200) {         this.books = response.data.works;       }     } finally {       this.isBusy = false;     }   }    findBook(key: string): Work | undefined {     return this.books.find(b => b.key === key);   }    // Getters   const bookCount = computed(() => this.books.length);    return {     isBusy,     books,     loadBooks,     findBook,     bookCount   } });

This allows you to build your Vuex object just like you would your views with the Composition API and arguably it’s simpler.

One main drawback in this new design is that you lose the non-mutability of the state. There are discussions happening around being able to enable this (for development only, just like Vuex 4) but there isn’t consensus how important this is. I personally think it’s a key benefit for Vuex, but we’ll have to see how this plays out.

Where Are We?

Managing shared state in single page applications is a crucial part of development for most apps. Having a game plan on how you want to go about it in Vue is an important step in designing your solution. In this article, I’ve shown you several patterns for managing shared state including what’s coming for Vuex 5. Hopefully you’ll now have the knowledge to make the right decision for you own projects.

Articles on Smashing Magazine — For Web Designers And Developers

08 Feb

Managing CSS Z-Index In Large Projects

by TBSCategories: News

There are several articles that explain z-index (here’s a good one), since it continues to trip up developers of all experience levels. I do not think that the number of articles is a sign that none of them do a good job at explaining it, but that there are a lot of developers out there and just because one developer read and understood the article doesn’t necessarily mean that everyone on their team read and understands it now. While taking the time to better understand how z-index (or any piece of technology) works will definitely set you up to work with it better, we can also take another approach: make it easier to work with z-index.

We use abstractions and conventions to hide away the tricky and error-prone parts, which in turn makes it easier for everyone who needs to do the same task. I had the opportunity to attempt to make z-index easier to work with for my team while working on a redesign of our company’s website. The system I designed allowed my team to implement the entire UI while never having to question what a certain z-index value was used for, what number to use when adding a new z-index declaration, or how to fix stacking bugs that crept into the system.

Common Solution

The most common system I’ve seen for managing z-index values — other than no system — is setting several general-use values, each separated by an arbitrary number. This solution definitely tames z-index issues, but as I’ve worked on teams that use this system there still seems to be confusion about how to use it properly. Here is an example from the Bootstrap documentation.

$  zindex-dropdown:       1000; $  zindex-sticky:         1020; $  zindex-fixed:          1030; $  zindex-modal-backdrop: 1040; $  zindex-modal:          1050; $  zindex-popover:        1060; $  zindex-tooltip:        1070;

Bootstrap defines z-index values in Sass variables like $ zindex-dropdown, $ zindex-sticky, and $ zindex-fixed. Those names seem pretty straight forward, but when a developer goes to choose a value for a feature they’re working on, there could be confusion as to which value is most appropriate for their use. They end up asking, “Is what I’m implementing a ‘dropdown’ or a ‘popover’?” which can easily be debated and may not have a clear answer.

A second issue I see with this solution is that the actual values for the variables might seem confusing or lead to insecurity. This solution leaves space in between each value to give developers space to add their own values in between if necessary. Bootstrap defines seven values separated by increments of 10, starting at 1000 and ending at 1070.

Many questions could come to mind when reading this:

“Why start at 1000?

“Is there anything less than 1000?”

“Where is 1010? Is it a bug? Is something else using it?”

“Why was 10 chosen? What if I need more than 9 values to go in between?”

Though I’ve never actually needed these “what if” questions answered, they can add insecurity and confusion to a system that already seems magical and misunderstood. Can we remove all of these concerns, allowing the developer to easily and accurately choose the z-index value they need?

A New Solution

Since working on a redesign gave my team a fresh start, this was one common issue we wanted to see if we could avoid. To align with our general coding standards, my goals for managing z-index was to avoid magic numbers and to make it easier for every team member to confidently contribute. The second goal of making it easier for others is vague, so I focused on trying to solve these common issues:

  • People often choose arbitrarily large z-index values;
  • z-index bug fixes often result in a new z-index bug;
  • The relationship between z-index values is difficult to trace.

Let’s look at solutions for each of these issues that I was able to apply, leaning on conventions and using existing technologies.

Giving Z-Index Values Semantics

One reason people often choose arbitrarily large z-index values is because they don’t know the z-index value of the item above which they are trying to place a new item. Once they find an arbitrarily high value that works, they leave it instead of finding an optimal value. Later on, when someone finds this value they have no idea why it is what it is, and even the original author may have forgotten.

z-index: 9999;

The solution for fixing “magic numbers” like this is by using a named constant instead. While naming the value alone does not give us much more value than the class name does, when we put our z-index constants together, their relationship starts to become explicit.

To remove the magic numbers, I first started defining all of our z-index values in a JavaScript file. I used a JavaScript file since our application was using a CSS-in-JS solution, though this and the ideas in this article can be implemented with styling preprocessors like Sass variables as well as in CSS using custom properties.

export const backdrop = 0; export const openButton = 1; export const dropdown = 2;

With z-index constants, the CSS value has little more meaning, and the actual value is obscured away.

css`   z-index: $  {backdrop}; `;

This also makes the original value easy to find, revealing the related constants, but there is a further improvement that can be made. We know by how z-index works that these values are related to each other, so we can change our constants to make that more apparent.

export const backdrop = 0; export const openButton = backdrop + 1; export const dropdown = openButton + 1;

Using simple arithmetic, we can use the previous constants to make the next constant. Taking this idea one step further to further eliminate ambiguity, I added some utility constants to make these definitions read more like a sentence.

const base = 0; const above = 1;  export const backdrop = base; export const openButton = above + backdrop; export const dropdown = above + openButton;

Now when someone sees a line like z-index: $ {dropdown}; they can look find the dropdown’s definition and read, “The dropdown is above the open button.”

This makes future maintenance of the constants easier. Whenever you have a new value to add, you can be confident that you are adding it to the right place.

export const backdrop = base; export const openButton = above + backdrop; export const dropdown = above + openButton; export const closeButton = above + dropdown; // new

Deleting values is easy too, but you need to remember to update any other values that are dependent on it. Using JavaScript, the linter highlighted this for me.

Stacking bug tickets often show up that say something like, “the dropdown is overlapping with the button when it should be underneath.” When coming across these, the fix is as simple as swapping the relationship pointers in the definitions.

export const backdrop = base; export const dropdown = above + backdrop; export const openButton = above + dropdown; export const closeButton = above + dropdown; // ???

Now that we’ve swapped the z-index order, we notice another potential bug before we even check the browser. The close button might now conflict with the open button. You can now have the necessary conversations to resolve bugs before anyone sees a problem in production.

One extra piece I found to be helpful in rare situations was a utility for placing items below others. To avoid mixing above and below, I made the rule that below should only be used for negative values.

const base = 0; const above = 1; const below = -1;  export const backdrop = below + dropdown; export const dropdown = below + button; export const button = base;

In this system, every z-index value is only as high as it needs to be, and since it’s dynamically chosen, you aren’t concerned with what the value actually is.

You can also delete and add values knowing with confidence how it will affect the other stacked elements.

Once our application ended up with a dozen or so z-index constants, though it started to become a little bit confusing having a long flat list.

Organizing By Stacking Context

When thinking about stacking context and how the values of each stacking context are independent of others, it sounded like other front-end solutions for effective scoping. I drew similarities to other JavaScript modules, components, atomic design, and BEM. They are all trying to solve similar problems of how we can independently scope concerns, keeping them from affecting other areas.

Taking inspiration from BEM, I made a naming convention for our constants to better organize the values and bring more order to the flat list of constants. The format I ended up using had a template like this: z<Context><Element>.

The z portion is a prefix denoting the fact that the value is meant to be used in z-index declarations, considering we had other constants defined in our JavaScript files like color variables.

The<Context> portion is replaced with the name stacking context the constant belongs to. This is similar to the “block” in BEM and in practice almost always shares the same name as the component being styled. The main exception is the root HTML stacking context that is used for page region stacking.

The final portion of the format, <Element> is for the name of the specific item to be positioned in the stacking context and is most similar to “element” in BEM.

Here is a full example of what this naming convention could look like when added to what we’ve talked about previously. For an interactive version, you can play around with the same example in a CodePen:

See the Pen Managing CSS Z-Index in Large Projects Demo by Steven Frieson.

For other language versions, check out this repository.

// Utils const base = 0; const above = 1; // use this for all values above the base const below = -1; // and this for all values below the base  // Page Layout export const zLayoutNavigation = above + base; export const zLayoutFooter = above + base; export const zLayoutModal = above + zLayoutNavigation; export const zLayoutPopUpAd = above + zLayoutModal;  // NavMenu export const zNavMenuBackdrop = below + base; export const zNavMenuPopover = above + base; export const zNavMenuToggle = above + zNavMenuPopover;

Now that our constants are organized by their stacking context, we can quickly see which values are related and where a new value or fix should go.

Taking It Further

That is essentially the specification of how this should work. Considering this solution was only designed with one application in mind, there are some further steps that could be taken to make it more mature and support more use cases. Some of these ideas are more specific to the language it’s being implemented in but most ideas carry over.

One area that could possibly be improved around what is being shipped to the browser. When I implemented this, the framework we were using did not give us much control over the build tools, so the JavaScript file of all the definitions was bundled with the application. This did not have a measurable performance impact on our application, but you may have noticed that all of the values could be computed at compile time. An implementation using Sass would end up not shipping any of the Sass variables to the client, but instead, insert the derived z-index value in the CSS. For JS and CSS solutions, build tools like Webpack and PostCSS, respectively, could help do the same.

The way the solution evolved as I worked on it, the z-index constants ended up all in one file. This ended up being a great way to see all of the z-index values across the application at once, making it easier to quickly glance for any possible stacking conflicts. They were also filed away with other styling constants like colors and typography, so it made sense to originally have them all defined together. As the file grew though, it started to be internally organized by stacking context as explained above. Since the stacking contexts often mapped to a component, it started feeling like each set of constants could be collocated with their component. This would bring all the normal benefits of collocation, being closer to the files they’re used in, causing less friction when needing to add, edit, and remove constants. We never refactored it, but that seems like a viable option to explore.

One additional piece has to do with ergonomics and developer experience. The constants are all exported as a flat list at the moment. The naming convention took inspiration from BEM, but Sass and JavaScript allow us to use other ways to organize our data. Sass maps or JavaScript Objects or Maps could have been used to organize the values hierarchically. If we had all the values in a z object, it could have led to shorter import statements. We could have gone further to have an object per stacking context as well leading to a usage style more like z.layout.navigation. Different tools like TypeScript could guard against making typos here, though this might be more effort than it’s worth.

Our Results

The system as spelled out was successfully implemented and deployed to our production applications. Checking back in on the objectives, we definitely got rid of the magic numbers. As far as developer ease and confidence goes, my team was able to easily add new z-index values and fix pre- and post-launch bugs without fear that the changes would introduce new bugs. On multiple occasions, we fixed bugs before they were filed.

We also were able to avoid the issue of coming across a random z-index: 9999;. Though the application had sticky headers, floating action buttons, dropdowns, modals, pop up ads, and more in the stacking context, the highest value we had was 5. Even then, no one knew it since the values were all abstracted away from us in variables.

Solving developer experience issues resulted in a z-index mini-framework, helping people make the correct decision with less effort and move more quickly.

Something else we noticed was that sometimes we were assigning a z-index when we did not necessarily need one. Since stacking contexts can be created by several different properties, declarations like position: sticky; can act in a similar manner as setting z-index: 1;. In those cases, we continued to add a constant and declaration anyway. Keeping them allowed for better consistency in the system instead of allowing there to be special cases, which would degrade confidence about whether everything was working correctly or not. Keeping the constant list complete aided in understanding the system and set us up better for rearranging the values when necessary.

What It Doesn’t Solve

Like any framework, there are parts that it doesn’t not do a good job at solving for you. Naming things is still hard, and this framework slightly exacerbates the problem by requiring that you name all of your z-index values. Even still, we found that the gained clarity overcame the chore of having to name them all.

This system also does not necessarily help you figure out which stacking context a bug is in. Coming across a z-index bug where you don’t know where the new stacking context is created or where the z-index value is set is not solved by this framework, but once you have found the issue, the path to making the correct fix is clear.

Using It In Your App

The ideas shared here should be actionable in most applications depending on your styling solution and browser support. Migrating to use this system is not very risky since stacking contexts are already scoped individually; you can migrate one context as it already exists at a time. Changing to use these conventions forces you to describe more clearly what you already have in your app, shining a light on what might currently seem like a dark, scary corner.

If your z-index values are in a state where you are unsure about most or all of them, then the best way to convert to this system will probably be to start by creating a constant for each value in a single list in a single file. As the stacking contexts become more clear, you can start grouping them and renaming them (if necessary) to conform to the naming convention.

My team was not working with any external CSS libraries or frameworks that included z-index values, but that could possibly add some difficulty to adopting this system. Hopefully, the utilities are configurable enough to deal with most uses and to even incorporate the third-party values into the system.

Finally, all of the examples here have been written as a single file of z-index values, but you could collocate these values with the component to make an even stronger connection between the two. Using a file naming convention will make it easier to find all of the values throughout the application.

Try It Out Yourself

If you are having trouble wrangling z-index values on your site and end up trying out these suggestions, I would love to hear about your experience. This mini-framework was developed over just a few months and has only been used in one production codebase, so there are certainly unexplored use cases and opinions that could be added or tweaked.

Articles on Smashing Magazine — For Web Designers And Developers

02 Dec

Managing Long-Running Tasks In A React App With Web Workers

by TBSCategories: News

Response time is a big deal when it comes to web applications. Users demand instantaneous responses, no matter what your app may be doing. Whether it’s only displaying a person’s name or crunching numbers, web app users demand that your app responds to their command every single time. Sometimes that can be hard to achieve given the single-threaded nature of JavaScript. But in this article, we’ll learn how we can leverage the Web Worker API to deliver a better experience.

In writing this article, I made the following assumptions:

  1. To be able to follow along, you should have at least some familiarity with JavaScript and the document API;
  2. You should also have a working knowledge of React so that you can successfully start a new React project using Create React App.

If you need more insights into this topic, I’ve included a number of links in the “Further Resources” section to help you get up to speed.

First, let’s get started with Web Workers.

What Is A Web Worker?

To understand Web Workers and the problem they’re meant to solve, it is necessary to get a grasp of how JavaScript code is executed at runtime. During runtime, JavaScript code is executed sequentially and in a turn-by-turn manner. Once a piece of code ends, then the next one in line starts running, and so on. In technical terms, we say that JavaScript is single-threaded. This behavior implies that once some piece of code starts running, every code that comes after must wait for that code to finish execution. Thus, every line of code “blocks” the execution of everything else that comes after it. It is therefore desirable that every piece of code finish as quickly as possible. If some piece of code takes too long to finish our program would appear to have stopped working. On the browser, this manifests as a frozen, unresponsive page. In some extreme cases, the tab will freeze altogether.

Imagine driving on a single-lane. If any of the drivers ahead of you happen to stop moving for any reason, then, you have a traffic jam. With a program like Java, traffic could continue on other lanes. Thus Java is said to be multi-threaded. Web Workers are an attempt to bring multi-threaded behavior to JavaScript.

The screenshot below shows that the Web Worker API is supported by many browsers, so you should feel confident in using it.

Web Workers run in background threads without interfering with the UI, and they communicate with the code that created them by way of event handlers.

An excellent definition of a Web Worker comes from MDN:

“A worker is an object created using a constructor (e.g. Worker() that runs a named JavaScript file — this file contains the code that will run in the worker thread; workers run in another global context that is different from the current window. Thus, using the window shortcut to get the current global scope (instead of self within a Worker will return an error.”

A worker is created using the Worker constructor.

const worker = new Worker('worker-file.js')

It is possible to run most code inside a web worker, with some exceptions. For example, you can’t manipulate the DOM from inside a worker. There is no access to the document API.

Workers and the thread that spawns them send messages to each other using the postMessage() method. Similarly, they respond to messages using the onmessage event handler. It’s important to get this difference. Sending messages is achieved using a method; receiving a message back requires an event handler. The message being received is contained in the data attribute of the event. We will see an example of this in the next section. But let me quickly mention that the sort of worker we’ve been discussing is called a “dedicated worker”. This means that the worker is only accessible to the script that called it. It is also possible to have a worker that is accessible from multiple scripts. These are called shared workers and are created using the SharedWorker constructor, as shown below.

const sWorker = new SharedWorker('shared-worker-file.js')

To learn more about Workers, please see this MDN article. The purpose of this article is to get you started with using Web workers. Let’s get to it by computing the nth Fibonacci number.

Computing The Nth Fibonacci Number

Note: For this and the next two sections, I’m using Live Server on VSCode to run the app. You can certainly use something else.

This is the section you’ve been waiting for. We’ll finally write some code to see Web Workers in action. Well, not so fast. We wouldn’t appreciate the job a Web Worker does unless we run into the sort of problems it solves. In this section, we’re going to see an example problem, and in the following section, we’ll see how a web worker helps us do better.

Imagine you were building a web app that allowed users to calculate the nth Fibonacci number. In case you’re new to the term ‘Fibonacci number’, you can read more about it here, but in summary, Fibonacci numbers are a sequence of numbers such that each number is the sum of the two preceding numbers.

Mathematically, it is expressed as:

Thus the first few numbers of the sequence are:

1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89 ...

In some sources, the sequence starts at F0 = 0, in which case the formula below holds for n > 1:

In this article we’ll start at F1 = 1. One thing we can see right away from the formula is that the numbers follow a recursive pattern. The task at hand now is to write a recursive function to compute the nth Fibonacci number (FN).

After a few tries, I believe you can easily come up with the function below.

const fib = n => {   if (n < 2) {     return n // or 1   } else {     return fib(n - 1) + fib(n - 2)   } }

The function is simple. If n is less than 2, return n (or 1), otherwise, return the sum of the n-1 and n-2 FNs. With arrow functions and ternary operator, we can come up with a one-liner. 

const fib = n => (n < 2 ? n : fib(n-1) + fib(n-2))

This function has a time complexity of 0(2n). This simply means that as the value of n increases, the time required to compute the sum increases exponentially. This makes for a really long-running task that could potentially interfere with our UI, for large values of n. Let’s see this in action.

Note: This is by no means the best way to solve this particular problem. My choice of using this method is for the purpose of this article.

To start, create a new folder and name it whatever you like. Now inside that folder create a src/ folder. Also, create an index.html file in the root folder. Inside the src/ folder, create a file named index.js.

Open up index.html and add the following HTML code.

<!DOCTYPE html> <html> <head>   <link rel="stylesheet" href="styles.css"> </head> <body>   <div class="heading-container">     <h1>Computing the nth Fibonnaci number</h1>   </div>   <div class="body-container">     <p id='error' class="error"></p>     <div class="input-div">       <input id='number-input' class="number-input" type='number' placeholder="Enter a number" />       <button id='submit-btn' class="btn-submit">Calculate</button>     </div>     <div id='results-container' class="results"></div>   </div>   <script src="/src/index.js"></script> </body> </html>

This part is very simple. First, we have a heading. Then we have a container with an input and a button. A user would enter a number then click on “Calculate”. We also have a container to hold the result of the calculation. Lastly, we include the src/index.js file in a script tag.

You may delete the stylesheet link. But if you’re short on time, I have defined some CSS which you can use. Just create the styles.css file at the root folder and add the styles below:

 body {     margin: 0;     padding: 0;     box-sizing: border-box;   }    .body-container,   .heading-container {     padding: 0 20px;   }    .heading-container {     padding: 20px;     color: white;     background: #7a84dd;   }    .heading-container > h1 {     margin: 0;   }    .body-container {     width: 50%   }    .input-div {     margin-top: 15px;     margin-bottom: 15px;     display: flex;     align-items: center;   }    .results {     width: 50vw;   }    .results>p {     font-size: 24px;   }    .result-div {     padding: 5px 10px;     border-radius: 5px;     margin: 10px 0;     background-color: #e09bb7;   }    .result-div p {     margin: 5px;   }    span.bold {     font-weight: bold;   }    input {     font-size: 25px;   }    p.error {     color: red;   }    .number-input {     padding: 7.5px 10px;   }    .btn-submit {     padding: 10px;     border-radius: 5px;     border: none;     background: #07f;     font-size: 24px;     color: white;     cursor: pointer;     margin: 0 10px;   }

Now open up src/index.js let’s slowly develop it. Add the code below.

const fib = (n) => (n < 2 ? n : fib(n - 1) + fib(n - 2));  const ordinal_suffix = (num) => {   // 1st, 2nd, 3rd, 4th, etc.   const j = num % 10;   const k = num % 100;   switch (true) {     case j === 1 && k !== 11:       return num + "st";     case j === 2 && k !== 12:       return num + "nd";     case j === 3 && k !== 13:       return num + "rd";     default:       return num + "th";   } }; const textCont = (n, fibNum, time) => {   const nth = ordinal_suffix(n);   return &lt;p id='timer'&gt;Time: &lt;span class='bold'&gt;$  {time} ms&lt;/span&gt;&lt;/p&gt;   &lt;p&gt;&lt;span class="bold" id='nth'&gt;$  {nth}&lt;/span&gt; fibonnaci number: &lt;span class="bold" id='sum'&gt;$  {fibNum}&lt;/span&gt;&lt;/p&gt;; };

Here we have three functions. The first one is the function we saw earlier for calculating the nth FN. The second function is just a utility function to attach an appropriate suffix to an integer number. The third function takes some arguments and outputs a markup which we will later insert in the DOM. The first argument is the number whose FN is being computed. The second argument is the computed FN. The last argument is the time it takes to perform the computation.

Still in src/index.js, add the below code just under the previous one.

const errPar = document.getElementById("error"); const btn = document.getElementById("submit-btn"); const input = document.getElementById("number-input"); const resultsContainer = document.getElementById("results-container");  btn.addEventListener("click", (e) => {   errPar.textContent = '';   const num = window.Number(input.value);    if (num < 2) {     errPar.textContent = "Please enter a number greater than 2";     return;   }    const startTime = new Date().getTime();   const sum = fib(num);   const time = new Date().getTime() - startTime;    const resultDiv = document.createElement("div");   resultDiv.innerHTML = textCont(num, sum, time);   resultDiv.className = "result-div";   resultsContainer.appendChild(resultDiv); });

First, we use the document API to get hold of DOM nodes in our HTML file. We get a reference to the paragraph where we’ll display error messages; the input; the calculate button and the container where we’ll show our results.

Next, we attach a “click” event handler to the button. When the button gets clicked, we take whatever is inside the input element and convert it to a number, if we get anything less than 2, we display an error message and return. If we get a number greater than 2, we continue. First, we record the current time. After that, we calculate the FN. When that finishes, we get a time difference that represents how long the computation took. In the remaining part of the code, we create a new div. We then set its inner HTML to be the output of the textCont() function we defined earlier. Finally, we add a class to it (for styling) and append it to the results container. The effect of this is that each computation will appear in a separate div below the previous one.

We can see that as the number increases, the computation time also increases (exponentially). For instance, from 30 to 35, we had the computation time jump from 13ms to 130ms. We can still consider those operations to be “fast”. At 40 we see a computation time of over 1 second. On my machine, this is where I start noticing the page become unresponsive. At this point, I can no longer interact with the page while the computation is on-going. I can’t focus on the input or do anything else.

Recall when we talked about JavaScript being single-threaded? Well, that thread has been “blocked” by this long-running computation, so everything else must “wait” for it to finish. It may start at a lower or higher value on your machine, but you’re bound to reach that point. Notice that it took almost 10s to compute that of 44. If there were other things to do on your web app, well, the user has to wait for Fib(44) to finish before they can continue. But if you deployed a web worker to handle that calculation, your users could carry on with something else while that runs.

Let’s now see how web workers help us overcome this problem.

An Example Web Worker In Action

In this section, we’ll delegate the job of computing the nth FN to a web worker. This will help free up the main thread and keep our UI responsive while the computation is on-going.

Getting started with web workers is surprisingly simple. Let’s see how. Create a new file src/fib-worker.js. and enter the following code.

const fib = (n) => (n < 2 ? n : fib(n - 1) + fib(n - 2));  onmessage = (e) => {   const { num } = e.data;   const startTime = new Date().getTime();   const fibNum = fib(num);   postMessage({     fibNum,     time: new Date().getTime() - startTime,   }); };

Notice that we have moved the function that calculates the nth Fibonacci number, fib inside this file. This file will be run by our web worker.

Recall in the section What is a web worker, we mentioned that web workers and their parent communicate using the onmessage event handler and postMessage() method. Here we’re using the onmessage event handler to listen to messages from the parent script. Once we get a message, we destructure the number from the data attribute of the event. Next, we get the current time and start the computation. Once the result is ready, we use the postMessage() method to post the results back to the parent script.

Open up src/index.js let’s make some changes.

...  const worker = new window.Worker("src/fib-worker.js");  btn.addEventListener("click", (e) => {   errPar.textContent = "";   const num = window.Number(input.value);   if (num < 2) {     errPar.textContent = "Please enter a number greater than 2";     return;   }    worker.postMessage({ num });   worker.onerror = (err) => err;   worker.onmessage = (e) => {     const { time, fibNum } = e.data;     const resultDiv = document.createElement("div");     resultDiv.innerHTML = textCont(num, fibNum, time);     resultDiv.className = "result-div";     resultsContainer.appendChild(resultDiv);   }; });

The first thing to do is to create the web worker using the Worker constructor. Then inside our button’s event listener, we send a number to the worker using worker.postMessage({ num }). After that, we set a function to listen for errors in the worker. Here we simply return the error. You can certainly do more if you want, like showing it in DOM. Next, we listen for messages from the worker. Once we get a message, we destructure time and fibNum, and continue the process of showing them in the DOM.

Note that inside the web worker, the onmessage event is available in the worker’s scope, so we could have written it as self.onmessage and self.postMessage(). But in the parent script, we have to attach these to the worker itself.

In the screenshot below you would see the web worker file in the sources tab of Chrome Dev Tools. What you should notice is that the UI stays responsive no matter what number you enter. This behavior is the magic of web workers.

We’ve made a lot of progress with our web app. But there’s something else we can do to make it better. Our current implementation uses a single worker to handle every computation. If a new message comes while one is running, the old one gets replaced. To get around this, we can create a new worker for each call to calculate the FN. Let’s see how to do that in the next section.

Working With Multiple Web Workers

Currently, we’re handling every request with a single worker. Thus an incoming request will replace a previous one that is yet to finish. What we want now is to make a small change to spawn a new web worker for every request. We will kill this worker once it’s done.

Open up src/index.js and move the line that creates the web worker inside the button’s click event handler. Now the event handler should look like below.

btn.addEventListener("click", (e) => {   errPar.textContent = "";   const num = window.Number(input.value);    if (num < 2) {     errPar.textContent = "Please enter a number greater than 2";     return;   }    const worker = new window.Worker("src/fib-worker.js"); // this line has moved inside the event handler   worker.postMessage({ num });   worker.onerror = (err) => err;   worker.onmessage = (e) => {     const { time, fibNum } = e.data;     const resultDiv = document.createElement("div");     resultDiv.innerHTML = textCont(num, fibNum, time);     resultDiv.className = "result-div";     resultsContainer.appendChild(resultDiv);     worker.terminate() // this line terminates the worker   }; });

We made two changes.

  1. We moved this line const worker = new window.Worker("src/fib-worker.js") inside the button’s click event handler.
  2. We added this line worker.terminate() to discard the worker once we’re done with it.

So for every click of the button, we create a new worker to handle the calculation. Thus we can keep changing the input, and each result will hit the screen once the computation finishes. In the screenshot below you can see that the values for 20 and 30 appear before that of 45. But I started 45 first. Once the function returns for 20 and 30, their results were posted, and the worker terminated. When everything finishes, we shouldn’t have any workers on the sources tab.

We could end this article right here, but if this were a react app, how would we bring web workers into it. That is the focus of the next section.

Web Workers In React

To get started, create a new react app using CRA. Copy the fib-worker.js file into the public/ folder of your react app. Putting the file here stems from the fact that React apps are single-page apps. That’s about the only thing that is specific to using the worker in a react application. Everything that follows from here is pure React.

In src/ folder create a file helpers.js and export the ordinal_suffix() function from it.

// src/helpers.js  export const ordinal_suffix = (num) => {   // 1st, 2nd, 3rd, 4th, etc.   const j = num % 10;   const k = num % 100;   switch (true) {     case j === 1 && k !== 11:       return num + "st";     case j === 2 && k !== 12:       return num + "nd";     case j === 3 && k !== 13:       return num + "rd";     default:       return num + "th";   } };

Our app will require us to maintain some state, so create another file, src/reducer.js and paste in the state reducer.

// src/reducers.js  export const reducer = (state = {}, action) => {   switch (action.type) {     case "SET_ERROR":       return { ...state, err: action.err };     case "SET_NUMBER":       return { ...state, num: action.num };     case "SET_FIBO":       return {         ...state,         computedFibs: [           ...state.computedFibs,           { id: action.id, nth: action.nth, loading: action.loading },         ],       };     case "UPDATE_FIBO": {       const curr = state.computedFibs.filter((c) => c.id === action.id)[0];       const idx = state.computedFibs.indexOf(curr);       curr.loading = false;       curr.time = action.time;       curr.fibNum = action.fibNum;       state.computedFibs[idx] = curr;       return { ...state };     }     default:       return state;   } };

Let’s go over each action type one after the other.

  1. SET_ERROR: sets an error state when triggered.
  2. SET_NUMBER: sets the value in our input box to state.
  3. SET_FIBO: adds a new entry to the array of computed FNs.
  4. UPDATE_FIBO: here we look for a particular entry and replaces it with a new object which has the computed FN and the time taken to compute it.

We shall use this reducer shortly. Before that, let’s create the component that will display the computed FNs. Create a new file src/Results.js and paste in the below code.

// src/Results.js  import React from "react";  export const Results = (props) => {   const { results } = props;   return (     <div id="results-container" className="results-container">       {results.map((fb) => {         const { id, nth, time, fibNum, loading } = fb;         return (           <div key={id} className="result-div">             {loading ? (               <p>                 Calculating the{" "}                 <span className="bold" id="nth">                   {nth}                 </span>{" "}                 Fibonacci number...               </p>             ) : (               <>                 <p id="timer">                   Time: <span className="bold">{time} ms</span>                 </p>                 <p>                   <span className="bold" id="nth">                     {nth}                   </span>{" "}                   fibonnaci number:{" "}                   <span className="bold" id="sum">                     {fibNum}                   </span>                 </p>               </>             )}           </div>         );       })}     </div>   ); };

With this change, we start the process of converting our previous index.html file to jsx. This file has one responsibility: take an array of objects representing computed FNs and display them. The only difference from what we had before is the introduction of a loading state. So now when the computation is running, we show the loading state to let the user know that something is happening.

Let’s put in the final pieces by updating the code inside src/App.js. The code is rather long, so we’ll do it in two steps. Let’s add the first block of code.

import React from "react"; import "./App.css"; import { ordinal_suffix } from "./helpers"; import { reducer } from './reducer' import { Results } from "./Results"; function App() {   const [info, dispatch] = React.useReducer(reducer, {     err: "",     num: "",     computedFibs: [],   });   const runWorker = (num, id) => {     dispatch({ type: "SET_ERROR", err: "" });     const worker = new window.Worker('./fib-worker.js')     worker.postMessage({ num });     worker.onerror = (err) => err;     worker.onmessage = (e) => {       const { time, fibNum } = e.data;       dispatch({         type: "UPDATE_FIBO",         id,         time,         fibNum,       });       worker.terminate();     };   };   return (     <div>       <div className="heading-container">         <h1>Computing the nth Fibonnaci number</h1>       </div>       <div className="body-container">         <p id="error" className="error">           {info.err}         </p>          // ... next block of code goes here ... //          <Results results={info.computedFibs} />       </div>     </div>   ); } export default App;

As usual, we bring in our imports. Then we instantiate a state and updater function with the useReducer hook. We then define a function, runWorker(), that takes a number and an ID and sets about calling a web worker to compute the FN for that number.

Note that to create the worker, we pass a relative path to the worker constructor. At runtime, our React code gets attached to the public/index.html file, thus it can find the fib-worker.js file in the same directory. When the computation completes (triggered by worker.onmessage), the UPDATE_FIBO action gets dispatched, and the worker terminated afterward. What we have now is not much different from what we had previously.

In the return block of this component, we render the same HTML we had before. We also pass the computed numbers array to the <Results /> component for rendering.

Let’s add the final block of code inside the return statement.

        <div className="input-div">           <input             type="number"             value={info.num}             className="number-input"             placeholder="Enter a number"             onChange={(e) =>               dispatch({                 type: "SET_NUMBER",                 num: window.Number(e.target.value),               })             }           />           <button             id="submit-btn"             className="btn-submit"             onClick={() => {               if (info.num < 2) {                 dispatch({                   type: "SET_ERROR",                   err: "Please enter a number greater than 2",                 });                 return;               }               const id = info.computedFibs.length;               dispatch({                 type: "SET_FIBO",                 id,                 loading: true,                 nth: ordinal_suffix(info.num),               });               runWorker(info.num, id);             }}           >             Calculate           </button>         </div>

We set an onChange handler on the input to update the info.num state variable. On the button, we define an onClick event handler. When the button gets clicked, we check if the number is greater than 2. Notice that before calling runWorker(), we first dispatch an action to add an entry to the array of computed FNs. It is this entry that will be updated once the worker finishes its job. In this way, every entry maintains its position in the list, unlike what we had before.

Finally, copy the content of styles.css from before and replace the content of App.css.

We now have everything in place. Now start up your react server and play around with some numbers. Take note of the loading state, which is a UX improvement. Also, note that the UI stays responsive even when you enter a number as high as 1000 and click “Calculate”.

Note the loading state and the active worker. Once the 46th value is computed the worker is killed and the loading state is replaced by the final result.

Conclusion

Phew! It has been a long ride, so let’s wrap it up. I encourage you to take a look at the MDN entry for web workers (see resources list below) to learn other ways of using web workers.

In this article, we learned about what web workers are and the sort of problems they’re meant to solve. We also saw how to implement them using plain JavaScript. Finally, we saw how to implement web workers in a React application.

I encourage you to take advantage of this great API to deliver a better experience for your users.

Further Resources

Articles on Smashing Magazine — For Web Designers And Developers

02 Dec

Managing Long-Running Tasks In A React App With Web Workers

by TBSCategories: News

Response time is a big deal when it comes to web applications. Users demand instantaneous responses, no matter what your app may be doing. Whether it’s only displaying a person’s name or crunching numbers, web app users demand that your app responds to their command every single time. Sometimes that can be hard to achieve given the single-threaded nature of JavaScript. But in this article, we’ll learn how we can leverage the Web Worker API to deliver a better experience.

In writing this article, I made the following assumptions:

  1. To be able to follow along, you should have at least some familiarity with JavaScript and the document API;
  2. You should also have a working knowledge of React so that you can successfully start a new React project using Create React App.

If you need more insights into this topic, I’ve included a number of links in the “Further Resources” section to help you get up to speed.

First, let’s get started with Web Workers.

What Is A Web Worker?

To understand Web Workers and the problem they’re meant to solve, it is necessary to get a grasp of how JavaScript code is executed at runtime. During runtime, JavaScript code is executed sequentially and in a turn-by-turn manner. Once a piece of code ends, then the next one in line starts running, and so on. In technical terms, we say that JavaScript is single-threaded. This behavior implies that once some piece of code starts running, every code that comes after must wait for that code to finish execution. Thus, every line of code “blocks” the execution of everything else that comes after it. It is therefore desirable that every piece of code finish as quickly as possible. If some piece of code takes too long to finish our program would appear to have stopped working. On the browser, this manifests as a frozen, unresponsive page. In some extreme cases, the tab will freeze altogether.

Imagine driving on a single-lane. If any of the drivers ahead of you happen to stop moving for any reason, then, you have a traffic jam. With a program like Java, traffic could continue on other lanes. Thus Java is said to be multi-threaded. Web Workers are an attempt to bring multi-threaded behavior to JavaScript.

The screenshot below shows that the Web Worker API is supported by many browsers, so you should feel confident in using it.

Web Workers run in background threads without interfering with the UI, and they communicate with the code that created them by way of event handlers.

An excellent definition of a Web Worker comes from MDN:

“A worker is an object created using a constructor (e.g. Worker() that runs a named JavaScript file — this file contains the code that will run in the worker thread; workers run in another global context that is different from the current window. Thus, using the window shortcut to get the current global scope (instead of self within a Worker will return an error.”

A worker is created using the Worker constructor.

const worker = new Worker('worker-file.js')

It is possible to run most code inside a web worker, with some exceptions. For example, you can’t manipulate the DOM from inside a worker. There is no access to the document API.

Workers and the thread that spawns them send messages to each other using the postMessage() method. Similarly, they respond to messages using the onmessage event handler. It’s important to get this difference. Sending messages is achieved using a method; receiving a message back requires an event handler. The message being received is contained in the data attribute of the event. We will see an example of this in the next section. But let me quickly mention that the sort of worker we’ve been discussing is called a “dedicated worker”. This means that the worker is only accessible to the script that called it. It is also possible to have a worker that is accessible from multiple scripts. These are called shared workers and are created using the SharedWorker constructor, as shown below.

const sWorker = new SharedWorker('shared-worker-file.js')

To learn more about Workers, please see this MDN article. The purpose of this article is to get you started with using Web workers. Let’s get to it by computing the nth Fibonacci number.

Computing The Nth Fibonacci Number

Note: For this and the next two sections, I’m using Live Server on VSCode to run the app. You can certainly use something else.

This is the section you’ve been waiting for. We’ll finally write some code to see Web Workers in action. Well, not so fast. We wouldn’t appreciate the job a Web Worker does unless we run into the sort of problems it solves. In this section, we’re going to see an example problem, and in the following section, we’ll see how a web worker helps us do better.

Imagine you were building a web app that allowed users to calculate the nth Fibonacci number. In case you’re new to the term ‘Fibonacci number’, you can read more about it here, but in summary, Fibonacci numbers are a sequence of numbers such that each number is the sum of the two preceding numbers.

Mathematically, it is expressed as:

Thus the first few numbers of the sequence are:

1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89 ...

In some sources, the sequence starts at F0 = 0, in which case the formula below holds for n > 1:

In this article we’ll start at F1 = 1. One thing we can see right away from the formula is that the numbers follow a recursive pattern. The task at hand now is to write a recursive function to compute the nth Fibonacci number (FN).

After a few tries, I believe you can easily come up with the function below.

const fib = n => {   if (n < 2) {     return n // or 1   } else {     return fib(n - 1) + fib(n - 2)   } }

The function is simple. If n is less than 2, return n (or 1), otherwise, return the sum of the n-1 and n-2 FNs. With arrow functions and ternary operator, we can come up with a one-liner. 

const fib = n => (n < 2 ? n : fib(n-1) + fib(n-2))

This function has a time complexity of 0(2n). This simply means that as the value of n increases, the time required to compute the sum increases exponentially. This makes for a really long-running task that could potentially interfere with our UI, for large values of n. Let’s see this in action.

Note: This is by no means the best way to solve this particular problem. My choice of using this method is for the purpose of this article.

To start, create a new folder and name it whatever you like. Now inside that folder create a src/ folder. Also, create an index.html file in the root folder. Inside the src/ folder, create a file named index.js.

Open up index.html and add the following HTML code.

<!DOCTYPE html> <html> <head>   <link rel="stylesheet" href="styles.css"> </head> <body>   <div class="heading-container">     <h1>Computing the nth Fibonnaci number</h1>   </div>   <div class="body-container">     <p id='error' class="error"></p>     <div class="input-div">       <input id='number-input' class="number-input" type='number' placeholder="Enter a number" />       <button id='submit-btn' class="btn-submit">Calculate</button>     </div>     <div id='results-container' class="results"></div>   </div>   <script src="/src/index.js"></script> </body> </html>

This part is very simple. First, we have a heading. Then we have a container with an input and a button. A user would enter a number then click on “Calculate”. We also have a container to hold the result of the calculation. Lastly, we include the src/index.js file in a script tag.

You may delete the stylesheet link. But if you’re short on time, I have defined some CSS which you can use. Just create the styles.css file at the root folder and add the styles below:

 body {     margin: 0;     padding: 0;     box-sizing: border-box;   }    .body-container,   .heading-container {     padding: 0 20px;   }    .heading-container {     padding: 20px;     color: white;     background: #7a84dd;   }    .heading-container > h1 {     margin: 0;   }    .body-container {     width: 50%   }    .input-div {     margin-top: 15px;     margin-bottom: 15px;     display: flex;     align-items: center;   }    .results {     width: 50vw;   }    .results>p {     font-size: 24px;   }    .result-div {     padding: 5px 10px;     border-radius: 5px;     margin: 10px 0;     background-color: #e09bb7;   }    .result-div p {     margin: 5px;   }    span.bold {     font-weight: bold;   }    input {     font-size: 25px;   }    p.error {     color: red;   }    .number-input {     padding: 7.5px 10px;   }    .btn-submit {     padding: 10px;     border-radius: 5px;     border: none;     background: #07f;     font-size: 24px;     color: white;     cursor: pointer;     margin: 0 10px;   }

Now open up src/index.js let’s slowly develop it. Add the code below.

const fib = (n) => (n < 2 ? n : fib(n - 1) + fib(n - 2));  const ordinal_suffix = (num) => {   // 1st, 2nd, 3rd, 4th, etc.   const j = num % 10;   const k = num % 100;   switch (true) {     case j === 1 && k !== 11:       return num + "st";     case j === 2 && k !== 12:       return num + "nd";     case j === 3 && k !== 13:       return num + "rd";     default:       return num + "th";   } }; const textCont = (n, fibNum, time) => {   const nth = ordinal_suffix(n);   return &lt;p id='timer'&gt;Time: &lt;span class='bold'&gt;$  {time} ms&lt;/span&gt;&lt;/p&gt;   &lt;p&gt;&lt;span class="bold" id='nth'&gt;$  {nth}&lt;/span&gt; fibonnaci number: &lt;span class="bold" id='sum'&gt;$  {fibNum}&lt;/span&gt;&lt;/p&gt;; };

Here we have three functions. The first one is the function we saw earlier for calculating the nth FN. The second function is just a utility function to attach an appropriate suffix to an integer number. The third function takes some arguments and outputs a markup which we will later insert in the DOM. The first argument is the number whose FN is being computed. The second argument is the computed FN. The last argument is the time it takes to perform the computation.

Still in src/index.js, add the below code just under the previous one.

const errPar = document.getElementById("error"); const btn = document.getElementById("submit-btn"); const input = document.getElementById("number-input"); const resultsContainer = document.getElementById("results-container");  btn.addEventListener("click", (e) => {   errPar.textContent = '';   const num = window.Number(input.value);    if (num < 2) {     errPar.textContent = "Please enter a number greater than 2";     return;   }    const startTime = new Date().getTime();   const sum = fib(num);   const time = new Date().getTime() - startTime;    const resultDiv = document.createElement("div");   resultDiv.innerHTML = textCont(num, sum, time);   resultDiv.className = "result-div";   resultsContainer.appendChild(resultDiv); });

First, we use the document API to get hold of DOM nodes in our HTML file. We get a reference to the paragraph where we’ll display error messages; the input; the calculate button and the container where we’ll show our results.

Next, we attach a “click” event handler to the button. When the button gets clicked, we take whatever is inside the input element and convert it to a number, if we get anything less than 2, we display an error message and return. If we get a number greater than 2, we continue. First, we record the current time. After that, we calculate the FN. When that finishes, we get a time difference that represents how long the computation took. In the remaining part of the code, we create a new div. We then set its inner HTML to be the output of the textCont() function we defined earlier. Finally, we add a class to it (for styling) and append it to the results container. The effect of this is that each computation will appear in a separate div below the previous one.

We can see that as the number increases, the computation time also increases (exponentially). For instance, from 30 to 35, we had the computation time jump from 13ms to 130ms. We can still consider those operations to be “fast”. At 40 we see a computation time of over 1 second. On my machine, this is where I start noticing the page become unresponsive. At this point, I can no longer interact with the page while the computation is on-going. I can’t focus on the input or do anything else.

Recall when we talked about JavaScript being single-threaded? Well, that thread has been “blocked” by this long-running computation, so everything else must “wait” for it to finish. It may start at a lower or higher value on your machine, but you’re bound to reach that point. Notice that it took almost 10s to compute that of 44. If there were other things to do on your web app, well, the user has to wait for Fib(44) to finish before they can continue. But if you deployed a web worker to handle that calculation, your users could carry on with something else while that runs.

Let’s now see how web workers help us overcome this problem.

An Example Web Worker In Action

In this section, we’ll delegate the job of computing the nth FN to a web worker. This will help free up the main thread and keep our UI responsive while the computation is on-going.

Getting started with web workers is surprisingly simple. Let’s see how. Create a new file src/fib-worker.js. and enter the following code.

const fib = (n) => (n < 2 ? n : fib(n - 1) + fib(n - 2));  onmessage = (e) => {   const { num } = e.data;   const startTime = new Date().getTime();   const fibNum = fib(num);   postMessage({     fibNum,     time: new Date().getTime() - startTime,   }); };

Notice that we have moved the function that calculates the nth Fibonacci number, fib inside this file. This file will be run by our web worker.

Recall in the section What is a web worker, we mentioned that web workers and their parent communicate using the onmessage event handler and postMessage() method. Here we’re using the onmessage event handler to listen to messages from the parent script. Once we get a message, we destructure the number from the data attribute of the event. Next, we get the current time and start the computation. Once the result is ready, we use the postMessage() method to post the results back to the parent script.

Open up src/index.js let’s make some changes.

...  const worker = new window.Worker("src/fib-worker.js");  btn.addEventListener("click", (e) => {   errPar.textContent = "";   const num = window.Number(input.value);   if (num < 2) {     errPar.textContent = "Please enter a number greater than 2";     return;   }    worker.postMessage({ num });   worker.onerror = (err) => err;   worker.onmessage = (e) => {     const { time, fibNum } = e.data;     const resultDiv = document.createElement("div");     resultDiv.innerHTML = textCont(num, fibNum, time);     resultDiv.className = "result-div";     resultsContainer.appendChild(resultDiv);   }; });

The first thing to do is to create the web worker using the Worker constructor. Then inside our button’s event listener, we send a number to the worker using worker.postMessage({ num }). After that, we set a function to listen for errors in the worker. Here we simply return the error. You can certainly do more if you want, like showing it in DOM. Next, we listen for messages from the worker. Once we get a message, we destructure time and fibNum, and continue the process of showing them in the DOM.

Note that inside the web worker, the onmessage event is available in the worker’s scope, so we could have written it as self.onmessage and self.postMessage(). But in the parent script, we have to attach these to the worker itself.

In the screenshot below you would see the web worker file in the sources tab of Chrome Dev Tools. What you should notice is that the UI stays responsive no matter what number you enter. This behavior is the magic of web workers.

We’ve made a lot of progress with our web app. But there’s something else we can do to make it better. Our current implementation uses a single worker to handle every computation. If a new message comes while one is running, the old one gets replaced. To get around this, we can create a new worker for each call to calculate the FN. Let’s see how to do that in the next section.

Working With Multiple Web Workers

Currently, we’re handling every request with a single worker. Thus an incoming request will replace a previous one that is yet to finish. What we want now is to make a small change to spawn a new web worker for every request. We will kill this worker once it’s done.

Open up src/index.js and move the line that creates the web worker inside the button’s click event handler. Now the event handler should look like below.

btn.addEventListener("click", (e) => {   errPar.textContent = "";   const num = window.Number(input.value);    if (num < 2) {     errPar.textContent = "Please enter a number greater than 2";     return;   }    const worker = new window.Worker("src/fib-worker.js"); // this line has moved inside the event handler   worker.postMessage({ num });   worker.onerror = (err) => err;   worker.onmessage = (e) => {     const { time, fibNum } = e.data;     const resultDiv = document.createElement("div");     resultDiv.innerHTML = textCont(num, fibNum, time);     resultDiv.className = "result-div";     resultsContainer.appendChild(resultDiv);     worker.terminate() // this line terminates the worker   }; });

We made two changes.

  1. We moved this line const worker = new window.Worker("src/fib-worker.js") inside the button’s click event handler.
  2. We added this line worker.terminate() to discard the worker once we’re done with it.

So for every click of the button, we create a new worker to handle the calculation. Thus we can keep changing the input, and each result will hit the screen once the computation finishes. In the screenshot below you can see that the values for 20 and 30 appear before that of 45. But I started 45 first. Once the function returns for 20 and 30, their results were posted, and the worker terminated. When everything finishes, we shouldn’t have any workers on the sources tab.

We could end this article right here, but if this were a react app, how would we bring web workers into it. That is the focus of the next section.

Web Workers In React

To get started, create a new react app using CRA. Copy the fib-worker.js file into the public/ folder of your react app. Putting the file here stems from the fact that React apps are single-page apps. That’s about the only thing that is specific to using the worker in a react application. Everything that follows from here is pure React.

In src/ folder create a file helpers.js and export the ordinal_suffix() function from it.

// src/helpers.js  export const ordinal_suffix = (num) => {   // 1st, 2nd, 3rd, 4th, etc.   const j = num % 10;   const k = num % 100;   switch (true) {     case j === 1 && k !== 11:       return num + "st";     case j === 2 && k !== 12:       return num + "nd";     case j === 3 && k !== 13:       return num + "rd";     default:       return num + "th";   } };

Our app will require us to maintain some state, so create another file, src/reducer.js and paste in the state reducer.

// src/reducers.js  export const reducer = (state = {}, action) => {   switch (action.type) {     case "SET_ERROR":       return { ...state, err: action.err };     case "SET_NUMBER":       return { ...state, num: action.num };     case "SET_FIBO":       return {         ...state,         computedFibs: [           ...state.computedFibs,           { id: action.id, nth: action.nth, loading: action.loading },         ],       };     case "UPDATE_FIBO": {       const curr = state.computedFibs.filter((c) => c.id === action.id)[0];       const idx = state.computedFibs.indexOf(curr);       curr.loading = false;       curr.time = action.time;       curr.fibNum = action.fibNum;       state.computedFibs[idx] = curr;       return { ...state };     }     default:       return state;   } };

Let’s go over each action type one after the other.

  1. SET_ERROR: sets an error state when triggered.
  2. SET_NUMBER: sets the value in our input box to state.
  3. SET_FIBO: adds a new entry to the array of computed FNs.
  4. UPDATE_FIBO: here we look for a particular entry and replaces it with a new object which has the computed FN and the time taken to compute it.

We shall use this reducer shortly. Before that, let’s create the component that will display the computed FNs. Create a new file src/Results.js and paste in the below code.

// src/Results.js  import React from "react";  export const Results = (props) => {   const { results } = props;   return (     <div id="results-container" className="results-container">       {results.map((fb) => {         const { id, nth, time, fibNum, loading } = fb;         return (           <div key={id} className="result-div">             {loading ? (               <p>                 Calculating the{" "}                 <span className="bold" id="nth">                   {nth}                 </span>{" "}                 Fibonacci number...               </p>             ) : (               <>                 <p id="timer">                   Time: <span className="bold">{time} ms</span>                 </p>                 <p>                   <span className="bold" id="nth">                     {nth}                   </span>{" "}                   fibonnaci number:{" "}                   <span className="bold" id="sum">                     {fibNum}                   </span>                 </p>               </>             )}           </div>         );       })}     </div>   ); };

With this change, we start the process of converting our previous index.html file to jsx. This file has one responsibility: take an array of objects representing computed FNs and display them. The only difference from what we had before is the introduction of a loading state. So now when the computation is running, we show the loading state to let the user know that something is happening.

Let’s put in the final pieces by updating the code inside src/App.js. The code is rather long, so we’ll do it in two steps. Let’s add the first block of code.

import React from "react"; import "./App.css"; import { ordinal_suffix } from "./helpers"; import { reducer } from './reducer' import { Results } from "./Results"; function App() {   const [info, dispatch] = React.useReducer(reducer, {     err: "",     num: "",     computedFibs: [],   });   const runWorker = (num, id) => {     dispatch({ type: "SET_ERROR", err: "" });     const worker = new window.Worker('./fib-worker.js')     worker.postMessage({ num });     worker.onerror = (err) => err;     worker.onmessage = (e) => {       const { time, fibNum } = e.data;       dispatch({         type: "UPDATE_FIBO",         id,         time,         fibNum,       });       worker.terminate();     };   };   return (     <div>       <div className="heading-container">         <h1>Computing the nth Fibonnaci number</h1>       </div>       <div className="body-container">         <p id="error" className="error">           {info.err}         </p>          // ... next block of code goes here ... //          <Results results={info.computedFibs} />       </div>     </div>   ); } export default App;

As usual, we bring in our imports. Then we instantiate a state and updater function with the useReducer hook. We then define a function, runWorker(), that takes a number and an ID and sets about calling a web worker to compute the FN for that number.

Note that to create the worker, we pass a relative path to the worker constructor. At runtime, our React code gets attached to the public/index.html file, thus it can find the fib-worker.js file in the same directory. When the computation completes (triggered by worker.onmessage), the UPDATE_FIBO action gets dispatched, and the worker terminated afterward. What we have now is not much different from what we had previously.

In the return block of this component, we render the same HTML we had before. We also pass the computed numbers array to the <Results /> component for rendering.

Let’s add the final block of code inside the return statement.

        <div className="input-div">           <input             type="number"             value={info.num}             className="number-input"             placeholder="Enter a number"             onChange={(e) =>               dispatch({                 type: "SET_NUMBER",                 num: window.Number(e.target.value),               })             }           />           <button             id="submit-btn"             className="btn-submit"             onClick={() => {               if (info.num < 2) {                 dispatch({                   type: "SET_ERROR",                   err: "Please enter a number greater than 2",                 });                 return;               }               const id = info.computedFibs.length;               dispatch({                 type: "SET_FIBO",                 id,                 loading: true,                 nth: ordinal_suffix(info.num),               });               runWorker(info.num, id);             }}           >             Calculate           </button>         </div>

We set an onChange handler on the input to update the info.num state variable. On the button, we define an onClick event handler. When the button gets clicked, we check if the number is greater than 2. Notice that before calling runWorker(), we first dispatch an action to add an entry to the array of computed FNs. It is this entry that will be updated once the worker finishes its job. In this way, every entry maintains its position in the list, unlike what we had before.

Finally, copy the content of styles.css from before and replace the content of App.css.

We now have everything in place. Now start up your react server and play around with some numbers. Take note of the loading state, which is a UX improvement. Also, note that the UI stays responsive even when you enter a number as high as 1000 and click “Calculate”.

Note the loading state and the active worker. Once the 46th value is computed the worker is killed and the loading state is replaced by the final result.

Conclusion

Phew! It has been a long ride, so let’s wrap it up. I encourage you to take a look at the MDN entry for web workers (see resources list below) to learn other ways of using web workers.

In this article, we learned about what web workers are and the sort of problems they’re meant to solve. We also saw how to implement them using plain JavaScript. Finally, we saw how to implement web workers in a React application.

I encourage you to take advantage of this great API to deliver a better experience for your users.

Further Resources

Articles on Smashing Magazine — For Web Designers And Developers

01 Dec

Managing Long-Running Tasks In A React App With Web Workers

by TBSCategories: News

Response time is a big deal when it comes to web applications. Users demand instantaneous responses, no matter what your app may be doing. Whether it’s only displaying a person’s name or crunching numbers, web app users demand that your app responds to their command every single time. Sometimes that can be hard to achieve given the single-threaded nature of JavaScript. But in this article, we’ll learn how we can leverage the Web Worker API to deliver a better experience.

In writing this article, I made the following assumptions:

  1. To be able to follow along, you should have at least some familiarity with JavaScript and the document API;
  2. You should also have a working knowledge of React so that you can successfully start a new React project using Create React App.

If you need more insights into this topic, I’ve included a number of links in the “Further Resources” section to help you get up to speed.

First, let’s get started with Web Workers.

What Is A Web Worker?

To understand Web Workers and the problem they’re meant to solve, it is necessary to get a grasp of how JavaScript code is executed at runtime. During runtime, JavaScript code is executed sequentially and in a turn-by-turn manner. Once a piece of code ends, then the next one in line starts running, and so on. In technical terms, we say that JavaScript is single-threaded. This behavior implies that once some piece of code starts running, every code that comes after must wait for that code to finish execution. Thus, every line of code “blocks” the execution of everything else that comes after it. It is therefore desirable that every piece of code finish as quickly as possible. If some piece of code takes too long to finish our program would appear to have stopped working. On the browser, this manifests as a frozen, unresponsive page. In some extreme cases, the tab will freeze altogether.

Imagine driving on a single-lane. If any of the drivers ahead of you happen to stop moving for any reason, then, you have a traffic jam. With a program like Java, traffic could continue on other lanes. Thus Java is said to be multi-threaded. Web Workers are an attempt to bring multi-threaded behavior to JavaScript.

The screenshot below shows that the Web Worker API is supported by many browsers, so you should feel confident in using it.

Web Workers run in background threads without interfering with the UI, and they communicate with the code that created them by way of event handlers.

An excellent definition of a Web Worker comes from MDN:

“A worker is an object created using a constructor (e.g. Worker() that runs a named JavaScript file — this file contains the code that will run in the worker thread; workers run in another global context that is different from the current window. Thus, using the window shortcut to get the current global scope (instead of self within a Worker will return an error.”

A worker is created using the Worker constructor.

const worker = new Worker('worker-file.js')

It is possible to run most code inside a web worker, with some exceptions. For example, you can’t manipulate the DOM from inside a worker. There is no access to the document API.

Workers and the thread that spawns them send messages to each other using the postMessage() method. Similarly, they respond to messages using the onmessage event handler. It’s important to get this difference. Sending messages is achieved using a method; receiving a message back requires an event handler. The message being received is contained in the data attribute of the event. We will see an example of this in the next section. But let me quickly mention that the sort of worker we’ve been discussing is called a “dedicated worker”. This means that the worker is only accessible to the script that called it. It is also possible to have a worker that is accessible from multiple scripts. These are called shared workers and are created using the SharedWorker constructor, as shown below.

const sWorker = new SharedWorker('shared-worker-file.js')

To learn more about Workers, please see this MDN article. The purpose of this article is to get you started with using Web workers. Let’s get to it by computing the nth Fibonacci number.

Computing The Nth Fibonacci Number

Note: For this and the next two sections, I’m using Live Server on VSCode to run the app. You can certainly use something else.

This is the section you’ve been waiting for. We’ll finally write some code to see Web Workers in action. Well, not so fast. We wouldn’t appreciate the job a Web Worker does unless we run into the sort of problems it solves. In this section, we’re going to see an example problem, and in the following section, we’ll see how a web worker helps us do better.

Imagine you were building a web app that allowed users to calculate the nth Fibonacci number. In case you’re new to the term ‘Fibonacci number’, you can read more about it here, but in summary, Fibonacci numbers are a sequence of numbers such that each number is the sum of the two preceding numbers.

Mathematically, it is expressed as:

Thus the first few numbers of the sequence are:

1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89 ...

In some sources, the sequence starts at F0 = 0, in which case the formula below holds for n > 1:

In this article we’ll start at F1 = 1. One thing we can see right away from the formula is that the numbers follow a recursive pattern. The task at hand now is to write a recursive function to compute the nth Fibonacci number (FN).

After a few tries, I believe you can easily come up with the function below.

const fib = n => {   if (n < 2) {     return n // or 1   } else {     return fib(n - 1) + fib(n - 2)   } }

The function is simple. If n is less than 2, return n (or 1), otherwise, return the sum of the n-1 and n-2 FNs. With arrow functions and ternary operator, we can come up with a one-liner. 

const fib = n => (n < 2 ? n : fib(n-1) + fib(n-2))

This function has a time complexity of 0(2n). This simply means that as the value of n increases, the time required to compute the sum increases exponentially. This makes for a really long-running task that could potentially interfere with our UI, for large values of n. Let’s see this in action.

Note: This is by no means the best way to solve this particular problem. My choice of using this method is for the purpose of this article.

To start, create a new folder and name it whatever you like. Now inside that folder create a src/ folder. Also, create an index.html file in the root folder. Inside the src/ folder, create a file named index.js.

Open up index.html and add the following HTML code.

<!DOCTYPE html> <html> <head>   <link rel="stylesheet" href="styles.css"> </head> <body>   <div class="heading-container">     <h1>Computing the nth Fibonnaci number</h1>   </div>   <div class="body-container">     <p id='error' class="error"></p>     <div class="input-div">       <input id='number-input' class="number-input" type='number' placeholder="Enter a number" />       <button id='submit-btn' class="btn-submit">Calculate</button>     </div>     <div id='results-container' class="results"></div>   </div>   <script src="/src/index.js"></script> </body> </html>

This part is very simple. First, we have a heading. Then we have a container with an input and a button. A user would enter a number then click on “Calculate”. We also have a container to hold the result of the calculation. Lastly, we include the src/index.js file in a script tag.

You may delete the stylesheet link. But if you’re short on time, I have defined some CSS which you can use. Just create the styles.css file at the root folder and add the styles below:

 body {     margin: 0;     padding: 0;     box-sizing: border-box;   }    .body-container,   .heading-container {     padding: 0 20px;   }    .heading-container {     padding: 20px;     color: white;     background: #7a84dd;   }    .heading-container > h1 {     margin: 0;   }    .body-container {     width: 50%   }    .input-div {     margin-top: 15px;     margin-bottom: 15px;     display: flex;     align-items: center;   }    .results {     width: 50vw;   }    .results>p {     font-size: 24px;   }    .result-div {     padding: 5px 10px;     border-radius: 5px;     margin: 10px 0;     background-color: #e09bb7;   }    .result-div p {     margin: 5px;   }    span.bold {     font-weight: bold;   }    input {     font-size: 25px;   }    p.error {     color: red;   }    .number-input {     padding: 7.5px 10px;   }    .btn-submit {     padding: 10px;     border-radius: 5px;     border: none;     background: #07f;     font-size: 24px;     color: white;     cursor: pointer;     margin: 0 10px;   }

Now open up src/index.js let’s slowly develop it. Add the code below.

const fib = (n) => (n < 2 ? n : fib(n - 1) + fib(n - 2));  const ordinal_suffix = (num) => {   // 1st, 2nd, 3rd, 4th, etc.   const j = num % 10;   const k = num % 100;   switch (true) {     case j === 1 && k !== 11:       return num + "st";     case j === 2 && k !== 12:       return num + "nd";     case j === 3 && k !== 13:       return num + "rd";     default:       return num + "th";   } }; const textCont = (n, fibNum, time) => {   const nth = ordinal_suffix(n);   return &lt;p id='timer'&gt;Time: &lt;span class='bold'&gt;$  {time} ms&lt;/span&gt;&lt;/p&gt;   &lt;p&gt;&lt;span class="bold" id='nth'&gt;$  {nth}&lt;/span&gt; fibonnaci number: &lt;span class="bold" id='sum'&gt;$  {fibNum}&lt;/span&gt;&lt;/p&gt;; };

Here we have three functions. The first one is the function we saw earlier for calculating the nth FN. The second function is just a utility function to attach an appropriate suffix to an integer number. The third function takes some arguments and outputs a markup which we will later insert in the DOM. The first argument is the number whose FN is being computed. The second argument is the computed FN. The last argument is the time it takes to perform the computation.

Still in src/index.js, add the below code just under the previous one.

const errPar = document.getElementById("error"); const btn = document.getElementById("submit-btn"); const input = document.getElementById("number-input"); const resultsContainer = document.getElementById("results-container");  btn.addEventListener("click", (e) => {   errPar.textContent = '';   const num = window.Number(input.value);    if (num < 2) {     errPar.textContent = "Please enter a number greater than 2";     return;   }    const startTime = new Date().getTime();   const sum = fib(num);   const time = new Date().getTime() - startTime;    const resultDiv = document.createElement("div");   resultDiv.innerHTML = textCont(num, sum, time);   resultDiv.className = "result-div";   resultsContainer.appendChild(resultDiv); });

First, we use the document API to get hold of DOM nodes in our HTML file. We get a reference to the paragraph where we’ll display error messages; the input; the calculate button and the container where we’ll show our results.

Next, we attach a “click” event handler to the button. When the button gets clicked, we take whatever is inside the input element and convert it to a number, if we get anything less than 2, we display an error message and return. If we get a number greater than 2, we continue. First, we record the current time. After that, we calculate the FN. When that finishes, we get a time difference that represents how long the computation took. In the remaining part of the code, we create a new div. We then set its inner HTML to be the output of the textCont() function we defined earlier. Finally, we add a class to it (for styling) and append it to the results container. The effect of this is that each computation will appear in a separate div below the previous one.

We can see that as the number increases, the computation time also increases (exponentially). For instance, from 30 to 35, we had the computation time jump from 13ms to 130ms. We can still consider those operations to be “fast”. At 40 we see a computation time of over 1 second. On my machine, this is where I start noticing the page become unresponsive. At this point, I can no longer interact with the page while the computation is on-going. I can’t focus on the input or do anything else.

Recall when we talked about JavaScript being single-threaded? Well, that thread has been “blocked” by this long-running computation, so everything else must “wait” for it to finish. It may start at a lower or higher value on your machine, but you’re bound to reach that point. Notice that it took almost 10s to compute that of 44. If there were other things to do on your web app, well, the user has to wait for Fib(44) to finish before they can continue. But if you deployed a web worker to handle that calculation, your users could carry on with something else while that runs.

Let’s now see how web workers help us overcome this problem.

An Example Web Worker In Action

In this section, we’ll delegate the job of computing the nth FN to a web worker. This will help free up the main thread and keep our UI responsive while the computation is on-going.

Getting started with web workers is surprisingly simple. Let’s see how. Create a new file src/fib-worker.js. and enter the following code.

const fib = (n) => (n < 2 ? n : fib(n - 1) + fib(n - 2));  onmessage = (e) => {   const { num } = e.data;   const startTime = new Date().getTime();   const fibNum = fib(num);   postMessage({     fibNum,     time: new Date().getTime() - startTime,   }); };

Notice that we have moved the function that calculates the nth Fibonacci number, fib inside this file. This file will be run by our web worker.

Recall in the section What is a web worker, we mentioned that web workers and their parent communicate using the onmessage event handler and postMessage() method. Here we’re using the onmessage event handler to listen to messages from the parent script. Once we get a message, we destructure the number from the data attribute of the event. Next, we get the current time and start the computation. Once the result is ready, we use the postMessage() method to post the results back to the parent script.

Open up src/index.js let’s make some changes.

...  const worker = new window.Worker("src/fib-worker.js");  btn.addEventListener("click", (e) => {   errPar.textContent = "";   const num = window.Number(input.value);   if (num < 2) {     errPar.textContent = "Please enter a number greater than 2";     return;   }    worker.postMessage({ num });   worker.onerror = (err) => err;   worker.onmessage = (e) => {     const { time, fibNum } = e.data;     const resultDiv = document.createElement("div");     resultDiv.innerHTML = textCont(num, fibNum, time);     resultDiv.className = "result-div";     resultsContainer.appendChild(resultDiv);   }; });

The first thing to do is to create the web worker using the Worker constructor. Then inside our button’s event listener, we send a number to the worker using worker.postMessage({ num }). After that, we set a function to listen for errors in the worker. Here we simply return the error. You can certainly do more if you want, like showing it in DOM. Next, we listen for messages from the worker. Once we get a message, we destructure time and fibNum, and continue the process of showing them in the DOM.

Note that inside the web worker, the onmessage event is available in the worker’s scope, so we could have written it as self.onmessage and self.postMessage(). But in the parent script, we have to attach these to the worker itself.

In the screenshot below you would see the web worker file in the sources tab of Chrome Dev Tools. What you should notice is that the UI stays responsive no matter what number you enter. This behavior is the magic of web workers.

We’ve made a lot of progress with our web app. But there’s something else we can do to make it better. Our current implementation uses a single worker to handle every computation. If a new message comes while one is running, the old one gets replaced. To get around this, we can create a new worker for each call to calculate the FN. Let’s see how to do that in the next section.

Working With Multiple Web Workers

Currently, we’re handling every request with a single worker. Thus an incoming request will replace a previous one that is yet to finish. What we want now is to make a small change to spawn a new web worker for every request. We will kill this worker once it’s done.

Open up src/index.js and move the line that creates the web worker inside the button’s click event handler. Now the event handler should look like below.

btn.addEventListener("click", (e) => {   errPar.textContent = "";   const num = window.Number(input.value);    if (num < 2) {     errPar.textContent = "Please enter a number greater than 2";     return;   }    const worker = new window.Worker("src/fib-worker.js"); // this line has moved inside the event handler   worker.postMessage({ num });   worker.onerror = (err) => err;   worker.onmessage = (e) => {     const { time, fibNum } = e.data;     const resultDiv = document.createElement("div");     resultDiv.innerHTML = textCont(num, fibNum, time);     resultDiv.className = "result-div";     resultsContainer.appendChild(resultDiv);     worker.terminate() // this line terminates the worker   }; });

We made two changes.

  1. We moved this line const worker = new window.Worker("src/fib-worker.js") inside the button’s click event handler.
  2. We added this line worker.terminate() to discard the worker once we’re done with it.

So for every click of the button, we create a new worker to handle the calculation. Thus we can keep changing the input, and each result will hit the screen once the computation finishes. In the screenshot below you can see that the values for 20 and 30 appear before that of 45. But I started 45 first. Once the function returns for 20 and 30, their results were posted, and the worker terminated. When everything finishes, we shouldn’t have any workers on the sources tab.

We could end this article right here, but if this were a react app, how would we bring web workers into it. That is the focus of the next section.

Web Workers In React

To get started, create a new react app using CRA. Copy the fib-worker.js file into the public/ folder of your react app. Putting the file here stems from the fact that React apps are single-page apps. That’s about the only thing that is specific to using the worker in a react application. Everything that follows from here is pure React.

In src/ folder create a file helpers.js and export the ordinal_suffix() function from it.

// src/helpers.js  export const ordinal_suffix = (num) => {   // 1st, 2nd, 3rd, 4th, etc.   const j = num % 10;   const k = num % 100;   switch (true) {     case j === 1 && k !== 11:       return num + "st";     case j === 2 && k !== 12:       return num + "nd";     case j === 3 && k !== 13:       return num + "rd";     default:       return num + "th";   } };

Our app will require us to maintain some state, so create another file, src/reducer.js and paste in the state reducer.

// src/reducers.js  export const reducer = (state = {}, action) => {   switch (action.type) {     case "SET_ERROR":       return { ...state, err: action.err };     case "SET_NUMBER":       return { ...state, num: action.num };     case "SET_FIBO":       return {         ...state,         computedFibs: [           ...state.computedFibs,           { id: action.id, nth: action.nth, loading: action.loading },         ],       };     case "UPDATE_FIBO": {       const curr = state.computedFibs.filter((c) => c.id === action.id)[0];       const idx = state.computedFibs.indexOf(curr);       curr.loading = false;       curr.time = action.time;       curr.fibNum = action.fibNum;       state.computedFibs[idx] = curr;       return { ...state };     }     default:       return state;   } };

Let’s go over each action type one after the other.

  1. SET_ERROR: sets an error state when triggered.
  2. SET_NUMBER: sets the value in our input box to state.
  3. SET_FIBO: adds a new entry to the array of computed FNs.
  4. UPDATE_FIBO: here we look for a particular entry and replaces it with a new object which has the computed FN and the time taken to compute it.

We shall use this reducer shortly. Before that, let’s create the component that will display the computed FNs. Create a new file src/Results.js and paste in the below code.

// src/Results.js  import React from "react";  export const Results = (props) => {   const { results } = props;   return (     <div id="results-container" className="results-container">       {results.map((fb) => {         const { id, nth, time, fibNum, loading } = fb;         return (           <div key={id} className="result-div">             {loading ? (               <p>                 Calculating the{" "}                 <span className="bold" id="nth">                   {nth}                 </span>{" "}                 Fibonacci number...               </p>             ) : (               <>                 <p id="timer">                   Time: <span className="bold">{time} ms</span>                 </p>                 <p>                   <span className="bold" id="nth">                     {nth}                   </span>{" "}                   fibonnaci number:{" "}                   <span className="bold" id="sum">                     {fibNum}                   </span>                 </p>               </>             )}           </div>         );       })}     </div>   ); };

With this change, we start the process of converting our previous index.html file to jsx. This file has one responsibility: take an array of objects representing computed FNs and display them. The only difference from what we had before is the introduction of a loading state. So now when the computation is running, we show the loading state to let the user know that something is happening.

Let’s put in the final pieces by updating the code inside src/App.js. The code is rather long, so we’ll do it in two steps. Let’s add the first block of code.

import React from "react"; import "./App.css"; import { ordinal_suffix } from "./helpers"; import { reducer } from './reducer' import { Results } from "./Results"; function App() {   const [info, dispatch] = React.useReducer(reducer, {     err: "",     num: "",     computedFibs: [],   });   const runWorker = (num, id) => {     dispatch({ type: "SET_ERROR", err: "" });     const worker = new window.Worker('./fib-worker.js')     worker.postMessage({ num });     worker.onerror = (err) => err;     worker.onmessage = (e) => {       const { time, fibNum } = e.data;       dispatch({         type: "UPDATE_FIBO",         id,         time,         fibNum,       });       worker.terminate();     };   };   return (     <div>       <div className="heading-container">         <h1>Computing the nth Fibonnaci number</h1>       </div>       <div className="body-container">         <p id="error" className="error">           {info.err}         </p>          // ... next block of code goes here ... //          <Results results={info.computedFibs} />       </div>     </div>   ); } export default App;

As usual, we bring in our imports. Then we instantiate a state and updater function with the useReducer hook. We then define a function, runWorker(), that takes a number and an ID and sets about calling a web worker to compute the FN for that number.

Note that to create the worker, we pass a relative path to the worker constructor. At runtime, our React code gets attached to the public/index.html file, thus it can find the fib-worker.js file in the same directory. When the computation completes (triggered by worker.onmessage), the UPDATE_FIBO action gets dispatched, and the worker terminated afterward. What we have now is not much different from what we had previously.

In the return block of this component, we render the same HTML we had before. We also pass the computed numbers array to the <Results /> component for rendering.

Let’s add the final block of code inside the return statement.

        <div className="input-div">           <input             type="number"             value={info.num}             className="number-input"             placeholder="Enter a number"             onChange={(e) =>               dispatch({                 type: "SET_NUMBER",                 num: window.Number(e.target.value),               })             }           />           <button             id="submit-btn"             className="btn-submit"             onClick={() => {               if (info.num < 2) {                 dispatch({                   type: "SET_ERROR",                   err: "Please enter a number greater than 2",                 });                 return;               }               const id = info.computedFibs.length;               dispatch({                 type: "SET_FIBO",                 id,                 loading: true,                 nth: ordinal_suffix(info.num),               });               runWorker(info.num, id);             }}           >             Calculate           </button>         </div>

We set an onChange handler on the input to update the info.num state variable. On the button, we define an onClick event handler. When the button gets clicked, we check if the number is greater than 2. Notice that before calling runWorker(), we first dispatch an action to add an entry to the array of computed FNs. It is this entry that will be updated once the worker finishes its job. In this way, every entry maintains its position in the list, unlike what we had before.

Finally, copy the content of styles.css from before and replace the content of App.css.

We now have everything in place. Now start up your react server and play around with some numbers. Take note of the loading state, which is a UX improvement. Also, note that the UI stays responsive even when you enter a number as high as 1000 and click “Calculate”.

Note the loading state and the active worker. Once the 46th value is computed the worker is killed and the loading state is replaced by the final result.

Conclusion

Phew! It has been a long ride, so let’s wrap it up. I encourage you to take a look at the MDN entry for web workers (see resources list below) to learn other ways of using web workers.

In this article, we learned about what web workers are and the sort of problems they’re meant to solve. We also saw how to implement them using plain JavaScript. Finally, we saw how to implement web workers in a React application.

I encourage you to take advantage of this great API to deliver a better experience for your users.

Further Resources

Articles on Smashing Magazine — For Web Designers And Developers

01 Dec

Managing Long-Running Tasks In A React App With Web Workers

by TBSCategories: News

Response time is a big deal when it comes to web applications. Users demand instantaneous responses, no matter what your app may be doing. Whether it’s only displaying a person’s name or crunching numbers, web app users demand that your app responds to their command every single time. Sometimes that can be hard to achieve given the single-threaded nature of JavaScript. But in this article, we’ll learn how we can leverage the Web Worker API to deliver a better experience.

In writing this article, I made the following assumptions:

  1. To be able to follow along, you should have at least some familiarity with JavaScript and the document API;
  2. You should also have a working knowledge of React so that you can successfully start a new React project using Create React App.

If you need more insights into this topic, I’ve included a number of links in the “Further Resources” section to help you get up to speed.

First, let’s get started with Web Workers.

What Is A Web Worker?

To understand Web Workers and the problem they’re meant to solve, it is necessary to get a grasp of how JavaScript code is executed at runtime. During runtime, JavaScript code is executed sequentially and in a turn-by-turn manner. Once a piece of code ends, then the next one in line starts running, and so on. In technical terms, we say that JavaScript is single-threaded. This behavior implies that once some piece of code starts running, every code that comes after must wait for that code to finish execution. Thus, every line of code “blocks” the execution of everything else that comes after it. It is therefore desirable that every piece of code finish as quickly as possible. If some piece of code takes too long to finish our program would appear to have stopped working. On the browser, this manifests as a frozen, unresponsive page. In some extreme cases, the tab will freeze altogether.

Imagine driving on a single-lane. If any of the drivers ahead of you happen to stop moving for any reason, then, you have a traffic jam. With a program like Java, traffic could continue on other lanes. Thus Java is said to be multi-threaded. Web Workers are an attempt to bring multi-threaded behavior to JavaScript.

The screenshot below shows that the Web Worker API is supported by many browsers, so you should feel confident in using it.

Web Workers run in background threads without interfering with the UI, and they communicate with the code that created them by way of event handlers.

An excellent definition of a Web Worker comes from MDN:

“A worker is an object created using a constructor (e.g. Worker() that runs a named JavaScript file — this file contains the code that will run in the worker thread; workers run in another global context that is different from the current window. Thus, using the window shortcut to get the current global scope (instead of self within a Worker will return an error.”

A worker is created using the Worker constructor.

const worker = new Worker('worker-file.js')

It is possible to run most code inside a web worker, with some exceptions. For example, you can’t manipulate the DOM from inside a worker. There is no access to the document API.

Workers and the thread that spawns them send messages to each other using the postMessage() method. Similarly, they respond to messages using the onmessage event handler. It’s important to get this difference. Sending messages is achieved using a method; receiving a message back requires an event handler. The message being received is contained in the data attribute of the event. We will see an example of this in the next section. But let me quickly mention that the sort of worker we’ve been discussing is called a “dedicated worker”. This means that the worker is only accessible to the script that called it. It is also possible to have a worker that is accessible from multiple scripts. These are called shared workers and are created using the SharedWorker constructor, as shown below.

const sWorker = new SharedWorker('shared-worker-file.js')

To learn more about Workers, please see this MDN article. The purpose of this article is to get you started with using Web workers. Let’s get to it by computing the nth Fibonacci number.

Computing The Nth Fibonacci Number

Note: For this and the next two sections, I’m using Live Server on VSCode to run the app. You can certainly use something else.

This is the section you’ve been waiting for. We’ll finally write some code to see Web Workers in action. Well, not so fast. We wouldn’t appreciate the job a Web Worker does unless we run into the sort of problems it solves. In this section, we’re going to see an example problem, and in the following section, we’ll see how a web worker helps us do better.

Imagine you were building a web app that allowed users to calculate the nth Fibonacci number. In case you’re new to the term ‘Fibonacci number’, you can read more about it here, but in summary, Fibonacci numbers are a sequence of numbers such that each number is the sum of the two preceding numbers.

Mathematically, it is expressed as:

Thus the first few numbers of the sequence are:

1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89 ...

In some sources, the sequence starts at F0 = 0, in which case the formula below holds for n > 1:

In this article we’ll start at F1 = 1. One thing we can see right away from the formula is that the numbers follow a recursive pattern. The task at hand now is to write a recursive function to compute the nth Fibonacci number (FN).

After a few tries, I believe you can easily come up with the function below.

const fib = n => {   if (n < 2) {     return n // or 1   } else {     return fib(n - 1) + fib(n - 2)   } }

The function is simple. If n is less than 2, return n (or 1), otherwise, return the sum of the n-1 and n-2 FNs. With arrow functions and ternary operator, we can come up with a one-liner. 

const fib = n => (n < 2 ? n : fib(n-1) + fib(n-2))

This function has a time complexity of 0(2n). This simply means that as the value of n increases, the time required to compute the sum increases exponentially. This makes for a really long-running task that could potentially interfere with our UI, for large values of n. Let’s see this in action.

Note: This is by no means the best way to solve this particular problem. My choice of using this method is for the purpose of this article.

To start, create a new folder and name it whatever you like. Now inside that folder create a src/ folder. Also, create an index.html file in the root folder. Inside the src/ folder, create a file named index.js.

Open up index.html and add the following HTML code.

<!DOCTYPE html> <html> <head>   <link rel="stylesheet" href="styles.css"> </head> <body>   <div class="heading-container">     <h1>Computing the nth Fibonnaci number</h1>   </div>   <div class="body-container">     <p id='error' class="error"></p>     <div class="input-div">       <input id='number-input' class="number-input" type='number' placeholder="Enter a number" />       <button id='submit-btn' class="btn-submit">Calculate</button>     </div>     <div id='results-container' class="results"></div>   </div>   <script src="/src/index.js"></script> </body> </html>

This part is very simple. First, we have a heading. Then we have a container with an input and a button. A user would enter a number then click on “Calculate”. We also have a container to hold the result of the calculation. Lastly, we include the src/index.js file in a script tag.

You may delete the stylesheet link. But if you’re short on time, I have defined some CSS which you can use. Just create the styles.css file at the root folder and add the styles below:

 body {     margin: 0;     padding: 0;     box-sizing: border-box;   }    .body-container,   .heading-container {     padding: 0 20px;   }    .heading-container {     padding: 20px;     color: white;     background: #7a84dd;   }    .heading-container > h1 {     margin: 0;   }    .body-container {     width: 50%   }    .input-div {     margin-top: 15px;     margin-bottom: 15px;     display: flex;     align-items: center;   }    .results {     width: 50vw;   }    .results>p {     font-size: 24px;   }    .result-div {     padding: 5px 10px;     border-radius: 5px;     margin: 10px 0;     background-color: #e09bb7;   }    .result-div p {     margin: 5px;   }    span.bold {     font-weight: bold;   }    input {     font-size: 25px;   }    p.error {     color: red;   }    .number-input {     padding: 7.5px 10px;   }    .btn-submit {     padding: 10px;     border-radius: 5px;     border: none;     background: #07f;     font-size: 24px;     color: white;     cursor: pointer;     margin: 0 10px;   }

Now open up src/index.js let’s slowly develop it. Add the code below.

const fib = (n) => (n < 2 ? n : fib(n - 1) + fib(n - 2));  const ordinal_suffix = (num) => {   // 1st, 2nd, 3rd, 4th, etc.   const j = num % 10;   const k = num % 100;   switch (true) {     case j === 1 && k !== 11:       return num + "st";     case j === 2 && k !== 12:       return num + "nd";     case j === 3 && k !== 13:       return num + "rd";     default:       return num + "th";   } }; const textCont = (n, fibNum, time) => {   const nth = ordinal_suffix(n);   return &lt;p id='timer'&gt;Time: &lt;span class='bold'&gt;$  {time} ms&lt;/span&gt;&lt;/p&gt;   &lt;p&gt;&lt;span class="bold" id='nth'&gt;$  {nth}&lt;/span&gt; fibonnaci number: &lt;span class="bold" id='sum'&gt;$  {fibNum}&lt;/span&gt;&lt;/p&gt;; };

Here we have three functions. The first one is the function we saw earlier for calculating the nth FN. The second function is just a utility function to attach an appropriate suffix to an integer number. The third function takes some arguments and outputs a markup which we will later insert in the DOM. The first argument is the number whose FN is being computed. The second argument is the computed FN. The last argument is the time it takes to perform the computation.

Still in src/index.js, add the below code just under the previous one.

const errPar = document.getElementById("error"); const btn = document.getElementById("submit-btn"); const input = document.getElementById("number-input"); const resultsContainer = document.getElementById("results-container");  btn.addEventListener("click", (e) => {   errPar.textContent = '';   const num = window.Number(input.value);    if (num < 2) {     errPar.textContent = "Please enter a number greater than 2";     return;   }    const startTime = new Date().getTime();   const sum = fib(num);   const time = new Date().getTime() - startTime;    const resultDiv = document.createElement("div");   resultDiv.innerHTML = textCont(num, sum, time);   resultDiv.className = "result-div";   resultsContainer.appendChild(resultDiv); });

First, we use the document API to get hold of DOM nodes in our HTML file. We get a reference to the paragraph where we’ll display error messages; the input; the calculate button and the container where we’ll show our results.

Next, we attach a “click” event handler to the button. When the button gets clicked, we take whatever is inside the input element and convert it to a number, if we get anything less than 2, we display an error message and return. If we get a number greater than 2, we continue. First, we record the current time. After that, we calculate the FN. When that finishes, we get a time difference that represents how long the computation took. In the remaining part of the code, we create a new div. We then set its inner HTML to be the output of the textCont() function we defined earlier. Finally, we add a class to it (for styling) and append it to the results container. The effect of this is that each computation will appear in a separate div below the previous one.

We can see that as the number increases, the computation time also increases (exponentially). For instance, from 30 to 35, we had the computation time jump from 13ms to 130ms. We can still consider those operations to be “fast”. At 40 we see a computation time of over 1 second. On my machine, this is where I start noticing the page become unresponsive. At this point, I can no longer interact with the page while the computation is on-going. I can’t focus on the input or do anything else.

Recall when we talked about JavaScript being single-threaded? Well, that thread has been “blocked” by this long-running computation, so everything else must “wait” for it to finish. It may start at a lower or higher value on your machine, but you’re bound to reach that point. Notice that it took almost 10s to compute that of 44. If there were other things to do on your web app, well, the user has to wait for Fib(44) to finish before they can continue. But if you deployed a web worker to handle that calculation, your users could carry on with something else while that runs.

Let’s now see how web workers help us overcome this problem.

An Example Web Worker In Action

In this section, we’ll delegate the job of computing the nth FN to a web worker. This will help free up the main thread and keep our UI responsive while the computation is on-going.

Getting started with web workers is surprisingly simple. Let’s see how. Create a new file src/fib-worker.js. and enter the following code.

const fib = (n) => (n < 2 ? n : fib(n - 1) + fib(n - 2));  onmessage = (e) => {   const { num } = e.data;   const startTime = new Date().getTime();   const fibNum = fib(num);   postMessage({     fibNum,     time: new Date().getTime() - startTime,   }); };

Notice that we have moved the function that calculates the nth Fibonacci number, fib inside this file. This file will be run by our web worker.

Recall in the section What is a web worker, we mentioned that web workers and their parent communicate using the onmessage event handler and postMessage() method. Here we’re using the onmessage event handler to listen to messages from the parent script. Once we get a message, we destructure the number from the data attribute of the event. Next, we get the current time and start the computation. Once the result is ready, we use the postMessage() method to post the results back to the parent script.

Open up src/index.js let’s make some changes.

...  const worker = new window.Worker("src/fib-worker.js");  btn.addEventListener("click", (e) => {   errPar.textContent = "";   const num = window.Number(input.value);   if (num < 2) {     errPar.textContent = "Please enter a number greater than 2";     return;   }    worker.postMessage({ num });   worker.onerror = (err) => err;   worker.onmessage = (e) => {     const { time, fibNum } = e.data;     const resultDiv = document.createElement("div");     resultDiv.innerHTML = textCont(num, fibNum, time);     resultDiv.className = "result-div";     resultsContainer.appendChild(resultDiv);   }; });

The first thing to do is to create the web worker using the Worker constructor. Then inside our button’s event listener, we send a number to the worker using worker.postMessage({ num }). After that, we set a function to listen for errors in the worker. Here we simply return the error. You can certainly do more if you want, like showing it in DOM. Next, we listen for messages from the worker. Once we get a message, we destructure time and fibNum, and continue the process of showing them in the DOM.

Note that inside the web worker, the onmessage event is available in the worker’s scope, so we could have written it as self.onmessage and self.postMessage(). But in the parent script, we have to attach these to the worker itself.

In the screenshot below you would see the web worker file in the sources tab of Chrome Dev Tools. What you should notice is that the UI stays responsive no matter what number you enter. This behavior is the magic of web workers.

We’ve made a lot of progress with our web app. But there’s something else we can do to make it better. Our current implementation uses a single worker to handle every computation. If a new message comes while one is running, the old one gets replaced. To get around this, we can create a new worker for each call to calculate the FN. Let’s see how to do that in the next section.

Working With Multiple Web Workers

Currently, we’re handling every request with a single worker. Thus an incoming request will replace a previous one that is yet to finish. What we want now is to make a small change to spawn a new web worker for every request. We will kill this worker once it’s done.

Open up src/index.js and move the line that creates the web worker inside the button’s click event handler. Now the event handler should look like below.

btn.addEventListener("click", (e) => {   errPar.textContent = "";   const num = window.Number(input.value);    if (num < 2) {     errPar.textContent = "Please enter a number greater than 2";     return;   }    const worker = new window.Worker("src/fib-worker.js"); // this line has moved inside the event handler   worker.postMessage({ num });   worker.onerror = (err) => err;   worker.onmessage = (e) => {     const { time, fibNum } = e.data;     const resultDiv = document.createElement("div");     resultDiv.innerHTML = textCont(num, fibNum, time);     resultDiv.className = "result-div";     resultsContainer.appendChild(resultDiv);     worker.terminate() // this line terminates the worker   }; });

We made two changes.

  1. We moved this line const worker = new window.Worker("src/fib-worker.js") inside the button’s click event handler.
  2. We added this line worker.terminate() to discard the worker once we’re done with it.

So for every click of the button, we create a new worker to handle the calculation. Thus we can keep changing the input, and each result will hit the screen once the computation finishes. In the screenshot below you can see that the values for 20 and 30 appear before that of 45. But I started 45 first. Once the function returns for 20 and 30, their results were posted, and the worker terminated. When everything finishes, we shouldn’t have any workers on the sources tab.

We could end this article right here, but if this were a react app, how would we bring web workers into it. That is the focus of the next section.

Web Workers In React

To get started, create a new react app using CRA. Copy the fib-worker.js file into the public/ folder of your react app. Putting the file here stems from the fact that React apps are single-page apps. That’s about the only thing that is specific to using the worker in a react application. Everything that follows from here is pure React.

In src/ folder create a file helpers.js and export the ordinal_suffix() function from it.

// src/helpers.js  export const ordinal_suffix = (num) => {   // 1st, 2nd, 3rd, 4th, etc.   const j = num % 10;   const k = num % 100;   switch (true) {     case j === 1 && k !== 11:       return num + "st";     case j === 2 && k !== 12:       return num + "nd";     case j === 3 && k !== 13:       return num + "rd";     default:       return num + "th";   } };

Our app will require us to maintain some state, so create another file, src/reducer.js and paste in the state reducer.

// src/reducers.js  export const reducer = (state = {}, action) => {   switch (action.type) {     case "SET_ERROR":       return { ...state, err: action.err };     case "SET_NUMBER":       return { ...state, num: action.num };     case "SET_FIBO":       return {         ...state,         computedFibs: [           ...state.computedFibs,           { id: action.id, nth: action.nth, loading: action.loading },         ],       };     case "UPDATE_FIBO": {       const curr = state.computedFibs.filter((c) => c.id === action.id)[0];       const idx = state.computedFibs.indexOf(curr);       curr.loading = false;       curr.time = action.time;       curr.fibNum = action.fibNum;       state.computedFibs[idx] = curr;       return { ...state };     }     default:       return state;   } };

Let’s go over each action type one after the other.

  1. SET_ERROR: sets an error state when triggered.
  2. SET_NUMBER: sets the value in our input box to state.
  3. SET_FIBO: adds a new entry to the array of computed FNs.
  4. UPDATE_FIBO: here we look for a particular entry and replaces it with a new object which has the computed FN and the time taken to compute it.

We shall use this reducer shortly. Before that, let’s create the component that will display the computed FNs. Create a new file src/Results.js and paste in the below code.

// src/Results.js  import React from "react";  export const Results = (props) => {   const { results } = props;   return (     <div id="results-container" className="results-container">       {results.map((fb) => {         const { id, nth, time, fibNum, loading } = fb;         return (           <div key={id} className="result-div">             {loading ? (               <p>                 Calculating the{" "}                 <span className="bold" id="nth">                   {nth}                 </span>{" "}                 Fibonacci number...               </p>             ) : (               <>                 <p id="timer">                   Time: <span className="bold">{time} ms</span>                 </p>                 <p>                   <span className="bold" id="nth">                     {nth}                   </span>{" "}                   fibonnaci number:{" "}                   <span className="bold" id="sum">                     {fibNum}                   </span>                 </p>               </>             )}           </div>         );       })}     </div>   ); };

With this change, we start the process of converting our previous index.html file to jsx. This file has one responsibility: take an array of objects representing computed FNs and display them. The only difference from what we had before is the introduction of a loading state. So now when the computation is running, we show the loading state to let the user know that something is happening.

Let’s put in the final pieces by updating the code inside src/App.js. The code is rather long, so we’ll do it in two steps. Let’s add the first block of code.

import React from "react"; import "./App.css"; import { ordinal_suffix } from "./helpers"; import { reducer } from './reducer' import { Results } from "./Results"; function App() {   const [info, dispatch] = React.useReducer(reducer, {     err: "",     num: "",     computedFibs: [],   });   const runWorker = (num, id) => {     dispatch({ type: "SET_ERROR", err: "" });     const worker = new window.Worker('./fib-worker.js')     worker.postMessage({ num });     worker.onerror = (err) => err;     worker.onmessage = (e) => {       const { time, fibNum } = e.data;       dispatch({         type: "UPDATE_FIBO",         id,         time,         fibNum,       });       worker.terminate();     };   };   return (     <div>       <div className="heading-container">         <h1>Computing the nth Fibonnaci number</h1>       </div>       <div className="body-container">         <p id="error" className="error">           {info.err}         </p>          // ... next block of code goes here ... //          <Results results={info.computedFibs} />       </div>     </div>   ); } export default App;

As usual, we bring in our imports. Then we instantiate a state and updater function with the useReducer hook. We then define a function, runWorker(), that takes a number and an ID and sets about calling a web worker to compute the FN for that number.

Note that to create the worker, we pass a relative path to the worker constructor. At runtime, our React code gets attached to the public/index.html file, thus it can find the fib-worker.js file in the same directory. When the computation completes (triggered by worker.onmessage), the UPDATE_FIBO action gets dispatched, and the worker terminated afterward. What we have now is not much different from what we had previously.

In the return block of this component, we render the same HTML we had before. We also pass the computed numbers array to the <Results /> component for rendering.

Let’s add the final block of code inside the return statement.

        <div className="input-div">           <input             type="number"             value={info.num}             className="number-input"             placeholder="Enter a number"             onChange={(e) =>               dispatch({                 type: "SET_NUMBER",                 num: window.Number(e.target.value),               })             }           />           <button             id="submit-btn"             className="btn-submit"             onClick={() => {               if (info.num < 2) {                 dispatch({                   type: "SET_ERROR",                   err: "Please enter a number greater than 2",                 });                 return;               }               const id = info.computedFibs.length;               dispatch({                 type: "SET_FIBO",                 id,                 loading: true,                 nth: ordinal_suffix(info.num),               });               runWorker(info.num, id);             }}           >             Calculate           </button>         </div>

We set an onChange handler on the input to update the info.num state variable. On the button, we define an onClick event handler. When the button gets clicked, we check if the number is greater than 2. Notice that before calling runWorker(), we first dispatch an action to add an entry to the array of computed FNs. It is this entry that will be updated once the worker finishes its job. In this way, every entry maintains its position in the list, unlike what we had before.

Finally, copy the content of styles.css from before and replace the content of App.css.

We now have everything in place. Now start up your react server and play around with some numbers. Take note of the loading state, which is a UX improvement. Also, note that the UI stays responsive even when you enter a number as high as 1000 and click “Calculate”.

Note the loading state and the active worker. Once the 46th value is computed the worker is killed and the loading state is replaced by the final result.

Conclusion

Phew! It has been a long ride, so let’s wrap it up. I encourage you to take a look at the MDN entry for web workers (see resources list below) to learn other ways of using web workers.

In this article, we learned about what web workers are and the sort of problems they’re meant to solve. We also saw how to implement them using plain JavaScript. Finally, we saw how to implement web workers in a React application.

I encourage you to take advantage of this great API to deliver a better experience for your users.

Further Resources

Articles on Smashing Magazine — For Web Designers And Developers

2-adobe-tips-for-managing-design-systems
28 May

Tips For Managing Design Systems

by TBSCategories: News

Tips For Managing Design Systems

Tips For Managing Design Systems

Nick Babich

(This is a sponsored article.) A design system enables a product team to create a product faster by making the design reusable. But quite often, despite everyone’s best intentions, all the effort that a product team puts into making a thoughtful design system can go straight down the drain.

Nowadays, there’s no shortage of articles explaining what a design system is and how to create one. However, there’s still a lack of practical recommendations on how to manage a design system.

Let’s fill this gap. In this article, I’ll talk about things you can do to set up your organization for long-term success with your design system.

1. Encourage Adoption Of Your Design System

More important than building a design system is encouraging everyone to use it. A design system sets a new direction for an organization, and whether the organization accepts this direction will largely depend on how people react to the changes. Depending on the size of the company, encouraging people to adopt a single design system can be a tall order. People will be happy to adopt the system only when they find it to be valuable.

Here is what you need to do to get your organization to follow the direction you’ve established with the design system.

Create A Vision Statement

Where are we going? What do we want to achieve? Why do we want to achieve that? Those are fundamental questions that you need to answer in order to build a shared vision.

A vision statement defines what your team, product or company is attempting to achieve and, more importantly, why. The vision statement will become your North Star — it will unite the team and guide it towards a common destination.

A simple technique you can use to create your vision statement is to describe what your product or organization should look like in five years. By doing that, you’ll define a target condition.

The vision statement is the answer to the question, “Where do we want to go?” (Image: UIE) (Large preview)

Establish Guiding Design Principles

How do you define good design? How do you know when something is ready to ship? When it comes to evaluating the quality of a design, designers often rely on their own set of standards. But as a team grows, following such an approach can introduce a lot of chaos in the product design process, because every designer will have their own subjective ideals. That’s where design principles can save the day.

Design principles act as standards for the product team and help them to measure their work. They replace subjective ideals with clear standards that help team members make user-centered design decisions. However, in many cases, it’s not hard to make people follow guidelines, but rather it’s hard to make people agree on guidelines. That’s why it’s essential not only to establish grounding principles of design, but also to get a commitment to those principles from the people involved in the creation of the product.

Here are a few things to remember when working on design principles:

  • Design principles should reflect the nature of the product.
    For example, when it comes to human-machine interface design for automobiles, the most important design principle should be “Safety first”. Every design decision should be measured for safety — the goal is to keep the driver and passengers safe.
  • Practice open discussion.
    If an organization has many design teams, then involving them in a discussion is vital. By getting their feedback on the design principles, you can adapt the principles to the needs of users.
  • Design principles should not sound like rules.
    Product creators should not feel limited or restrained. It’s important to make everyone comfortable when they do their work.

Magera Moon has written an excellent article, “Creating Etsy’s Design Principles”, that describes the process of creation.

Get Buy-In From Stakeholders

A design system won’t take off if the people who decide on funding don’t buy into it. You need to get buy-in from executives to fund the system.

Write a strategy with a clear proposal, and pitch it to key decision-makers. Your goal is to show that the system solves real problems. Identify key pain points — areas where people spend much time (especially routine operations), and pitch a presentation (or series of presentations) to show how the design system can save the day.

Quick tip: Wrap your presentation in the form of a story. By telling success stories, you will have a better chance of engaging stakeholders.

Promote Your Design System

You can create the best design system in the world, but if you don’t actively promote it in your organization, the entire effort will suffer greatly. That’s why, from the first release of your system, you need to work hard to foster its adoption and create a community of supporters.

Evangelize the design system. Create a group of volunteers, led by senior designers, who will pitch and sell ideas about your design system. The evangelists should participate in various activities such as workshops and webinars. The goal of all of those activities should be to raise awareness that the system exists and to educate people on how to use it.

Show Value Through A Sandbox Environment

It’s well known that the best way for people to see value is to experience it. So, create a sandbox environment that will allow product team members to quickly prototype apps using your design system. Using Adobe XD, it’s easy to create an environment that empowers people to experiment with their own ideas. Actually, it’s a two-step process.

First, you need to teach people how to build things using XD. The XD team has prepared a series of tutorials to familiarize people with the basics of Adobe XD.

Secondly, you need to set a solid foundation for your design system. Again, you don’t need to start from scratch. Ole Fredrik Lie has made a UI kit especially for design systems: Semantic UI Kit (download the ZIP file). The kit includes all of the basic components you need to start designing at scale, such as buttons, inputs, search, tabs and more.

Semantic UI Kit for Adobe XD. (Large preview)

2. Establish A Culture Of Communication

Every team member should use the design system on a regular basis. In doing so, team members will learn to solve problems systematically, not individually. Communication plays a key role in this process. Invest in creating a culture of communication early in the process, because it will increase the likelihood of adoption of the design system.

Shared Language

Language is fundamental to collaboration. The design language needs to be shared among the people involved in the creation of the product. A shared language allows team members to follow the same approach when giving names to new components and interface elements and when referring to existing components in conversation.

Communicate Changes

Once the design system is being used in product design, it’s vital to communicate changes and updates to the entire organization. Ship updates regularly and with a changelog. The log should tell users what changes were introduced in the new version and how upgrades will impact their work.

Release notes in the Salesforce’s Lightning Design System. (Large preview)

Open Channels For Getting Updates

Bake communication channels into the team’s daily workflow. This will help to keep both the design system’s users and makers engaged.

Start simple. Create a trigger for the update — whenever someone pushes updates to the design system, send a notification to your Slack channel, announcing to the team that a change has been proposed. Also, make an effort to be available via Slack to answer questions.

Establish A Practice Of Regular Checkups

In addition to a day-to-day conversation between the design system’s makers and users, it’s worth scheduling regular meetings to review the design system with makers, users and stakeholders. Discuss what works and what does not, what needs to be improved and when. The meetings will help you set priorities and create a roadmap to improve the system so that it better serves the needs of the business.

3. Improve Design Efficiency

Reduce Duplication Of Design Elements

Duplication of design elements leads to fragmentation, and fragmentation leads to inconsistency. Identifying duplication of design elements helps a team to avoid the scenario in which team members build an element from scratch and after a while find out that a version of it already exists.

Conducting an interface inventory, as described by Brad Frost, is a popular way to understand what’s in use. It’s worth investing time in an interface inventory even before building the actual design system, because going through this process will enable you to identify problem areas that need attention and help you to understand how much design debt your team has.

Interface inventory in action. Image: Brad Frost. (Large preview)

Analyze How People Use Your Design System

Similar to any other product you design, you need to find the answer to the following question: Who will use your design system, and how will they use it? Conduct research to find the answer to this question.

If you’ve just started incorporating a design system into your organization’s design process, conduct a series of interviews to understand how people use it. By doing that, you can pinpoint problems ahead of time. Try to make time for in-person feedback sessions, because such sessions will give you more insight than you would get with remote interviews or online surveys.

It’s also recommended to conduct user journey mapping. User journey mapping helps you better understand the user’s experience.

Strive To Create Reusable Components

Many design systems suffer from the same problem: Team members create components that are too focused on a single use case. As a result, the system becomes too inflexible, and its users (designers and developers) have to create their own components each time they need to cover a particular scenario.

A successful design system is highly reusable. Take Bootstrap. Because it was architected with reusability in mind, thousands of websites use it as their foundation.

Bootstrap framework. (Large preview)

Try to develop components that are not tied to a single use case, but can be reused in multiple contexts. To be reusable and scalable, components need to be the following:

  • Modular
    Modular components are self-contained — they don’t have any dependencies.
  • Composable
    It’s possible to combine components to create new components.
  • Customizable
    It’s possible to adjust and extend components to make them work in a variety of contexts.

Every time you want to introduce a new component, consider how it will work on the various platforms you are designing for. Ideally, every component you design should work on all platforms.

Introduce Versioning

Versioning makes it much easier to track changes. With versioned releases, users can reference a specific version as a dependency. They also have control over when and how upgrades to new versions are handled.

Versioning also helps you deal with breaking changes — situations where changes to a component’s code break existing usages of that component.

There are two types of versioning:

  • Versioning the entire system
    Here, everything within the system belongs to just one version number. As users, we deal with versioning for the whole system every time we update our mobile OS — when we update iOS, we’re updating the entire piece of software. Following the same approach for a design system will mean that users will have to update everything within the design system during the update. For example, if you changed a primary font, add a new secondary color or deprecate a particular UI element, when a user of the design system chooses to upgrade, they will get all of those changes together.
  • Versioning by modules
    This type of versioning involves having a version number for every component or style within the design system. Compared with versioning the entire system, versioning by module allows for more flexibility — users can choose to upgrade just the elements they need.

Establish A Clear Governance Strategy

Change is the only constant, as they say. Creating a clear governance strategy is essential to making sure your design system can adapt to changes. A robust governance strategy starts by answering some critical questions about how changes are handled, such as:

  • Who approves changes to the design system?
  • How are requests for new components handled?
  • What happens when bugs are found in the design system?

The organization of a design system is really important to its scalability. In his article, “Team Models for Scaling a Design System”, Nathan Curtis describes the three models:

  • Solitary model
    In this model, an “overlord” rules the design system.

    In the solitary model, the one team make a system available. Image: Nathan Curtis. (Large preview)
  • Centralized model
    In this model, one team is in charge of the system and guides its evolution.

    A single, central design team produces and supports a system used by others. Image: Nathan Curtis. (Large preview)
  • Federated model
    In this model, several people from several teams are in charge of the system.
    Designers from multiple product teams work on the system together. Image: Nathan Curtis. (Large preview)

Each of the models above has strengths and weaknesses, but the first is the most fragile because it has a built-in risk — when one person is in charge of so much, that person can quickly become a bottleneck to the completion of many tasks. As Nathan Curtis mentions in his article, overlords don’t scale. That’s why many teams are moving away from the solitary model to the centralized or federated model — those models are usually much better for scaling the design system.

In many cases, it’s possible to try a combination of models. For instance, the Salesforce team’s model is a combination of the centralized and federated models. Though Salesforce’s Lightning Design System has a core team, there are also contributors who act as a federation of practitioners.

Salesforce uses a hybrid of two models. Image: Jina Anne. (Large preview)

Find The Right Balance Between Strictness And Flexibility

One of the main goals of a design system is to extend creative direction. The system should give designers and developers the freedom to explore various approaches before they select one to follow.

It’s vital that the system does not prevent designers from exploring different styles. In her book, Alla Kholmatova defines two types of design systems:

  • Strict
    Designers and developers have to follow a rigorous process when introducing a new pattern in a system.
  • Loose
    The system acts as a framework, allowing designers and developers to experiment and try various approaches.

You have to find the right balance between the two extremes.

Cross-Functional Collaboration

Design is a team sport, and creating a design system is no exception. You need more than just designers to create an efficient design system. The expertise and creative energy of cross-functional collaboration will help you create a system that works best for your organization’s needs.

Product managers, project managers, executives and other stakeholders have unique perspectives that can undoubtedly inform and shape the work.

Here is a quick list of disciplines you’ll need to involve in the process of creating and managing the system:

  • Front-end development
    Front-end developers review the code and rework it to make it modular.
  • Back-end development
    Back-end engineers help to identify architectural decisions that could affect the front-end UI.
  • Content management
    Content strategists set the voice and tone of the design system.
  • UX research
    Researchers understand the needs of your users and help to bake those needs into the system.
  • Performance testing
    Performance engineers help you to avoid performance degradation. Leadership
    Leaders align the vision throughout the company.

At the same time, it doesn’t mean that every discipline should be constantly involved in developing the system. Cross-discipline exploration is better. Conduct cross-team sprints: Create teams of people from different teams, and have them work together and explore different areas of design and development. Such activities will help them to find common problems that many teams think are important and to propose solutions — in other words, users of the design system will tailor the system to their own needs.

Ship Early And Often

As with regular products, the waiting time for updates plays a key role in adoption of the design system. Practice regular incremental releases, rather than big reveals, and work hard to integrate the components into the products as soon as possible.

To make that happen, define clear timelines for new components, code reviews and other procedures.

Test Your Design Decisions

Some product teams believe that once a design system is built, the work is complete. Not true. A design system is a product, and it’s vital to manage it as a product instead of a project — a designs system requires ongoing maintenance and improvements as needs arise.

It’s essential to test the design system and the products that use it. When you test the design system, you will become confident that you have a solid foundation for your design.

If you’re just starting to introduce the design system into your design process, start small and test the foundation of the system before extending to larger parts. Find a pilot project — rebuild a real part of a product using this new approach — and see whether it works for your team.

Here are three types of testing that will help you:

  • Functional testing
  • Visual regression testing
    Visual regression testing help you to catch unintended visual changes to component styles.
  • Manual and automated accessibility testing
    This ensures that your components are accessible.

Measure Progress

Assess how effective your design system is at achieving your goals. Define key metrics, and track them with each release.

4. Invest In Documentation

A well-crafted design system is an excellent tool. But even more important than having a great tool is knowing how to use it properly. Documentation is key to adoption.

Write Documentation To Make It Crystal Clear

Minimize jargon and specific terms. Write the documentation in simple, human-readable sentences so that everyone on the team can understand it. This decision will also save a lot of time when onboarding new team members.

Keep Documentation Up To Date

If some part of the system is not documented, it doesn’t exist. When some elements of the design system go undocumented, you run the risk of duplicating elements. Thus, try to keep documentation up to date with your system’s code by automating documentation — the documentation should be automatically updated when a component changes. This should include both visual references and code samples.

Good Findability Of Information

Prioritize sections with information in the documentation, and make sure search works fine. The structure you choose should follow the pattern that users follow when browsing the documentation.

Users should be able to find what they’re looking for themselves and not have to ping other people to find it.

Bake Best Practices Into The Documentation

When best practices — such as accessibility, performance, ergonomics and so on — are baked into the system, it becomes much easier for users to apply them.

Shopify’s Polaris design system has sections with best practices. (Large preview)

Conclusion

Incorporating a system into a design culture takes a lot of time; it’s a gradual process. And the way you manage the design system plays a vital role in its adoption. A successful design system needs to become part of the organization’s DNA, helping your team produce more consistent user experiences, building bridges between design and development, and improving your design process without exposing your orgchart.

This article is part of the UX design series sponsored by Adobe. Adobe XD tool is made for a fast and fluid UX design process, as it lets you go from idea to prototype faster. Design, prototype and share — all in one app. You can check out more inspiring projects created with Adobe XD on Behance, and also sign up for the Adobe experience design newsletter to stay updated and informed on the latest trends and insights for UX/UI design.

Smashing Editorial (ms, yk, il, al)


Articles on Smashing Magazine — For Web Designers And Developers

logo-red-2
03 Apr

Managing Z-Index In A Component-Based Web Application

by TBSCategories: News

Managing Z-Index In A Component-Based Web Application

Managing Z-Index In A Component-Based Web Application

Pavel Pomerantsev

If you’ve done any complex web UI development, you must have at least once furiously tried driving an element’s z-index up to thousands, only to see that it’s not helping position it on top of some other element, whose z-index is lower or even not defined at all.

Why does that happen? And more importantly, how to avoid such issues?

In this article, I’ll recap what z-index actually is and how you can stop guessing whether it might work in any specific case and start treating it just like any other convenient tool.

The Hierarchy Of Stacking Contexts

If you imagine the webpage as having three dimensions, then z-index is a property that defines the z coordinate of an element (also called its “stacking order”): the larger the value, the closer the element is to the observer. You can also think of it as a property affecting paint order, and this will in fact be more correct since the screen is a two-dimensional grid of pixels. So, the larger the z-index value, the later the element is painted on the page.

There is, however, one major complication. The z-index value space is not flat — it’s hierarchical. An element can create a stacking context which becomes the root for z-index values of its descendants. It would be best to explain the concept of stacking contexts by using an example.

The document body has five div descendants: div1, div2, div3, div1-1, and div2-1. They’re all absolutely positioned and overlap with each other. div1-1 is a child of div1, and div2-1 is a child of div2.

See the Pen stacking-contexts by Pavel Pomerantsev.

Let’s try to understand why we see what we see. There are quite elaborate rules to determine paint order, but here we only need to compare two things:

  • z-index Values
    If an element has a higher z-index, it’s painted later.
  • Source Order
    If z-index values are the same, then the later it’s in the source, the later it’s painted.

So if we don’t take stacking contexts into account, the order should be as follows:

  • div1
  • div2
  • div3
  • div1-1
  • div2-1

Note that div2-1 is in fact overlapped by div3. Why is that happening?

If an element is said to create a stacking context, it creates a basis for its children’s z-index values, so they’re never compared with anything outside the stacking context when determining paint order. To put it another way, when an element creating a stacking context is painted, all its children are painted right after it and before any of its siblings.

Going back to the example, the actual paint order of body’s descendant divs is:

  • div1
  • div2
  • div3
  • div1-1

Notice the absence of div2-1 in the list — it’s a child of div2 which creates a stacking context (because it’s an absolutely positioned element with a z-index other than the default value of auto), so it’s painted after div2, but before div3.

div1 doesn’t create a stacking context, because its implicit z-index value is auto, so div1-1 (its child) is painted after div2 and div3 (since its z-index, 10, is larger than that of div2 and div3).

Don’t worry if you didn’t fully grasp this on first reading. There’s a bunch of online resources that do a great job in explaining these concepts in more detail:

Note: It’s also great to be familiar with general paint order rules (which are actually quite complex).

The main point of this piece, however, is how to deal with z-index when your page is composed of dozens and hundreds of components, each potentially having children with z-index defined.

One of the most popular articles on z-index proposes grouping all z-index values in one place, but comparing those values doesn’t make sense if they don’t belong to the same stacking context (which might not be easy to achieve in a large application).

Here’s an example. Let’s say we have a page with header and main sections. The main section for some reason has to have position: relative and z-index: 1.

See the Pen z-index-step1 by Pavel Pomerantsev.

We’re using a component architecture here, so CSS for the root component and every child component is defined in dedicated sections. In practice, components would live in separate files, and the markup would be generated using a JavaScript library of your choice, like React, but for demonstration purposes it’s fine to have everything together.

Now, imagine we’re tasked with creating a dropdown menu in the header. It has to be stacked on top of the main section, of course, so we’ll give it a z-index of 10:

See the Pen z-index-step2 by Pavel Pomerantsev.

Now, a few months later, in order to make something unrelated work better, we apply the translateZ hack to the header.

See the Pen z-index-step3 by Pavel Pomerantsev.

As you can see, the layout is now broken. An element with z-index: 1 sits on top of an element with z-index: 10, in the absence of any other z-index rules. The reason is that the header now creates a stacking context — it’s an element with a transform property whose value is anything other than none (see full rules) and its own z-index (0 by default) is lower than that of the main section (1).

The solution is straightforward: give the header a z-index value of 2, and it’ll be fixed.

See the Pen z-index-step4 by Pavel Pomerantsev.

The question is, how are we supposed to come to this solution if we have components within components within components, each having elements with different z-indices? How can we be sure that changing z-index of the header won’t break anything else?

The answer is a convention that eliminates the need for guesswork, and it’s the following: changing z-indices within a component should only affect that component, and nothing else. To put it differently, when dealing with z-index values in a certain CSS file, we should ideally only concern ourselves with other values in that same file.

Achieving it is easy. We should simply make sure that the root of every component creates a stacking context. The easiest way to do it is to give it position and z-index values other than the default ones (which are static and auto, respectively).

Here’s one of the ways to structure the application. It uses more elements than the previous one, but computation associated with extra DOM elements is cheap whereas developer’s time (a lot of which can sometimes be spent on debugging stacking issues) is definitely not.

See the Pen z-index-step5 by Pavel Pomerantsev.

  • header__container and main__container both have position: relative and z-index: 0;
  • header__overlay now has z-index: 1 (we don’t need a large value since it’s only going to compete for stacking order with other elements within the header);
  • root__header now has z-index: 2, whereas root__main keeps its z-index: 1, and this is what makes the two siblings stack correctly.

(Note also that both have position: relative since z-index doesn’t apply to statically positioned elements.)

If we look at the header code now, we’ll notice that we can remove the z-index property from both the container and the overlay altogether because the overlay is the only positioned element there. Likewise, the z-index is not required on the main container. This is the biggest benefit of the proposed approach: when looking at z-indices, it’s only the component itself that matters, not its context.

See the Pen z-index-step6 by Pavel Pomerantsev.

Such an architecture is not without its drawbacks. It makes the application more predictable at the expense of some flexibility. For example, you won’t be able to create such overlays inside both the header and the main section:

See the Pen z-index-step7 by Pavel Pomerantsev.

In my experience, however, this is rarely a problem. You could make the overlay in the main section go down instead of up, in order for it to not intersect with the header. Or, if you really needed it to go up, you could inject the overlay HTML at the end of the body and give it a large z-index (“large” being whatever’s larger than those of other sections at the top level). In any case, if you’re not in a competition to build the most complicated layout, you should be fine.

To recap:

  • Isolate components in terms of z-index values of elements by making the root of each component a stacking context;
  • You don’t have to do it if no element within a component needs a z-index value other than auto;
  • Within a component’s CSS file, maintain z-index values any way you like. It might be consecutive values, or you could give them a step of 10, or you can use variables — it all depends on your project’s conventions and the size of the component (although making components smaller is never a bad thing). Preferably, only assign z-index to sibling elements. Otherwise, you may inadvertently introduce more stacking contexts within a component, and you’re faced with the same issue again, luckily on a smaller scale;
  • Debugging becomes easy. Find the first ancestor component of the two elements that are not stacked correctly, and change z-indices within that component as necessary.

This approach will hopefully bring back some sanity to your development process.

Smashing Editorial (dm, ra, il)


Articles on Smashing Magazine — For Web Designers And Developers


Deprecated: Function create_function() is deprecated in /home2/thebrand/public_html/wp-content/plugins/wp-spamshield/wp-spamshield.php on line 1884
logo-red-9
14 Feb

Managing Image Breakpoints With Angular

by TBSCategories: News

Managing Image Breakpoints With Angular

Managing Image Breakpoints With Angular

Tamas Piros

As web developers, we are often required to create applications that are responsive as well as media-rich. Having such requirements in place means that we need to work with image breakpoints, as well as media queries since we want to provide the best experience to the end users. Adding to the list of requirements we may need to use a front-end framework such as Angular which is great for creating SPAs and other application types.

In this article, we’ll take a look at image breakpoints, their use-cases and throughout a hands-on example; we’ll implement them in an Angular application using Angular’s own BreakPoint Observer. While using this approach, we’ll also highlight why this popular framework helps us work with the aforementioned techniques in a seamless way.

Image Breakpoints And Responsive Images

In the era of responsive layouts (where we capture breakpoints based on the viewport size and based on the breakpoint we change the layout of the page), we also need to make sure that images can be displayed with the right dimensions — even after a layout change. Selecting the right image is quite challenging for modern responsive websites.

Let’s discuss two options that developers can utilize at the moment.

srcset

srcset lets us define a list of images that the browser switches between based on the rendered <img> size and the density of the display.

Let’s take a look at an example:

<img   srcset="tuscany-sm.jpg 600w, tuscany-md.jpg 900w, tuscany-lg.jpg 1440w" sizes="100vw"   src="tuscany.jpg" />

In the above, we specify 3 images, with the w indicating the pixel width for the image. When using the above with srcset we also need to specify the sizes attribute (this is required because the spec mandates that if we use srcset and w we must have a sizes attribute as well). What is the purpose of this attribute? Browsers need to pick which resource to load out of a source set before they layout the page (before they know how big the image will end up being). We can think of sizes as a hint to the browser that, after layout, the image will occupy 100% of the width of the viewport (that’s what vw refers to). The browser knows the actual viewport width (as well as the DPR of the image) at load-time, so it can do the math to figure out what size resource it needs and pick one out of the source set.

The <picture> and <source media=""> element combinations let us switch out image resources in response to media queries, like the ones at layout breakpoints.

Let’s take a look at an example of this as well:

<picture>     <source media="(min-width: 1440px)" srcset="../assets/images/tuscany-lg.jpg">     <source media="(min-width: 900px)" srcset="../assets/images/tuscany-md.jpg">     <source media="(min-width: 600px)" srcset="../assets/images/tuscany-sm.jpg">     <img src="../assets/images/tuscany-sm.jpg" />   </picture>

Change the code above locally with an image of your choice that has a small, medium and large size. Notice how, by resizing the browser, you get a different image.

The key takeaway from all the above is that if we want to swap out images at specific breakpoints, we can use the <picture> element to put media queries right into the markup.

Note: If you’re interested in exploring the differences between <picture> and srcset + sizes, I recommend reading Eric Portis’ great article: srcset and sizes.

So far we have discussed how to use image breakpoints along with media queries in a pure HTML environment. Wouldn’t it be a lot better to have a convenient, almost semi-automated way of generating image breakpoints as well as the corresponding images for the breakpoints even without having to specify media queries at all? Luckily for us Angular has a built-in mechanism to help us out and we’ll also take a look at generating the appropriate images dynamically based on certain conditions by using a third-party service.

Angular Layout Module

Angular comes with a Layout Module which lives in the CDK (Component Dev Kit) toolset. The Angular CDK contains well-tested tools to aid with component development. One part of the CDK is the Layout Module which contains a BreakpointObserver. This helper gives access to media-query breakpoints, meaning that components (and their contents) can adapt to changes when the browser size (screen size) is changed intuitively.

Recommended reading: Layout Module

Now that we have the theory out of the way let’s get down to business and create an application that will implement responsive image breakpoints. In this first iteration, we’ll create the shell of the application via the Angular CLI: ng new bpo and select the necessary options.

To use the BreakpointObserver we also need to install the Angular’s CDK Layout Module, which we can do via npm: npm i @angular/cdk.

After the installation, we will be able to add the necessary import statements to any component that we wish:

// app.component.ts import { BreakpointObserver, Breakpoints } from '@angular/cdk/layout';

Using the BreakpointObserver we can subscribe to changes in the viewport width and Angular gives us convenient accessors which mean that we don’t need to use media queries at all! Let’s go ahead and try this out:

// app.component.ts constructor(public breakpointObserver: BreakpointObserver) { }  ngOnInit() {     this.breakpointObserver.observe([       Breakpoints.XSmall,       Breakpoints.Small,       Breakpoints.Medium,       Breakpoints.Large,       Breakpoints.XLarge     ]).subscribe(result => {       if (result.breakpoints[Breakpoints.XSmall]) {        // handle XSmall breakpoint       }       if (result.breakpoints[Breakpoints.Small]) {        // handle Small breakpoint       }       if (result.breakpoints[Breakpoints.Medium]) {       // handle Medium breakpoint       }       if (result.breakpoints[Breakpoints.Large]) {         // handle Large breakpoint       }       if (result.breakpoints[Breakpoints.XLarge]) {         // handle XLarge breakpoint       }     });   }

As mentioned before the accessor properties above reflect media queries in the following way:

  • Breakpoints.XSmall: max-width = 599.99px
  • Breakpoints.Small: min-width = 600px and max-width = 959.99px
  • Breakpoints.Medium: min-width = 960px and max-width = 1279.99px
  • Breakpoints.Large: min-width = 1280px and max-width = 1919.99px
  • Breakpoints.XLarge: min-width = 1920px

We now have everything in place which means, we can start to generate the appropriate images.

Responsive Breakpoints For Images

We have a few options to generate responsive images:

  1. Responsive Image Breakpoints Generator
    Using this tool, we can upload any image, setup various options, e.g. the number of images that we wish to generate. After running the tool, we’ll have a visual representation about the generated images, and we can download them as a zip file along with some generated code which uses the previously mentioned <picture> element.
  2. Another solution would be to create a build step for our project to generate breakpoints via some packages available in the NPM repository, such as gulp-responsive or grunt-responsive-images. Both of these depend on additional libraries that we are required to install for our operating system. (Please check the appropriate repositories for additional information.)
  3. Yet another solution would be to use a service such as Cloudinary to store the images and serve them in a size and format that we need only by modifying the URL for the requested resource. This will be our approach since this gives us the most flexibility.

Recommended reading: Automating Art Direction With The Responsive Image Breakpoints Generator by Eric Portis

I have uploaded the original image to my Cloudinary account which means that I can access that image via the following URL:

https://res.cloudinary.com/tamas-demo/image/upload/breakpoints-article/tuscany.jpg

This is the full-sized, raw, original and unchanged image that we’ll work with.

We can modify the URL of the image to generate a much smaller version. For example, if we want to have an image with a width of 600 pixels, we could update the Cloudinary URL* to be the following:

https://res.cloudinary.com/tamas-demo/image/upload/w_600/breakpoints-article/tuscany.jpg

* Note the w_600 added to the URL.

Hopefully, by this point, you see where all this is going. Based on the approach above, we can very quickly start to generate the right image for the right breakpoint.

Using Cloudinary means that we don’t need to create, store and manage multiple version of the same image — it is done for us by Cloudinary on-the-fly.

Let’s update our code:

<!-- app.component.html --> <div>   <h1>Current breakpoint: {{ breakpoint }}</h1>   <img [src]="imagePath"> </div> 
// app.component.ts import { Component, OnInit } from '@angular/core'; // ... export class AppComponent implements OnInit {   imagePath;   constructor(public breakpointObserver: BreakpointObserver) { }   ngOnInit() {     this.breakpointObserver.observe([ ...   } }

We can pick any number of breakpoints to observe from the list mentioned previously, and since we have an Observer we can subscribe to the changes and act on them:

this.breakpointObserver.observe([   Breakpoints.XSmall,   Breakpoints.Small,   Breakpoints.Medium,   Breakpoints.Large,   Breakpoints.XLarge ]).subscribe(result => {   if (result.breakpoints[Breakpoints.XSmall]) {     // handle this case   } });

To handle the options for the different images in Cloudinary, we’ll utilize an approach that will be very easy to follow. For each case, we’ll create an options variable and update the final Cloudinary URL.

Add the following at the top of the component definition:

// app.component.ts imagePath;   breakpoint;   cloudinaryOptions;   baseURL = 'https://res.cloudinary.com/tamas-demo/image/upload/breakpoints-article/tuscany.jpg';

And add the following as well to the first if statement:

// app.component.ts let url = this.baseURL.split('/'); let insertIndex = url.indexOf('upload'); const options = 'c_thumb,g_auto,f_auto,q_auto,w_400'; url.splice(insertIndex + 1, 0, options); this.imagePath = url.join('/'); this.breakpoint = Breakpoints.XSmall;

The result is going to be an updated Cloudinary URL:

https://res.cloudinary.com/tamas-demo/image/upload/c_thumb,g_auto,f_auto,q_auto,w_400/breakpoints-article/tuscany.jpg

What are the options that we are setting here?

  • c_thumb (generates a thumbnail of the image);
  • g_auto (focuses on the most interesting part; we see the cathedral in the thumbnail);
  • f_auto (serves the most appropriate format for a given browser, i.e. WebP for Chrome);
  • q_auto (reduces the quality — and therefore the overall size — of the image without impacting the visuals);
  • w_400 (sets the width of the image to 400px).

For the sake of curiosity, let’s compare the original image size with this newly generated image: 2.28 MBs vs 29.08 KBs!

We now have a straightforward job: we need to create different options for different breakpoints. I created a sample application on StackBlitz so you can test it out immediately (you can also see a preview here).

Conclusion

The variety of desktop and mobile devices and the amount of media used in today’s web has reached an outstanding number. As web developers, we must be at the forefront of creating web applications that work on any device and doesn’t impact the visual experience.

There are a good number of methods that make sure the right image is loaded to the right device (or even when resizing a device). In this article, we reviewed an approach that utilizes a built-in Angular feature called BreakPoint Observer which gives us a powerful interface for dealing with responsive images. Furthermore, we also had a look at a service that allows us to serve, transform and manage images in the cloud. Having such compelling tools at our hands, we can still create immersive visual web experiences, without losing visitors.

Smashing Editorial (dm, il)


Articles on Smashing Magazine — For Web Designers And Developers


Deprecated: Function create_function() is deprecated in /home2/thebrand/public_html/wp-content/plugins/wp-spamshield/wp-spamshield.php on line 1884
sarah-drasner-opt_kaxhos
10 Jul

Pattern Library First: An Approach For Managing CSS

by TBSCategories: News

Pattern Library First: An Approach For Managing CSS

Pattern Library First: An Approach For Managing CSS

Rachel Andrew

In this article, based on the talk that I gave at Smashing Conference in Toronto, I’m going to describe a method of working that I’ve adopted over the past two years that helps me to manage CSS across my projects.

I’ll be showing you how to use the pattern library tool Fractal, to manage your CSS on a component by component basis, while allowing you to use the tools you are already familiar with. While this serves as an introduction to Fractal, and why we have selected this particular pattern library, it is likely this way of working would transfer to other solutions.

Our Projects

My company has a couple of products — Perch and Perch Runway CMS and Notist, a software as a service application for public speakers. These products are quite different, especially given that Perch is a self-hosted system and Notist is SaaS, however, they both have a lot of user interface to develop. We also have all of the associated websites and documentation for these products, plus other things that we work on such as the 24 Ways website. After discovering Fractal two years ago, we have moved every new project — large and small — into Fractal.

Problems we wanted to solve

I began investigating pattern library solutions two years ago when I started work rebuilding the Perch UI for version 3. A feature of Perch is that the templates you create for the output of content on your website become the schema of the admin UI. This means that any fieldtype used in a template needs to be able to exist alongside any other fieldtype. We don’t know how our customers might combine these, and there are a huge number of possible combinations. It’s also not a “website”, and I didn’t want to try and force the pattern library into something designed for organizing website patterns.

As Perch is self-hosted — people download it and host it on their own servers — we need to use the simplest tech stack possible in order to not place any additional barriers to entry in front of people, many of who are new to using a CMS. To add an extra level of fun, we support back to Internet Explorer 9, yet I intended to use a lot of Flexbox — as this was before Grid Layout shipped.

I was also keen to avoid using tools which came with a lot of relearning how we worked, and completely changing our process. Any additional tool or change to the way that you work on your projects brings with it new friction. You can solve one problem, but bring in a whole new set of problems if you make large changes to the way that you work. In our case, we were using Sass in a fairly limited way, and processing that using Gulp. None of our projects use a Javascript framework, we’re just writing HTML, CSS and JavaScript.

Fractal fit our needs perfectly. It is agnostic as to the way you develop or the tools you want to use. Importantly for our purposes, it didn’t assume we were building a website. The experiment was so successful that we found ourselves using Fractal for every project large or small, as it makes the process of working on CSS far more straightforward. Even small sites I create on my own often start life in Fractal, because there are more benefits than you might think in terms of working with a pattern library, and many of those benefits make as much sense for a team of one as a large team.

Before we think about how to develop using Fractal and why I think it makes sense for small projects as well as large ones, let’s take a look at how to get the environment set up.

Getting Started With Fractal

The most straightforward approach for working with Fractal is to go to the Fractal website and take a look at the Getting Started Guide. You will first need to install Fractal globally, you can then follow the steps listed here to create a new Fractal project.

With your new project installed, at the command line change into the folder you have just created and run the command:

fractal start --sync

This will start up a little server at port 3000, so you should be able to go to http://localhost:3000 in a web browser and see your project.

Now that your project is up and running, open up the project folder in your favorite text editor and find the example component under components/example. You will find a config file and a file named example.hbs. The example.hbs template is the HTML of your component, you can add some more HTML to that and Fractal will automatically reload and display it. Change the file to:

<h1>This is my heading</h1> <p>{{ text }}</p>

You should see the heading appear in the browser. The config file can be used to add content and otherwise configure your component. If you want to read your heading text out of that file then edit that file to look like the following example:

title: Example component context:     text: This is an example component!     heading: My heading

Now change your example.hbs file to read in that text.

<h1>{{ heading }}</h1> <p>{{ text }}</p>
Adding Additional Components

You can follow the pattern of the example component to add your own. At a minimum, you need a folder (the name of the component) and a .hbs file using the same name. You can add the config file if you want to set configuration options.

Components can be nested into folders to make it easier to locate particular components, and how you structure the folders is completely up to you.

Note: It is really easy to find yourself spending a lot of time worrying about how to name your components. In Fractal at least, renaming and also reorganizing components into folders is straightforward. You can rename or move them and Fractal will update to show the new structure. I find that often the ideal structure only becomes apparent as I’m developing so I don’t worry too much at the outset and then firm it up later.

Adding a CSS Workflow

So far, we are able to create HTML components as handlebars templates, and a config file to insert data, however, we haven’t added any CSS. Ideally, we want to add the CSS for each component into the same folder as the rest of the component files and then combine it all together.

I mentioned that Fractal makes very few assumptions about your workflow; due to this, it does far less out of the box than it might if it were forcing you down a particular way of working. However, we can fairly easily get Fractal working with a Gulp setup.

Combining Fractal, Sass, And Gulp

The following describes a minimal setup using Gulp and Sass to create a single output CSS file. Hopefully, you can follow this process to do anything else that you would normally do in Gulp. The key thing to note is that most of this is not Fractal specific, so once you get the Fractal part working you can add in anything else following the same patterns. If you are familiar with another build tool then it is likely that you could create a similar process; if you do, and are happy to share, let us know in the comments.

First some setup, the following will enable you to follow along with the code listed in this tutorial, the locations of your Sass files and output CSS might ultimately be different to mine. The key thing is that the output CSS file needs to be somewhere in the public folder.

  1. Inside the public folder in your Fractal install, add a folder named css.
  2. In the root folder of your Fractal, install add a folder assets inside which is a folder scss. Create a Sass file named global.scss inside that folder. Inside that file add the following line:
    @import "../../components/**/*.scss";
  3. Create a file named example.scss in your example component directory.
  4. Create gulpfile.js in the root of your Fractal project and add the below code.
'use strict';  const gulp         = require('gulp'); const fractal      = require('./fractal.js'); const logger       = fractal.cli.console; const sass         = require('gulp-sass'); const sassGlob     = require('gulp-sass-glob'); const plumber      = require('gulp-plumber'); const notify       = require('gulp-notify'); const path         = require('path');  gulp.task('sass',function() {     return gulp.src('assets/scss/**/*.scss')     .pipe(customPlumber('Error running Sass'))     .pipe(sassGlob())     .pipe(sass())     .pipe(gulp.dest('public/css')) });  gulp.task('watch', ['sass'], function() {    gulp.watch([         'components/**/*.scss',         'assets/scss/**/*.scss'         ], ['sass']); });  function customPlumber(errTitle) {     return plumber({         errorHandler: notify.onError({             title: errTitle || "Error running Gulp",             message: "Error: <%= error.message %>",         })     }); }  gulp.task('fractal:start', function(){     const server = fractal.web.server({         sync: true     });     server.on('error', err => logger.error(err.message));     return server.start().then(() => {         logger.success(`Fractal server is now running at $ {server.url}`);     }); });  gulp.task('default', ['fractal:start', 'sass', 'watch']);

I then install the dependencies listed at the top of the file. If you were to install those at the command line you would run:

npm install gulp gulp-sass gulp-sass-glob gulp-plumber gulp-notify

The sass function compiles the Sass from assets into a single file, and outputs it into the folder in public.

gulp.task('sass',function() { return gulp.src('src/assets/scss/**/*.scss') .pipe(customPlumber('Error running Sass')) .pipe(sassGlob()) .pipe(sass()) .pipe(gulp.dest('public/css')) });

I then create a watch function that will watch my Sass in assets and also that in individual components and compile it into the folder in public.

gulp.task('watch', ['sass'], function() {    gulp.watch([ 'components/**/*.scss', 'assets/scss/**/*.scss' ], ['sass']); });

That’s my CSS building. I now want to make it so that I can run gulp and it will kick off the watching of the CSS file as well as starting fractal. I do this by creating a gulp task to run the fractal start command.

gulp.task('fractal:start', function(){ const server = fractal.web.server({ sync: true }); server.on('error', err => logger.error(err.message)); return server.start().then(() => { logger.success(Fractal server is now running at $ {server.url}); }); });

Finally, I need to ensure that the Sass building and Fractal start run when I run gulp and the command line:

gulp.task('default', 'fractal:start', 'sass', 'watch');

That’s my completed gulpfile.js. If you add this into your default Fractal project, make sure the folders are in place for the paths mentioned. You should be able to go to the command line, run gulp, and Fractal will start.

Commandline output
Starting Fractal with gulp (View large version)

We can test out our Sass by adding a variable in the global.scss file; you will need to add this above the line that includes the components so that the variable is available for those components.

$ color1: rebeccapurple;

Then in example.scss add a rule for the level 1 heading we added earlier:

h1 {   color: $ color1; }

If everything is set up correctly, you should find you have a .css file in public/css which contains the rule:

h1 {   color: rebeccapurple; }

We need to do one more thing so that we can preview our components using the CSS we are building. We need to create a preview file, which will link in the stylesheet from the public folder.

Inside your components folder, create a file named _preview.hbs.

The preview file is essentially an HTML document, linking in our CSS and anything else you need to include. In the body is a tag {{ yield }}, and this is where a component will be placed.

<!doctype html> <html lang="en"> <head> 	<meta charset="utf-8" /> 	<title>Preview Layout</title> 	<meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no"> 	<link rel="stylesheet" href="{{ path '/css/global.css' }}"> </head> <body> 	{{{ yield }}} </body> </html>

Note: The public folder can also house any other assets that you need to display in components such as images, fonts and so on.

The Pattern Library As Source Of Truth

As we have seen, Fractal can build our CSS. In our projects, we make it so that Fractal is the only place we build and process CSS and other assets for the site. What this means is that our pattern library and site or application do not drift. Drift happens after you deploy the site if people start editing the CSS of the site and not bringing those changes back to the pattern library. If you can make the pattern library the place where CSS is processed then changes have to start there — which prevents drift between the live site and library.

We build everything in Fractal and then copy those public assets over to the live sites to be deployed. In addition to preventing drift between the systems, it also makes managing CSS in source control much easier. When multiple people work on one CSS file, merge conflicts can be reasonably hard to deal with. With people working on individual components in the pattern library, you can usually avoid two people committing changes to the same file at once, and if they do it is only a small file to sort out and not all of your CSS.

Using A Pattern Library First Approach For Managing Fallbacks

I have found that working pattern library first makes dealing with fallbacks in your code far more straightforward and less overwhelming than attempting to fix up a complete site or application at once. It also allows us to concentrate on the best possible case, and be creative with new techniques, rather than limit what we do due to being worried about how we will get it to work well in non-supporting browsers.

We can look at a simple case of a media object component to see how that might work. To follow along, create a media folder inside components in Fractal, and add the files media.hbs and media.scss.

Start With Good Markup

Your starting point should always be well-structured markup. In the pattern library, it may be that you will use this component with a range of markup, for example, you could use a component with content marked up as a figure in one place and just with divs in another. Your content should, however, be structured in a way that makes sense and can be read from top to bottom.

This ensures that your content is accessible at a very basic level, but it also means you can take advantage of normal flow. Normal Flow is how browsers display your content by default, with block elements progressing one after the other in the block dimension and inline elements — such as words in a sentence — running along the inline axis. For a lot of content that is exactly what you want, and by taking advantage of normal flow rather than fighting against it you make your job far easier as you create your layout.

Therefore, my component has the following markup which I add to media.hbs.

<div class="media">    <div class="img">     <img src="/img/placeholder.jpg" alt="Placeholder">   </div>   <h2 class="title">This is my title</h2>   <div class="content">       <p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Duis vehicula vitae ligula sit amet maximus. Nunc auctor neque ipsum, ac porttitor elit lobortis ac. Vivamus ultrices sodales tellus et aliquam. Pellentesque porta sit amet nulla vitae luctus. Praesent quis risus id dolor venenatis condimentum.</p>   </div>   <div class="footer">     An optional footer goes here.   </div> </div>

You can see how this then displays inside Fractal.

The fractal UI with the added component
My component after adding the markup. (View large version)

Once I’ve got the markup that I want, I am going to work on the desktop display that I have in mind. I’m going to use CSS Grid Layout and the grid-template-areas method of doing so. Add the following to media.scss.

img { max-width: 100%; }  .media > .title {    grid-area: title;  }  .media > .img {    grid-area: img;  }  .media > .content {    grid-area: bd;  }  .media > .footer {    grid-area: ft;  }  .media {   margin-bottom: 2em;   display: grid;   grid-column-gap: 20px;   grid-template-columns: 200px 3fr;   grid-template-areas:     "img title"     "img bd"     "img ft";   }

We now have a simple media object layout:

A two column layout, image on the left text on the right
The Media Object layout. (View large version)

Something you can do in Fractal is to add variations of a component. You might want to flip the media object so that the image is on the right.

Now add the CSS to media.scss in order to flip the layout:

.media.media-flip { grid-template-columns: 3fr 200px ; grid-template-areas:   "title img"   "bd img"   "ft img";   }

There are two ways to create variants: file-based and configuration based. File-based is simplest and is also useful if your variant has different markup. To create a file-based variant, make a copy of your component in the media folder with the name media –flip.hbs (that’s two dashes in the filename).

This component should have identical markup with the class media-flip added to the first line, and you will then be able to see both versions.

<div class="media media-flip">
A two column layout, image on the right text on the left
The flipped version. (View large version)

Alternately, as in this case all we need to do is add a class, you can create a variant using a config file.

If you want to do this, remove your variant file, and instead add a config file named media.config.json containing the following code:

{     "title": "Media Object",     "context": {         "modifier": "default"     },     "variants": [         {             "name": "Flipped",             "context": {                 "modifier": "flip"             }         }     ] }

Then modify the first line of media.hbs as follows:

<div class="media media-{{ modifier }}">

Note: You can add as many variants as you like (take a look at the documentation for variants to read more).

We might now think about adding some CSS to change the layout based on screen size. Wrapping the layout we have created in a media query and above that creating a single column layout for smaller devices.

img {   max-width: 100%; }  .media > .title {    grid-area: title;  }  .media > .img {    grid-area: img;  }  .media > .content {    grid-area: bd;  }  .media > .footer {    grid-area: ft;  }  .media {   display: grid;   grid-column-gap: 20px;   grid-template-areas:     "title"     "img"     "bd"     "ft";   }      @media (min-width: 600px) {     .media {       margin-bottom: 2em;       display: grid;       grid-column-gap: 20px;       grid-template-columns: 200px 3fr;       grid-template-areas:         "img title"         "img bd"         "img ft";     }      .media.media-flip {       grid-template-columns: 3fr 200px ;       grid-template-areas:         "title img"         "bd img"         "ft img";     } }
A single column layout
The object for mobile devices. (View large version)

Then, just as we manage the view for smaller devices within our component, we can manage the layout for older browsers which do not support grid.

In this case, I’m going to build a float-based fallback (this will work for pretty much any legacy browser). I’m only going to worry about it for wider screen sizes and leave the component displaying in normal flow for older mobile devices.

Just inside the media query, add the following CSS:

.media:after {   content: "";   display: table;   clear: both; }  .media > .media {   margin-left: 160px;   clear: both; }  .media .img {   float: left;   margin: 0 10px 0 0;   width: 150px; }  .media.media-flip .img {   float: right;   margin: 0 0 0 10px; }  .media > * {   margin: 0 0 0 160px; }  .media.media-flip > * {   margin: 0 160px 0 0; }

This should sort out the display in non-grid browsers. For browsers that do support grid, you don’t need to worry about floats, i.e. when the floated item becomes a grid item, the float is removed. What will be a problem are any margins. The layout in grid supporting browsers will now be all spaced out due to the extra margins.

Two column layout with big gaps
The layout is spaced out due to the extra margins. (View large version)

This is where we can add a feature query, removing the margins if we know that our browser supports grid.

@supports(display: grid) {   .media > *,   .media.media-flip > * {     margin: 0;   }    .media .img,   .media.media-flip .img {     width: auto;     margin: 0;   }      .media:after {     content: none;   } }

That’s our small component finished. While a simple example — and it might be argued that it’s one which doesn’t really need grid at all if you need to have a fallback — it demonstrates the approach I’m taking across all of my projects, large and small.

To get my CSS file into production, we can take the CSS file from the public folder and add that to our production site. You could even script this process to copy it over to your site folder as it builds.

Reduced Test Case First Development

Something I have discovered as a key benefit in working this way, is that it really does make the browser support piece of the puzzle easier. Not only is it easier to see what fallback CSS is being included with this component, but also if we are having problems with a browser, it makes it far easier to debug them.

When you are battling with a browser issue then the thing you will generally be told to do is create a reduced test case. Reduce the problem down to the smallest thing that exhibits the issue. A component in a pattern library is often very close to that reduced test case already. Certainly far closer than if you are trying to debug a problem while looking at your entire website.

In addition to making browser debugging easier, having your fallbacks included alongside the rest of the CSS makes it easier to remove the fallback code once it is no longer needed, it’s obvious this fallback code is for this component. I know that removing it won’t change the way anything else displays.

This ease of organizing our code is really why Fractal makes sense even in small projects. Given that we tend to use Gulp and Sass anyway (even on smaller projects), adding Fractal to the mix isn’t a big overhead. We don’t need to see it as only for our bigger projects, as even a small site might have a reasonable amount of CSS.

See The Code

I’ve created a GitHub Project which has all of the code mentioned in the article. I would suggest setting up Fractal as described in the article and then grabbing any bits – such as the gulpfile or preview layout, from my repository.

As an additional reference and to see some published Fractal projects, we have the published version of the Perch Pattern Library, and also the Pattern Library for 24 Ways (built by Paul Robert Lloyd), which you can take a look at. These are good examples of a non-website pattern library, and a more traditional one used for a site.

How Do You Manage CSS?

I really like this way of working; it allows me to write CSS in a straightforward, progressively enhanced way. Depending on the project, we may include far more tooling and processing of files. Or, I may be building a simple site in which case the setup will be pretty much as we have seen in this article — with some light processing of Sass. The fact that Fractal means we can have the same process for sites big and small, for web applications or websites. It means we can always work in a familiar way.

This works for us, and I hope this article might give you some things to experiment with. However, I would love to know the ways in which you and your team have approached managing CSS in your projects and the strengths and weaknesses of the approaches you have tried. I’d be especially interested in hearing from anyone who has developed a similar process using another pattern library solution. Add your experiences in the comments.

Smashing Editorial (il)


Articles on Smashing Magazine — For Web Designers And Developers

Newer postsOlder posts
×

Powered by WhatsApp Chat

WhatsApp Chat is free, download and try it now here!

× Chat with Us