# UI

From an architectural point of view, the user interface is a client to the public HTTP layer - and mostly talks the language of the HTTP layer.

## UI and HTTP

It is OK to import domain modules into the UI layer (but not others, obviously).

Once GraphQL is introduced into the stack, the graph types might be slightly different from the domain types, causing annoying issues. For this reason, it's best to stick to the graph's language here.

Use a [type generator](https://github.com/dotansimha/graphql-code-generator) to minimise effort. These can turn graph types into static type definitions for the UI, resulting in end-to-end type safety.

## Declarative UI

There are many great UI libraries and frameworks today. React is suggested here because it's a [*declarative*](https://thekarel.gitbook.io/best-practices/source-code/declarative) and *functional* solution.

See [thekarel/best-practices-example](https://github.com/thekarel/best-practices-example) for examples.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://thekarel.gitbook.io/best-practices/the-big-picture/architecture/ui.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.