Doggo - A collection of unstyled Phoenix components

I released Doggo, a collection of unstyled Phoenix components.

Features

  • Unstyled Phoenix components.
  • Storybook that can be added to your application, so that you can see the component with your own styles.

Goals

  • Follow proper HTML semantics.
  • Adhere to accessibility guidelines with appropriate ARIA attributes and roles.
  • Favor semantic HTML and ARIA attributes over CSS classes for style bindings to states, if possible.
  • The library is comes without default styles and does not prefer any particular CSS framework.

Why did I build it?

  • I regularly bootstrap new projects and needed a component library to quickly replace Phoenix’s tailwind-based components.
  • I prefer to solve UI problems once and use the solutions across projects.
  • I’m very comfortable writing my own CSS/SCSS and feel like I outgrow any CSS framework at some point in a project’s lifecycle.

What’s next?

  • Add stories for components that are not covered in the storybook yet.
  • Complete the base component set (#20).
  • Implement remaining APG patterns (#139).
  • Add keyboard interaction (#136).
  • Improve conformance to WAI-ARIA and WCAG.

So far, all components are plain Phoenix components without any JavaScript. For some accessibility patterns, especially those involving keyboard interaction, it may be necessary to introduce some JavaScript in the future. I might also consider introducing more complex (live) components.

39 Likes

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

1 Like

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

1 Like

Looks like that worked!

1 Like

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.

12 Likes

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
4 Likes

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.
1 Like

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.

3 Likes

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.

1 Like

That is actually something I was thinking about. I have another project in its very early stages. In its current form, it is only an SCSS starter kit, but the idea in general was to define a specification first (e.g. a naming convention for design tokens and recommendations for the project structure), with the starter kit basically just being a reference implementation. And since I’ve published Doggo, I was wondering whether it would make sense to define a collection of standard components in a generic way that is not bound to any frameworks or languages. If that component specification was comprehensive enough and in a machine-readable format (e.g. JSON), it would be possible to generate Phoenix components from that specification, indeed, at least the HEEx part.

4 Likes

Great work - I was waiting for something like that.

I hope some capable devs with good CSS knowledge provide some basic CSS styling. One day we might have that for some of the most common CSS frameworks (e.g. Tailwind, Milligram,…).

@woylie nice job! Is it possible to maybe have the storybook deployed somewhere (Fly?) so folks can quickly see how the components work and behave? This would definitely reduce the friction to test and potentially adopt these components.

Also, are you currently using these components in a project or are you just developing them on their own?

1 Like

I could deploy the storybook, but since the components don’t have default styles, I don’t think it would be very useful.

I’m using Doggo in my side projects currently. I might start using it at work as well, if a new project comes along.

2 Likes

Cool stuff.
I’m working for a few months on writing a headless components library for LV too, but the more the merrier as we are still pretty thin on that front. The idea is for it to be the base of a more opinionated / styled UI library that makes use of it.

Keep up the good work!

4 Likes

Doggo 0.3.0 introduces a bunch of new components. This concludes the base component set for now. The next focus are the remaining APG patterns and keyboard interactions.

Added

  • New component: Doggo.avatar/1.
  • New component: Doggo.badge/1.
  • New component: Doggo.bottom_navigation/1.
  • New component: Doggo.box/1.
  • New component: Doggo.callout/1.
  • New component: Doggo.fab/1.
  • New component: Doggo.field_group/1.
  • New component: Doggo.page_header/1.
  • New component: Doggo.skeleton/1.
  • New component: Doggo.steps/1.
  • New component: Doggo.tag/1.
  • New component: Doggo.tooltip/1.
  • Allow to visually hide labels.
  • Support autocomplete via <datalist> in input/1 component.
  • addon_left and addon_right slots on the input/1 component.
  • gettext attribute on Doggo.input/1, giving you the choice to
    set the Gettext module locally.

https://hexdocs.pm/doggo/changelog.html#0-3-0-2023-12-27

6 Likes

By the way, there is a demo app in the same repository that I use for development. I added instructions for running it locally.

3 Likes

Release 0.4.0 focuses on improving the consistency of the existing components and on improving the test coverage. It also introduces the cluster and toggle_button components.

7 Likes

Doggo 0.5.0 focuses on the semantics of the remaining APG patterns. Note that not all added components are fully functional yet: client-side interactivity including keyboard support will be the next focus. Components that are not ready to be used yet are marked with admonition blocks in the documentation.

Added

  • New component: Doggo.alert_dialog/1.
  • New component: Doggo.carousel/1.
  • New component: Doggo.combobox/1.
  • New component: Doggo.disclosure_button/1.
  • New component: Doggo.menu/1.
  • New component: Doggo.menu_bar/1.
  • New component: Doggo.menu_button/1.
  • New component: Doggo.menu_group/1.
  • New component: Doggo.menu_item/1.
  • New component: Doggo.menu_item_checkbox/1.
  • New component: Doggo.menu_item_radio_group/1.
  • New component: Doggo.radio_group/1.
  • New component: Doggo.split_pane/1.
  • New component: Doggo.tabs/1.
  • New component: Doggo.toolbar/1.
  • New component: Doggo.tree/1.
  • Storybook page about modifier classes.
  • Mix task mix dog.modifiers to list all modifier classes.

Changed

  • Set aria-invalid and aria-errormessage attributes in Doggo.input/1
    component.
  • Use buttons instead of links in Doggo.action_bar/1.
  • Add toolbar role to Doggo.action_bar/1.
  • Use section instead of article in Doggo.modal/1.
  • Use button for close button in Doggo.modal/1.
  • Add dismissable attribute to Doggo.modal/1.
  • Remove role from button_link/1, add class.
  • Rename Doggo.drawer/1 slots to header, main, and footer.
  • Rename Doggo.drawer_nav/1, Doggo.drawer_nav_nested/1 and
    Doggo.drawer_nav_section to Doggo.vertical_nav/1,
    Doggo.vertical_nav_nested/1 and Doggo.vertical_nav_section/1.
  • Depend on phoenix_storybook ~> 0.6.0.
11 Likes