Hi everyone!

I’m the other developer contributing to Petal. We’re pleased to announce our new docs page has gone live!

CleanShot 2022-01-11 at 09.11.211200×593 24.5 KB

CleanShot 2022-01-11 at 08.47.301200×594 29.9 KB

You can check it out now here: petal.build

There’s live demo’s of all the components and code snippets you can directly copy and paste into your projects - soon you’ll be able to download the boilerplate (hopefully over the coming week or two). We’d really welcome your feedback on both the new site and boilerplate (when the latter becomes available).

New update to Petal Components - v0.9.0

Card

CleanShot 2022-01-11 at 08.48.19799×803 38.5 KB

CleanShot 2022-01-11 at 08.47.54789×757 40 KB

CleanShot 2022-01-11 at 08.48.09793×591 24.8 KB

This is super great! I have a bunch of similar components in my own apps. My one big suggestion would be to consolidate the modules. You could likely have a single module with the current surface area. One of the goals of function components was to push folks away from the one-function-per-module for component pattern. By grouping the functions, they are more discoverable, doc’d in one place, etc. For example, folks could import PetalComponent (or single alias) and have most core UI components available as <.link, <.button. I’m not saying everything must be define under the same namespace, but the current surface area would be really well suited and would be nice in user land. Awesome work!

New version release (v0.5)

New form field types

Now every form field type is supported.

<.email_input form={f} field={:email_input} />
<.number_input form={f} field={:number_input} />
<.password_input form={f} field={:password_input} />
<.search_input form={f} field={:search_input} />
<.telephone_input form={f} field={:telephone_input} />
<.url_input form={f} field={:url_input} />
<.time_input form={f} field={:time_input} />
<.time_select form={f} field={:time_select} />
<.datetime_local_input form={f} field={:datetime_local_input} />
<.datetime_select form={f} field={:datetime_select} />
<.color_input form={f} field={:color_input} />
<.file_input form={f} field={:file_input} />
<.range_input form={f} field={:range_input} />

Progress bars

image617×734 12.1 KB

<.progress color="primary" value={15} max={100} class="max-w-xl" />
<.progress color="secondary" value={30} max={100} class="max-w-xl" />
<.progress color="info" value={45} max={100} class="max-w-xl" />
<.progress color="success" value={60} max={100} class="max-w-xl" />
<.progress color="warning" value={75} max={100} class="max-w-xl" />
<.progress color="danger" value={90} max={100} class="max-w-xl" />

Pagination

Links can be live_patch or live_redirect. Automatically adds the ellipsis so you can have unlimited pages (inspired by Material UI).

image409×313 7.86 KB

<.pagination link_type="a" class="mb-5" path="/:page" current_page={1} total_pages={10} />
<.pagination link_type="live_patch" class="mb-5" path="/:page" current_page={5} total_pages={10} />
<.pagination link_type="live_redirect" class="mb-5" path="/:page" current_page={10} total_pages={10} />

This isn’t true. We have the JS interface as well as javascript hooks for handling purely client side interactions. Try out the tailwindUI dropdown on LiveBeats:
https://livebeats.fly.dev/chrismccord

It features purely client-side interaction (no server trip), and it is fully accessible (keyboard nav, focus handling etc). So LiveView component libraries can be released to fully handle these kinds of things without React et al.

<.dropdown id={@id}>
  <:img src={@current_user.avatar_url}/>
  <:title><%= @current_user.name %></:title>
  <:subtitle>@<%= @current_user.username %></:subtitle>

  <:link navigate={profile_path(@current_user)}>View Profile</:link>
  <:link navigate={Routes.settings_path(Endpoint, :edit)}>Settings</:link>
  <:link href={Routes.session_path(Endpoint, :sign_out)} method={:delete}>
    Sign out
  </:link>
</.dropdown>

It’s my hope with HEEx and function components we’ll see more and more full-featured component libs (like petal), and that they will ship fully accessible components, so doing the right thing is the default for standard components. We know that developers won’t ship accessible features if it takes extra effort (unless they are forced), so a <.dropdown, <.modal, etc that just happens to be accessible out-of-the-box is the happy destination I hope we arrive at