My Experience with Polymer 1.x at Enterprise Scale - Web Components

Table of Contents:

  1. Introduction
  2. Web Components
  3. Base Components
  4. Region Components
  5. Layout Components
  6. Master Component
  7. Data Adapters
  8. The App Data System
  9. Configuration
  10. Takeaways

When we began analyzing just how flexible our app needed to be, it needed to not only be made of building blocks that could be shifted around, but each block would be capable of changing it's style, shape, and size. In other words we needed to make Transformers that combine into Megazord. (Feel free to make fun of me for that last line).

Trying to accomplish this with vanilla HTML, CSS, and JS would be possible (anything's possible really), but I would probably go through a bottle of Tylenol with all of the headaches that would arise from such a system. Even if we expertly engineered a design system that could pull it off, it would quickly be sabotaged by new requirements, redesigns, and inexperienced employees. Why? Because the vanilla web has no sense of componentization.

Web components offer us a host of tools that enable us to pull off an extremely flexible, reusable, and scalable design. Let's take Component A in the diagram below for example:

Notice the position in the layout of Component A in the layout and its own internal layout. For the sake of this demonstration, Component A is made up of two sub-components, an Image Carousel and a Product Table.

The Image Carousel and Product Table are synced together on a 10sec. frequency in which the current item in the Product Table is highlighted with a color and the Image Carousel is displaying an image that matches the currently highlighted product.

Now, let's imagine that we want to take Component A and swap places with Component B, Component B swaps with Component C and Component C takes the place where Component A once filled.

What would our app have to do now to accomodate this?

  1. Component A must shrink to fit in the same place as Component C.
    • This would likely require a complete design change in order to keep the same functionality.
    • We would alter our CSS, we may have to restrict the number of products allowed when this component is in this configuration, and we may have to change what style of images this component should use.
  2. Component B must expand and adapt to the previous size of Component C.
  3. Component C must expand and adapt to the previous size of Component A.

Now, imagine 5 more layouts with any number of possible configurations for where each component will belong. How would you handle this in a non-componentized system?

  • Have very strict CSS class naming conventions and create a lot of files to account for the different designs.
  • Create a very highly modularized JavaScript system in an attempt to avoid conflicts.
  • Implement some sort of templating system to handle the different HTML layouts required.

Considering these development requirements to create this system you would still end up with code that isn't truly tied together. Wouldn't it be great if you could bundle your CSS, HTML, and JS for one of these components together in a neat package that a browser could natively ingest?

Web Components Save the Day

If we implement our system utilizing Web Components we'll be able to take advantage of this "bundling" feature and create a system that is much easier to reason about and scale. It will also reduce the code bloat that typically is associated with trying to manage the "bundling" yourself.

For our project we had to create the above example at a much larger scale. To meet the demands of that scale we took on an Atomic Design type of methodology which is something that is very natural in Polymer.

After much planning our system took on the following structure (I am noting the atomic design equivalent in parentheses):

  • Base Components - These are the smallest parts of the app (like an atom) that are the end point of all data. The consist of components like "base-header", "base-product-table", "base-image-rotator", etc.
  • Region Components - These are typically collections (molecules/organisms) of Base Components that implement a design to provide a visual part of the menu.
  • Layout Components - These are what control where the Region Components belong on the menu.
  • Master Component - This single component is the entry point in which the entire menu board is generated. It selects a layout for the screen based on meta data.

In my next article I will explain base components and how we can begin creating a menu board system from them.