Conversation
|
Size stats
|
|
Deploy preview for mistica-web ready! ✅ Preview Built with commit de134fc. |
|
Accessibility report ℹ️ You can run this locally by executing |
Marcosld
left a comment
Marcosld
left a comment
There was a problem hiding this comment.
Should we already define how do we intend to transition between this and a shared doc for devs and LLMs?
scripts/generate-component-docs.js
Outdated
There was a problem hiding this comment.
This script is very very complex for what it does. Do we really need to parse component props to create a table? I feel like if we tell the LLM where the source file is localted it will do a similar job at understanding its props... I would spend some time (not necessarily now) refactoring it or finding an easier solution.
| }) | ||
| } | ||
| > | ||
| {" "} |
There was a problem hiding this comment.
Please remove these spaces
|
|
||
| When to create a custom component | ||
|
|
||
| - The UI requirement cannot be satisfied by composition of existing Mistica components without repeated |
There was a problem hiding this comment.
Perhaps we could add an instruction requiring the llm to explicitly requiring confirmation by the user before creating a custom component
|
|
||
| # Badge | ||
|
|
||
| Badge is a compact, decorative indicator used to signal unread or pending status on top of another UI element. |
There was a problem hiding this comment.
decorative? I would say functional xD
There was a problem hiding this comment.
I would use functional only in cases where it has any behaviour based on interaction, so in this case we can use informative instead of decorative it works better?
doc/components/badge.md
Outdated
|
|
||
| ### Don't use for | ||
|
|
||
| - Do not use it as a standalone content element; it should decorate another component |
There was a problem hiding this comment.
i don't really like the word "decorate" because isnt a decoration (in terms of accessibility for example)
There was a problem hiding this comment.
Well, actually badge is hidden to screen readers, so we could state that is decorative, but i would't use that wording either. I've removed this point since we use badges standalone.
| - Do not use secondary styling for the main conversion or progression action | ||
| - Do not present too many secondary actions in one group, which can dilute clarity | ||
| - Do not style destructive actions as secondary when risk needs explicit emphasis | ||
|
|
There was a problem hiding this comment.
I can see a lot of "style" verb in this rules... Looks like is talking about style css or something similar. I have doubts about let this kind of "doors" open (mainly to avoid confusion in a human or a machine that can think the buttons can be customize)
doc/components/carousels.md
Outdated
| #### Use for | ||
|
|
||
| - Browsing related cards or modules when horizontal exploration is the intended interaction | ||
| - Revealing progressive content with clear page feedback (bullets) and optional directional controls |
There was a problem hiding this comment.
I would replace "bullet" by "page indicator" or similar maybe to make it more agnostic (also in description maybe)
There was a problem hiding this comment.
This may collision with new carousel definition? I was using page bullets / page counter
doc/components/carousels.md
Outdated
|
|
||
| #### Use for | ||
|
|
||
| - Showing a small sequence of prominent slides (for example hero banners or featured stories) one page at a |
There was a problem hiding this comment.
mayb can we include Hero component to expose the possibility to combine with this component? (the same in hero component)
|
|
||
| ## ButtonLinkDanger | ||
|
|
||
| ButtonLinkDanger is a low-emphasis destructive action used when risk exists but should not dominate the |
There was a problem hiding this comment.
I would clarify the usage between ButtonDanger vs ButtonLinkDanger. Maybe something like: "Use ButtonDanger for primary destructive actions with maximum prominence; use ButtonLinkDanger for secondary destructive actions that need lighter emphasis."
| - Do not use ToggleIconButton for multi-step or multi-option choices beyond two states | ||
| - Do not use the same icon/label for checked and unchecked states when meaning changes | ||
| - Do not omit accessible naming for each state; state intent must be understandable to assistive tech | ||
| - Do not use toggle interactions when the action is not reversible or does not represent a true on/off state |
There was a problem hiding this comment.
I'd simplify this to: "Do not use ToggleIconButton for actions that are not truly binary (on/off)." The "reversible" part is implied.
| - Do not use large primary actions in this pattern when compact action treatment is expected | ||
| - Do not present decorative visuals without clear supporting message and intent | ||
|
|
||
| ## CardActionIconButton |
There was a problem hiding this comment.
This component have no description or usage guidelines.
|
|
||
| ## CardActionIconButton | ||
|
|
||
| ## CardActionSpinner |
There was a problem hiding this comment.
This component have no description or usage guidelines.
| - Do not rely on deprecated small-card patterns when `NakedCard size="snap"` is the intended approach | ||
| - Do not overload transparent cards with excessive actions that reduce scanability on busy backgrounds | ||
|
|
||
| ## HighlightedCard |
There was a problem hiding this comment.
I think if they're still in the library we should document them. We could either:
-Keep individual files but add status: deprecated in the frontmatter with a note pointing to the replacement
-Group all deprecated cards into a single DeprecatedCards.md file with each as a subsection
Wdyt?
| @@ -0,0 +1,369 @@ | |||
| // @ts-check | |||
| // Component categories based on Storybook structure (src/__stories__) | |||
There was a problem hiding this comment.
The categories file looks good. After looking into this, adding a synonyms field could help improve search and LLM understanding for categories that might be searched by different names (eg "collapse" for accordions, "toggle" for switch, "tag" for chip). We can keep it as a future idea if we see it's needed
| - Do not rely on decorative circles alone to communicate critical information | ||
| - Do not use low-contrast background and border combinations that reduce legibility | ||
|
|
||
| ## Touchable |
There was a problem hiding this comment.
What's the difference between Touchable and TouchableElement?
|
|
||
| # StackingGroup | ||
|
|
||
| Use stacking group to display a compact set of similarly sized items, optionally overlapped, with a `+N` overflow indicator. |
There was a problem hiding this comment.
Should we add information about the +N element?
| - Binary preferences or settings that can be turned on and off independently | ||
| - Cases where the state change is immediate and does not require a separate confirmation action | ||
| - Interfaces with short, explicit labels (or accessible labels) so users understand the effect of each toggle | ||
| - Optional custom switch row compositions where the control remains semantically exposed as a switch |
There was a problem hiding this comment.
Should we clarify what "switch row composition" means?
| @@ -0,0 +1,22 @@ | |||
|
|
|||
| # Tag | |||
There was a problem hiding this comment.
Should we make this distinction explicit between Tag and Chip? We could reinforce in each component's documentation that they serve different purposes. Tag is for status/category (non-interactive), while Chip is for actions or selection (interactive).
| - Do not rely on overlay dismissal for destructive or irreversible flows without explicit confirmation | ||
| - Do not stack multiple independent overlays when a single coordinated layer can manage focus and dismissal | ||
|
|
||
| ## FocusTrap |
There was a problem hiding this comment.
FocusTrap, Portal, and applyAlpha have ambiguous descriptions. Could we follow how Overlay is documented to improve them?
4 participants
Add component docs under docs/component