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.
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?
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.
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.
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.
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.
- 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!