Micro-frontend types

ILC has different categories of micro-frontends. You are free to decide where and how you use each of them. The table below gives you basic recommendations:

Topic	Applications	Parcels	Global libraries
SSR support
Routing	(multiple routes)
API	Declarative API	Imperative API	Exports a public interface
Renders UI			(may or may not render)
Lifecycles	ILC-managed lifecycles	Custom managed lifecycles	External module: no direct single-spa lifecycles
When to use	Core building block	To embed part of one app into another	Useful to share common logic, or create a service

Each ILC micro-frontend is an in-browser JavaScript module.

Applications

Applications are registered in ILC Registry, and their lifecycle (when and where they should appear) is managed by ILC, based on the configuration of Routers and Templates.

Applications act as the main building blocks for the website and can be rendered at the server-side to enhance page loading time and SEO/SMO metrics.

Parcels in Applications

Applications can export Parcels to allow parts of their UI to be used in other apps.

Parcels

With Parcels, you can reuse parts of UI across applications when those applications are written in multiple frameworks. In other words, Parcels is an ILC-specific implementation of web components.

Use case example

Contacts modal

Let's say, you have an App1 that handles everything related to contacts (highly cohesive) but somewhere in App2 you need to create a contact. To to this, you can use several techniques:

1. If both are written in the same framework, you can export/import components.
2. Re-implement creation of a contact (loss of cohesion).
3. Use Parcels.

Exporting a Parcel from App1 that wraps the createContact modal component gives you the ability to share components and behavior across disparate frameworks without losing application cohesion. App1 can export a modal as Parcel, and App2 can import the Parcel and use it.