Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

#

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

docs: fully revised microfrontend types doc #383

Merged
merged 1 commit into from
Mar 30, 2022
Merged

docs: fully revised microfrontend types doc #383

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
52 changes: 24 additions & 28 deletions docs/microfrontend-types.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,46 +1,42 @@
# Micro-frontend Types
# Micro-frontend types

ILC has different categories of micro-frontends. It is up to you where and how you use each of them. However, here are some recommendations.
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](./parcels.md) | Global libraries (coming soon...) |
| ----------- | ----------------------------- | --------------------------------------- | ------------------------------------------------- |
| SSR support | yes | no | no |
| Routing | has multiple routes | has no routes | has no routes |
| API | declarative API | imperative API | exports a public interface |
| Renders UI | renders UI | renders UI | may or may not render UI |
| Lifecycles | ILC managed lifecycles | custom managed lifecycles | external module: no direct single-spa lifecycles |
| When to use | core building block | to embed part of the one App into other | useful to share common logic, or create a service |

Each ILC micro-frontend is an in-browser JavaScript module ([explanation](https://single-spa.js.org/docs/recommended-setup#in-browser-versus-build-time-modules)).
| Topic | Applications | [Parcels](./parcels.md) | Global libraries
| --------------- | ----------------------------------------------------| --------------------------------------- | ------------------------------------------------- |
| **SSR support** | :material-plus-box:{.color-green} | :material-minus-box:{.color-red} | :material-minus-box:{.color-red} |
| **Routing** | :material-plus-box:{.color-green} (multiple routes) | :material-minus-box:{.color-red} | :material-minus-box:{.color-red} |
| **API** | Declarative API | Imperative API | Exports a public interface |
| **Renders UI** | :material-plus-box:{.color-green} | :material-plus-box:{.color-green} | :material-plus-minus-box: (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 |

!!! tip ""
Each ILC micro-frontend is an [in-browser JavaScript module](https://single-spa.js.org/docs/recommended-setup#in-browser-versus-build-time-modules).

## Applications

Applications are registered in ILC Registry and their lifecycle (when and where it should appear) is fully managed by ILC
based on the Routers and Templates configuration.
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 a main building blocks for the website and can be rendered at the server side to enhance page loading timing and SEO/SMO metrics.
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
It's also important to mention that applications can export Parcels and so they can allow parts of their UI to be used in other apps.
See [Parcel documentation](./parcels.md) for more details.

Applications can export [Parcels](./parcels.md) to allow parts of their UI to be used in other apps.

## Parcels

Parcels exist primarily to allow you to reuse pieces of UI across applications when those applications are written in multiple frameworks.
Think of parcels as an ILC specific implementation of webcomponents. See [Parcel documentation](./parcels.md) for more details.
With [Parcels](./parcels.md), 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 examples
### Use case example

#### Contacts modal

`App1` handles everything related to contacts (highly cohesive) but somewhere in `App2` we need to create a contact.
We could do any number of things to share the functionality between application 1 and 2:
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:

- If both are written in the same framework we could export/import components.
- We could reimplement creating a contact (loss of cohesion)
- We could use Parcels.
1. If both are written in the same framework, you can export/import components.
1. Re-implement creation of a contact (loss of cohesion).
1. Use Parcels.

Exporting a parcel from `App1` that wraps the `createContact` modal component gives us 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 easily.
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.