Image for post
Image for post

In Part I of this series, we explored how Collective Health implemented a micro-frontend architecture to make our internal applications easier to maintain. Here, we discuss the side effects of our solution.

One objective from the start was keeping the platform consistent and unified from the end user’s perspective. On the engineering side, that meant creating a library of shared, framework-agnostic layout and UI elements that would ensure consistent page layout with a header and optional navigation components. This was another great use case for Web Components.

Solving for technical issues while future-proofing the solution

When creating components with libraries like React or Angular, we are used to passing a lot of data and callbacks. But complex data structures, like arrays, objects, or functions, cannot be passed as attributes to web components (or any other HTML element). To solve this, we decided to split our components into multiple, purely presentational elements and rely on slots for inserting content into them, managing all state changes (e.g., selecting an active navigation item) from the child app itself. This solution had the added bonus of making our components very flexible (as apps might have different routing patterns) and resilient to future changes. …


Collective Health

A smarter way to provide healthcare coverage through technology.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store