Doggo - A collection of unstyled Phoenix components

Nice! Big fan of your work so I’m looking forward to reading through this.

Looks cool! Do I need to do anything to generate the storybook components? I went through the installation process, but the Doggo Storybook page doesn’t have any components.

When I run

ls Path.join(:code.priv_dir(:doggo), "/storybook")

I get the error

No such file or directory <path_to_project>/_build/dev/lib/doggo/priv/storybook

I’m probably missing something obvious

Edit: I downloaded the source and manually copied the contents of priv into the build folder and that fixes the storybook file. Not sure what the right way to get it there is though.

I forgot to add the folder to the hex package. It should work in 0.1.3, can you try again?

Awesome work

Looks like that worked!

I have written many times my struggles on here that web UI is a huge gap and undermines Phoenix as a viable way to build apps fast. Phoenix isn’t fast vs other solutions which have established UI frameworks.

A set of semantic headless components that address accessibility is the missing piece in the ecosystem and now, with Doggo you have made great strides to closing that gap. Well done and thank-you for your efforts.

I’ve actually moved to using web components / custom elements because of this gap (Shoelace and Adobe Spectrum with the what looks to be amazing Spectrum 2 just around the corner).

IMO Doggo should be seriously considered by the Phoenix core team as a foundation library given there is nothing other than the “stop gap” core components which are not fit for purpose and create a maintenance issue for phoenix apps.

If Phoenix had a set of core semantic components which implement all the accessibility requirements correctly and cover the common application use cases then tools, generators, CSS frameworks, themes, application website templates, UI design/figma templates, and real storybook collaboration with design teams can thrive within the Phoenix ecosystem.

Without a core semantic UI component library Phoenix and liveview will remain a fringe hobby web technology with low adoption because the gap between UI design teams and dev teams is too large as they cant work effectively or efficiently together. Phoenix in effect slows you down vs just using react or next.js or any other popular solution that has established UI components and real storybook support out of the box to close the gap between design intent and devs.

With version 0.2, all components are covered in the storybook. It also introduces three new components:

• tab navigation
• frame - applies an aspect ratio to an image or video
• image - renders a figure with img and optional figcaption

Have you looked at bits-ui for inspiration in terms of structuring your headless UI components.

Bits-ui is a headless UI for accessibility concerns and is what shadcn-svelte is built on.

Some feedback:

• consider breaking things into module concerns
• keep drawers generic in respect of content.
• consider semantics for drawers like left, right, top, bottom and also scoped to another container element like Shoelace does as sometimes you don’t want a drawer to be viewport scope.
• consider generic menu lists which can be used in drop down menus, pickers, drawers etc vs drawer specific menu items.
• consider structuring your semantic UI along similar lines to Shoelace and Adobe Spectum given the relatively large coverage and use cases. Spectum React Aria provides a good example which only covers the accessibility /Aria concerns.

Thanks for the feedback! I put the items on my to-do list for further consideration. I wasn’t familiar with bits-ui, I’ll definitely check it out.

In general, the goal is to define sensible primitives while still allowing the user to add further customization. The drawer component for example has three slots, but it doesn’t make any assumptions about the content of those slots. You could just use the :top slot and put any content in there, you’re not bound to the other drawer_* components. To reflect top/right/bottom/left drawers, you can add your own modifier classes (just as an example, I might consider adding a separate attribute for this in particular).

There is an open issue for a generic menu, which will follow the APG menu and menubar pattern.

Thanks for your start on this important step for the community.

I don’t pretend to be any kind of expert in this, only sharing things that struck me a well designed with good coverage.

I am kind of impressed with what Adobe is doing with Spectrum 2, I think the time of custom elements is now and they will be leading the pack with a solid approach and huge investment as they are betting the farm on it with over 100 apps to be migrated to their web components.

Despite being quite bullish on web components I see incredible value for a semantic UI contract in Phoenix.

My thoughts are that your library could in fact be the start of a completely renderless behaviour module and your current implementation could be just one rendition of the html. With the right abstraction it should be possible to back the semantic UI onto your current rendition, Shoelace, Adobe Spectrum or something else entirely, even a native UI.