Skip to content

[WIP] Implement reusable primitives#761

Draft
NoelDeMartin wants to merge 4 commits into
SolidOS:post-milestone3mfrom
NoelDeMartin:primitives
Draft

[WIP] Implement reusable primitives#761
NoelDeMartin wants to merge 4 commits into
SolidOS:post-milestone3mfrom
NoelDeMartin:primitives

Conversation

@NoelDeMartin
Copy link
Copy Markdown
Member

@NoelDeMartin NoelDeMartin commented May 21, 2026

This is a follow up from #748, and it implements some reusable "primitive" components alongside a new Solid UI component (<solid-ui-account>).

Here's a summary of the most relevant points:

  • The first commit can be ignored (assuming you've looked at [WIP] Implement design system button #748)
  • You'll notice the "primitive" components are very narrow in behaviour (login, signup, and logout buttons are separate components, etc.). Initially I started with more useful components, but I realized it's very difficult to make them useful whilst still being "stylable". Because of that, I ended up doing smaller components and the more complete components sit on the "design system" layer. We can talk about that, but I think it's the best approach for now. The markup for primitive components can be overriden completely, look at their storybooks for examples.
  • One of the key architecture decisions here has been to decouple the Authentication from components. In fact, you'll notice the only authentication that has been wired up is Storybook's (which is a stub). We discussed this in this week's meeting, but TLDR, if we really want these components to be reusable, we have to decouple them from the actual authentication (Solid UI uses solid-logic, but other applications won't).
  • I have been struggling to implement a decent Popover (and have also been experimenting with Dialogs) with Web Components. This is one of the challenges I mentioned initially about web components. In particular, the targeting and relations between different elements inside and outside of the Shadow DOM are difficult to manage (a button inside a component is supposed to open a menu from a different component, possibly even from the light DOM, etc.). We'll need to keep investigating this, but I wonder if it would make sense to rely on third party libraries for these type of interactions (maybe Web Awesome, given that it's very aligned with our tooling?).
  • Related to the previous point, I'm aware that some of the components (specially the <solid-ui-menu>) are not very accessible. This is something I want to continue exploring as we work on these.
  • I am also aware that I'm using some advanced features that may not be supported in older browsers, such as the :state() selector or the Popover API. I have already thought on some ways to polyfill them, or even replace them, but for now I think it's ok to use them until we decide on the final direction.
  • Check out the updated Storybook to see al the components, both design system and primitives.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant