You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Following our recent integration of Zag.js, we're now unifying logic and state handling for most components and features using Zag itself. However, there's still a lot of repetition in how we scaffold components per each framework, including:
Common prop names
Common default prop values
Common types and interfaces
Common JSDoc comments for type definitions
We should investigate potential solutions to provide a single source of truth for this information.
Potential Issues
Hugo and I have discussed this on several occasions, but the biggest barrier of entry is that not all components are constructed symmetrically per framework. For simple components such as Avatars the implementation is quite close. The same list of props, values, types, etc:
While fairly similar from the end user's perspective, there's some notable differences:
Svelte: uses snippets for List/Control; requires only 3 components (Root, List, Panel)
React: requires dedicated components for each part of the component tree structure
Note that React does supply React.Node props, allowing you to pass template data through props. But the user-facing API for doing this is not widely used in any framework we've reviewed. And personally speaking is quite unfriendly:
This is great for small additions, such as icons. But would quickly become unmanageable once the size of the child content reached a certain length.
Potential Solutions
So far we do not have a solid solution for this scenario. However, the following ideas have been discussed:
Standardize all components around the composed tree of components (ala React), unfortunately this hurts the DX for Svelte, Vue and other frameworks on both the end user and maintainer/contributor side of things. We don't get to use the handy tools they provide (Snippets, slots, etc)
Keep separate structures, but find an alternative way to define the non-uniform props/types per these components. Unfortunately this returns us to the original issue we're trying to solve.
We welcome additional ideas and proposals around this in the comments section below!
The text was updated successfully, but these errors were encountered:
Following our recent integration of Zag.js, we're now unifying logic and state handling for most components and features using Zag itself. However, there's still a lot of repetition in how we scaffold components per each framework, including:
We should investigate potential solutions to provide a single source of truth for this information.
Potential Issues
Hugo and I have discussed this on several occasions, but the biggest barrier of entry is that not all components are constructed symmetrically per framework. For simple components such as Avatars the implementation is quite close. The same list of props, values, types, etc:
However, this is not always the case. Select components, such as Accordions and Tabs, can differ wildly:
The most common reason for this being React (or JSX-based component systems) lacking an 1:1 equivalent for named slots. For example:
Svelte:
React:
While fairly similar from the end user's perspective, there's some notable differences:
Note that React does supply
React.Node
props, allowing you to pass template data through props. But the user-facing API for doing this is not widely used in any framework we've reviewed. And personally speaking is quite unfriendly:This is great for small additions, such as icons. But would quickly become unmanageable once the size of the child content reached a certain length.
Potential Solutions
So far we do not have a solid solution for this scenario. However, the following ideas have been discussed:
We welcome additional ideas and proposals around this in the comments section below!
The text was updated successfully, but these errors were encountered: