feat: split conditions and rules into separate tabs, refactor schema component#1121
feat: split conditions and rules into separate tabs, refactor schema component#1121catosaurusrex2003 wants to merge 60 commits intoasyncapi:masterfrom
Conversation
…i-react into refactor-messages
…ad, split stuff into seperate components
catosaurusrex2003
changed the title
catosaurusrex2003
changed the title
|
|
|
@AceTheCreator |
|
This pull request has been automatically marked as stale because it has not had recent activity 😴 It will be closed in 120 days if no further activity occurs. To unstale this pull request, add a comment with detailed explanation. There can be many reasons why some specific pull request has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model. Let us figure out together how to push this pull request forward. Connect with us through one of many communication channels we established here. Thank you for your patience ❤️ |
|
still relevant |
AceTheCreator
left a comment
AceTheCreator
left a comment
There was a problem hiding this comment.
@catosaurusrex2003 I left some review :) Let's get this PR merged.
| expandAll(); | ||
|
|
||
| expandAll(); | ||
|
|
There was a problem hiding this comment.
Is this expandAll() called twice intentional?
There was a problem hiding this comment.
Yes it is intentional
But
Idealy it shouldnt be needed (theres an issue with the recursive working of expandAll)
test it against this schema in playground and you will understand.
asyncapi: 2.6.0
info:
title: Sets Example
version: 1.0.0
channels: {}
components:
schemas:
Sets:
title: Sets
type: array
items:
type: object
title: Set
properties:
pets:
title: Pets
type: array
items:
title: Pet
type: object
discriminator: type
required:
- type
properties:
type:
title: Pet.Type
type: string
enum:
- CAT
- DOG
oneOf:
- title: Cat
type: object
properties:
type:
const: CAT
- title: Dog
type: object
properties:
type:
const: DOG
There was a problem hiding this comment.
Okay, this makes sense in the case of deeply nested schema structure. I think you should add a comment why it needs to be called that way 😄
There was a problem hiding this comment.
I don't think this makes sense.
Shouldn't expand all work irrespective of schema being deeply nested ?
…hema-related components
AceTheCreator
left a comment
AceTheCreator
left a comment
There was a problem hiding this comment.
I think that'll be all from my end... I'm happy to chat about how best to represent these rules constraints especially in number types 😄
| expandAll(); | ||
|
|
||
| expandAll(); | ||
|
|
There was a problem hiding this comment.
Okay, this makes sense in the case of deeply nested schema structure. I think you should add a comment why it needs to be called that way 😄
|
2 participants
The problem
The current schema UI assumes a deep understanding of the AsyncAPI specification, making it difficult for many users to interpret. Since schemas can be recursive and heavily nested with various properties, the complexity often becomes overwhelming and unintuitive.
The solution
This PR introduces a new UI structure that splits schema properties into two logical sections: Rules and Conditions, making the documentation easier to understand and navigate.
Reference: AsyncAPI Schema Object (v3.0.0)
The properties which come under the
Rulessection are:format,pattern,constraints,contentEncoding,enum,default,constThe properties which come under the
Conditionssection are:oneOf,anyOf,allOf,not,propertyNames,contains,if,then,else,dependentSchemasAll other properties remain in their original positions.
A tabbed interface now allows users to toggle between Rules and Conditions. This design reduces visual clutter and helps users digest smaller, relevant portions of the schema at a time.
Visual Comparison
Old schema UI 👇
New implementation - Rules tab 👇
New implementation - Conditions tab 👇
New implementation - Conditions tab and expand all 👇
Alternative approaches explored
We initially considered a sidebar-based layout as demonstrated here that separated Rules and Conditions spatially. However, it introduced several issues:.
Without sidebar 👇 :
With sidebar 👇 : (you can notice how the empty spaces in red which is very unoptimal)
After discussions with @AceTheCreator we opted for the tabbed layout, which offers better responsiveness, clarity, and overall user experience.
Other changes
The existing
library/src/components/Schema.tsxhas been refactored into smaller, modular components under a newlibrary/src/components/Schema/directory for better maintainability and readability.Updated the way constraints are displayed: ranges like
[0..1000]are now represented in a more intuitive format as1 <= value <= 1000for better readability.Updated the
startandbuild:styles:devscript to include all the available tailwind styles during development. This ensures that when you add a new Tailwind class (even one not yet used anywhere else in the project), you don’t need to rebuild the styles manually. The new styles are already available in default.min.css, so changes take effect instantly through hot reloading — speeding up the development workflow.Source/Inspiration
#618
https://www.asmitbm.me/projects/asyncapi-docsux
This PR is part of https://github.com/orgs/asyncapi/discussions/1361#discussioncomment-10811342