-
Notifications
You must be signed in to change notification settings - Fork 9
A minimal declarative component set designed for LLM generation #5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
| - `<hstack>` - flexbox with row flex direction. | ||
| - Attributes | ||
| - `gap` - creates a gap between items. Defaults to a standard gap size. | ||
| - `<vstack>` - flexbox with column flex direction. | ||
| - Attributes | ||
| - `gap` - creates a gap between items. Defaults to a standard gap size. | ||
| - `<spacer>` - an empty element with aggressive flex grow and flex shrink to allow it to fill additional available space. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No <grid>? You can jerryrig one using stacks I suppose.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we want to avoid fine-grained visd primitives for now, in favor of use-case specific declarative/semantic layout components.
I think flexbox is a minimal layout module that should work for everything else. Notable to me that React Native and SwiftUI have both converged around it. And hstack/vstack/spacer offer the minimal markup surface.
| - `<button>` | ||
| - `<textfield>` | ||
| - `<rich-textfield>` - can wait | ||
| - `<input type="text">` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
<input type="number> is another good candidate imo
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Idle thought, if we integrate models like Whisper we could even have an input type to accept voice/audio.
|
Take the following with a grain of "chris wouldn't have put in the effort to write a whole RFC for an experiment so maybe he should keep his opinions to himself." Not stated in this RFC (but I, for one, would enjoy reading) is a rationale for why an off-the-shelf component set and/or state management solution is not considered. At the surface level, it seems like the shortest path to answering a question like, "can an LLM organize basic declarative components into something more useful," is one where the components and/or state management does not need to be implemented from scratch. (Thanks for being bothered to write this BTW) |
|
@cdata do you have a component library in mind? Would be a great exercise to take it and figure out the delta between it and our requirements |
|
No, I didn't have a library in mind. But, there is so much unmentioned prior art for the web as to make me wonder about the rationale for something brand new. Authoring good/robust components from scratch is a time consuming and thankless exercise, after all. For some token cases of component libraries, I would suggest picking apart https://ui.shadcn.com/ or https://shoelace.style/. |
|
TY! I'll dig into these. |
|
Closing out stale PRs, please reopen if this is relevant |
Rendered