import '../../components/dialog/dialog'
import '../../components/img/img'
import '../../components/theme/theme'

import archImage from './arch-overview.png';

# Green architecture

Green Core is the foundation of the Green Design System, and consists of a set of framework agnostic Web Components. These components can be used in any front-end framework, or without a framework, for example rendered on the server side. The Web Components are built using the Lit library, but this is an implementation detail that is typically not exposed to consumers, and consumers are not expected or required to use Lit.

The Green architecture roughly looks like this:

<gds-theme>
<gds-dialog heading="Architecture overview" width="95vw" height="95vh" scrollable><gds-link slot="trigger"><gds-img src={archImage} width="800px"></gds-img></gds-link><img></gds-dialog>
</gds-theme>

The dashed curvy lines illustrate roughly how different roles, like designers and developers, interact with the system, while the straight black lines illustrate actual code flows.

Public API Boundry before Web Components means that anything that is lower level than a complete component is considered internal to the framework and should not be used by consumers. We only guarantee semantic versioning for the public api. Anything that is considered internal could change in breaking ways in any release.

## Web Components

All the components in Green Core are implemented as [Web Components](https://developer.mozilla.org/en-US/docs/Web/API/Web_components) using the [Lit](https://lit.dev/) library. The components makes use of [Shadow DOM](https://developer.mozilla.org/en-US/docs/Web/API/Web_components/Using_shadow_DOM) to encapsulate their styles and behavior, so they won't interfere with the rest of your application.

The reason the components use Shadow DOM is twofold:

- Provide style encapsulation to protect against styling conflicts which can occur in a micro-frontend environment
- Put constraints on the design itself. When a feature is missing, it is important that it is implemented in the Design System and designed according to brand guidelines following all the principles that are in place. If every team were to add their own tweaks, consistency becomes very difficult to maintain. So while this restriction can feel like a limitation at times, it serves an important purpose in the larger context of the Design System.

Internally, these Web Components are often composed of a hierarchy of smaller Web Componentes that defines the various atomic pieces that make up a component. These atomic parts could either be other public components from the library, or they could be private components that are not exposed to consumers. In Green Core, those private components are called 'primitives'. This internal composition serves to both make the library more efficient by rusing code, but also as a consistency constraint: It ensures that the design of these atoms does not accidentally drift appart over time.

## Fonts

Fonts are not imported automatically in the Core library, so applications need to add this separately. There are plenty of strategies for how static files like fonts are handled and hosted, and often they are already loaded and avaible in the shells.

The CSS `font-family` property is inherited though shadow DOM boundaries, so the components will render whichever font is used in the parent document.

## Wrappers

Since React and Angular are the most commmonly used frameworks at SEB, we generate dedicated wrapper components for those frameworks, so that components can be used in a more idiomatic way, side-stepping some of the common comporomises associated with using plain web components directly.

The wrappers are generated automatically based on Custom Elements Schema.

## MCP / CLI

From the same schematic data, context docs for AI coding agents are also generated. This is included in the Core package as a local MCP server as well as a command line interface (CLI)