Skip to content

Investigate: Strong typing across microfrontends#1

Draft
mykeels wants to merge 10 commits into
masterfrom
strong-typing-across-microfrontends
Draft

Investigate: Strong typing across microfrontends#1
mykeels wants to merge 10 commits into
masterfrom
strong-typing-across-microfrontends

Conversation

@mykeels

@mykeels mykeels commented Oct 1, 2023

Copy link
Copy Markdown
Owner

Background

One of the disadvantages of using Microfrontends is developers lose type information because components are loaded at runtime, rather than at compile time.

E.g.
A team running Microfrontend A relies on a component in Microfrontend B which takes { a: number } as props. If for some reason, the props become { a: string } this can have consequences on the operation of Microfrontend A, if this change is not properly handled in B's instantiation logic.

What Ifs?

  • What if Microfrontend A's developers could get access to the typing information for Microfrontend B's props at development time with typescript?
  • What would such development experience look like?
    • Can it be optimized for low effort, high impact?
  • How can these types be aggregated, as each microfrontend is potentially developed and deployed by separate teams with separate infrastructure?
    • Which version of a microfrontend's deployments would be considered for type information? E.g. listening to types from a non-trunk branch deployment is potentially redundant until it is merged, right?
      • And if we only consider trunk branch deployments, then which versions of it, considering that the microfrontend could be rolled back to any of the last N versions?
  • How can this all be done consistently?

How this PR helps?

In this PR:

  • Every microfrontend-manifest.json file:
    • is now generated, instead of being managed by hand
    • now includes type information for slot component props, using JSON schema
    • contained JSON schema for typed events that are emitted by the microfrontend.
  • The microfrontends library:
    • exposes a jsonSchemaOf function that returns JSON schema of a zod type
    • uses generic types in the register function to provide strict typing of exposed modules
    • can have its register function run in a non-browser environment, so return metadata of exposed modules.
  • Every mf-*/package.json can have an equivalent git-ignored package.json.d.ts file that provides intellisense, so we can use the package's name as the scope of the microfrontend with strict typing.
  • The type information persisted in each microfrontend-manifest.json file is used to provide type checks in the IDE.

@mykeels mykeels self-assigned this Oct 8, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant