Lazy-loading components (part I - Intro)

About a week ago I decided to give some love to my AEM multi-tenant series and I got a very good question...how do you handle components lazy loading?

It is a very good question, and the answer (or some potential guidelines), can serve many different contexts. So I decided to decouple this post from the series. It's agnostic to any framework or CMS. At least, the analysis previous to deciding your lazy loading strategy.

This article is especially interesting for Enterprise Architecture, but you can take some learnings and ideas to other contexts.

Enterprise solutions: a monster

Yes, enterprise solutions are a very particular kind of solution. When you design for enterprise, you usually design patterns with the following in mind:

• views (or pages) are dynamic. You may have a template or a design guideline of what a page may potentially look like, but that can change at any time.
• components may be present in a page, multiple times
• each one of those potential instances in a single page/view, may have a different initialization configuration
• components will certainly have common dependencies, and those needed to be defined ONCE, and not multiple times

So where do you start?

The atomicity principle

I have to admit. I am a bit of an intransigent person when it comes to atomics. That means I am very much inclined to have my team think well about the smallest atomic unit that can function as a standalone, and make it a component.

Let's take the button example. A button is a button, yes. But a button in itself has multiple functional units, in terms of representation.

• the wrapper of the button, itself
• a label
• an icon

Each one of those has multiple different states, so they can be represented as atomic units. A label may say "Submit" or say "Cancel". An icon may be an arrow or a cross. And the wrapper of a button may cascade colors for positive or inverted combinations. This means that they are standalone units. They have an atomic life of their own. And so, they can be mapped to individual components.

The commonalities

Now, this is sort of the opposite. A label may have multiple values. They are dynamic. They may be coming from a logic conditional...However, commons are ...well, common to all instances of all components. They are consumables. Like the font type or the color scheme. And when it comes to JS, utility, and helper functions that serve your whole application. Services. (think singleton!) Even a very important piece of this puzzle: a component loader, that we will talk more about later.

And then, there is also the context

Context is like a switch. It's the one guy that says "This standalone feature, will be initialized with this configuration, and consume from these common definitions, while here". The context can be a section of your site. It can be a specific page. It can be a section of your page. It can be a region of it.

And why making this distinction matters?

It very much matters. Commonalities, you will want to bundle together. You will probably want to split them apart and put them together in a couple of bundles, and request each only once.

For JavaScript, it's likely you want to have a very well defined imports strategy, so you can leverage tree shaking at build time, and make sure you get the slimmest bundles you possibly can. If any of this sounds like too much for you right now, let's digest it slowly. Let's start by creating and publishing an npm package with CSS common abstracts, that you can reuse over and over across many tenants. If you want to learn more, stay tuned for Part II (probably coming tomorrow!)!

• What are abstracts?
• What should be in this package?
• What should NOT be in this package?
• How do you publish it to NPM?
• How do you make it part of your dependency graph?

See you soon! Stay safe. Stay at home!