Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

Add pictures to concepts documentation #41

Merged
merged 1 commit into from
Feb 29, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
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
Binary file added docs/.vuepress/public/concept.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added docs/.vuepress/public/services.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added docs/.vuepress/public/topics.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
11 changes: 11 additions & 0 deletions docs/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -19,7 +19,18 @@ features:
# TODO: add this claim as soon as DAVIAF-109 is done
# - title: Seamlessly Integratable
# details: Style your application - Collage synchronzes the styles so the micro frontends you integrate fit in perfectly


---
## What`s in it for me?
Create an application that consists of different micro frontends
- which can be developed in completely independent and autonomously working teams
- that already existed as non-micro frontends before, but are extended to be reused as micro frontends
- which have their own scope and are isolated and therefore do not affect others


<br>


:::: code-group
::: code-group-item html
Expand Down
19 changes: 17 additions & 2 deletions docs/docs/concepts.md
Original file line number Diff line number Diff line change
Expand Up @@ -12,6 +12,14 @@ An HTML Document enhanced this way is called a [**context**](#context)
> Here is a quick overview: https://blogs.halodoc.io/iframe-security-threats-and-the-prevention/
>

<br>

If we look at an application like in following picture, then we see a collage, which consists of several parts. There is the application frame, which we call an [**arrangement**](#arrangement). The arrangement can embed one or several micro frontends, which we also call [**fragment**](#fragment). This fragment can embed another fragment. As soon as a fragment embeds another, we call it fragment and simultanously arrangement.

![Concept](/concept.png)



## Context

By calling the [expose function](../docs/core-api.html#expose-function), an HTML Document is automatically upgraded to a **context**. Being a context comes with two main features:
Expand All @@ -38,6 +46,7 @@ A fragment defines its internal layout and exposes capabilities and properties t
The capabilities and features of a context are defined and described by its Frontend Description. These can be [**Services**](#service), [**Topics**](topic), [**Direct Functions**](../docs/core-api.html#direct-functions-api) or a [**Theme**](../docs/core-api.html#theme).

## Service
Services are a request response communication mechanism.

A Service is a function or a collection of functions and topics and is uniquely identified by its name and (optionally) version. With a Service, you can easily provide functionality to other fragments. This especially comes in handy when you want to provide application functionality like notification handles or modal dialogs to fragments.

Expand All @@ -46,6 +55,7 @@ Services have certain attributes and restrictions:
- Two implementations of a Service must always be compatible with each other, e.g. by implementing the same specification.
- Every service exposed by a context is registered within Collage and kept synchronous between all contexts in the arrangement.
- If a context in the application is calling a specific service, always the implementation of the context that registered the Service topmost in the DOM tree is called. This means, that if a service is provided by each a fragment and its arrangement, always the implementation registered at the arrangement will be executed.
![Services](/services.png)
- The return value of the implementation is communicated back to the context initially calling the Service.
- A context can expose any number of Services via its Frontend Description.
- A Service is always provided to the whole Application.
Expand All @@ -59,9 +69,14 @@ Services have certain attributes and restrictions:
> Don't use services to work around origin restrictions (e.g. [SOP](https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy) or [Same Site Cookie Restrictions](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie/SameSite)).

## Topics
Topics are a publish subscribe communication mechanism. They are an efficient way to communicate messages to the whole application.

To do so, a context can publish a message on that topic. Any other context, that has subscribed to that topic gets the message and can react appropriately to the message.

![Topics](/topics.png)


Topics are an efficient way to communicate messages to the whole application.
To do so, a context can publish a message on that topic. Any other context, that has subscribed to that topic gets the message and can react approprietly to the message. Information about how to use topics are found in the [**Topics API**](../docs/core-api.html#topics-api) section of the [API documentation](../docs/core-api/).
Information about how to use topics are found in the [**Topics API**](../docs/core-api.html#topics-api) section of the [API documentation](../docs/core-api/).

## Self Sufficiency

Expand Down
Loading