Merge branch 'master' into feat/studio-next

.github/workflows/lint-pr-adr.yml

@@ -25,7 +25,7 @@ jobs:
             const title = context.payload.pull_request.title;
             const labels = context.payload.pull_request.labels;
             const hasAdrLabel = labels.some(label => label.name === 'kind/adr');
-            const re = /^(chore:\s*)?\[ADR-(\d{4})\]/;
+            const re = /^(?:chore:\s*)?\[ADR-(\d{4})\]/;
             const match = title.match(re)
             const startsWithAdr = (match !== null);
             if (hasAdrLabel && !startsWithAdr) {

apps/studio/package.json

@@ -24,7 +24,7 @@
   ],
   "dependencies": {
     "@asyncapi/avro-schema-parser": "^3.0.2",
-    "@asyncapi/converter": "^1.2.1",
+    "@asyncapi/converter": "^1.3.1",
     "@asyncapi/openapi-schema-parser": "^3.0.3",
     "@asyncapi/parser": "^2.0.3",
     "@asyncapi/react-component": "^1.0.0-next.48",

doc/adr/0003-use-design-system.md

@@ -0,0 +1,27 @@
+# 3: Use a design system and UI kit
+
+Date: 2023-07-10
+
+## Status
+
+Accepted
+
+## Context
+
+To streamline the development process of Studio, it is important to establish a design system and accompanying UI kit. The goal is to provide developers with pre-designed components and guidelines, eliminating the need to start from scratch for each interface and reducing the cognitive load of making design decisions.
+
+
+## Decision
+
+We have decided to create a UI kit and design system as code rather than solely relying on Figma files. While Figma files can be useful for initial designs and gathering feedback, providing the components and designs as code will enable developers to directly implement them in their projects.
+
+The design system and UI kit should include components for typography, buttons, navigation, menus, modals, and other elements essential to our UI. However, it is important to avoid adding components that are not necessary for our specific use case. The aim is to establish a framework that accelerates development, not to build yet another comprehensive UI library.
+
+To accommodate this change, we have chosen to use the [turborepo](https://turbo.build/repo) tool to transition the Studio repository into a mono repository. This will allow us to manage multiple applications within a single repository, making it easier to maintain and distribute the design system and UI kit.
+
+## Consequences
+
+Implementing this decision will result in the following consequences:
+
+- The code repository will be transformed into a mono repository, accommodating multiple applications.
+- Developers will have access to a design system and UI kit provided as code, enabling them to quickly incorporate standardized components into their projects.

doc/adr/0004-use-radix-ui.md

@@ -0,0 +1,38 @@
+# 1. Record architecture decisions
+
+Date: 2023-07-17
+
+## Status
+
+Accepted
+
+
+## Context
+
+In our project, we have identified the need for a set of UI components that only handle the logical part without imposing any design aspects. We have evaluated existing libraries such as Radix and Headless UI, which provide components without implicit designs. 
+
+We have concluded that using a ready-made library would restrict our freedom to customize the look and feel of the components. Additionally, this kind of libraries integrate design elements into their components, making it challenging or impossible to modify them according to our specific requirements.
+
+This is related to [ADR-003](./0003-use-design-system.md).
+
+## Decision
+
+After careful evaluation, we have decided to use Radix UI. This decision was driven by the following factors:
+
+- **Flexibility**: By creating our own components, we gain complete freedom to define the design and visual aspects according to our specific needs and branding.
+
+- **Logic Integration**: Building our own components allows us to integrate both the logical and design aspects seamlessly. We can ensure that our components handle keyboard navigation, support screen readers, check for rendering space, and avoid collisions with window limits.
+
+- **Maintenance and Community Support**: We have selected Radix as our preferred library due to its completeness, active maintenance, and vibrant community.
+
+## Consequences
+
+The decision to build our own UI components instead of using existing libraries will have the following consequences:
+
+- **Increased Development Effort and maintenance**: Developing custom UI components requires additional time and effort compared to adopting an existing library.
+
+- **Design Consistency Responsibility**: With the freedom to define our own components, we also bear the responsibility of maintaining design consistency across the application. We must establish design guidelines and ensure that all components adhere to them, promoting a cohesive and intuitive user interface.
+
+- **Reduced Dependency on External Libraries**: By building our own components, we reduce our reliance on external libraries and minimize the risk of being tied to their specific look and feel. This independence allows us to evolve and iterate on the components based on our unique requirements, providing long-term flexibility.
+
+By carefully considering these consequences and actively managing the development and maintenance process, we believe that building our own UI components will provide us with the flexibility, control, and customization required to deliver an outstanding studio user experience.