Bulma Widgets - LiveComponent wrappers using Bulma

Got a bunch more changes done and added some tests to verify the data sharing system. The handling of slots and a few other of the bulma components and elements have been improved.

I also put up the widgets example page on my personal website. If you open the widgets examples on two different tabs or browsers and select options under the “Shared and Cached Dropdown” menu you’ll see how it syncs the selections between them!

You can check it out here:

https://elcritch.net/widgets.html

I’ve been working on re-writing my previous bulma widgets library to modernize it. There’s basic components for most of the basic bulma elements. There are also a few initial stateful live components for dropdowns and menus.

The library also includes the necessary Bulma CSS files for easy setup.

A big part of the re-write focuses on changing how the state of widgets is handled. There’s an event system which provides out-of-the-box support for updating shared values from a parent liveview in child live components. There’s also support for cached values and broadcasting values. I’m still working on documenting the design, but the api’s in what I think is a useable state.

The goal is easy development for small scale app style UIs for Nerves devices.

https://github.com/elcritch/bulma_widgets2/

Here’s the examples I’ve been developing with:

https://github.com/elcritch/bulma_widgets2/blob/main/lib/bulma_widgets_web/live/widget_examples_live.ex

I find making a library out of my internal widgets helps keep me a bit more disciplined in documenting them. Plus maybe others find them useful. Not currently planning on adding Bulma extensions as I don’t use them currently, but I’d be willing to accept PR’s.

Great! I used yours to see how I could model something like a card component. I tried a few variations and ended up liking a pattern of using a case statement in a do block with the LiveComponents as the Source-of-Truth. Though I also provide a “default” setup using proplist options for cases where you would want standard buttons, like this:

    <%= live_component @socket, CardComponent, 
                   id: :card1, 
                   footers: ["Save Item": "card-1-save"] do %>
      <%= case @item do %>
        <% :content_item -> %>
          Lorem ipsum dolor sit amet, consectetur adipiscing elit.
          Phasellus nec iaculis mauris. <a>@bulmaio</a>.
          <a href="#">#css</a> <a href="#">#responsive</a>
          <br>
          <time datetime="2016-1-1">11:09 PM - 1 Jan 2016</time>
        <% _other -> %>
      <% end %>
    <% end %>

It turns out that using the do-block actually makes composability pretty straightforward, even using the parent LiveView assigns (@modal_va is set in the parent LiveView) works! I’m pretty happy with the composability, even though you have to write a case statement. A macro would be nice to handle that but broke when I tried it.

You can also mix and match from default event handlers or custom ones like in this example. Note the save-button targets the parent LiveView while the cancel-button uses the default cancel handler:

    <%= live_component @socket, ModalComponent, id: :modal2 do %>
      <%= case @item do %>
        <% :header -> %>
          <p class="modal-card-title">Second Modal</p>
          <button class="delete" phx-click="delete" phx-target="<%= @target %>" aria-label="close">
        <% :footer -> %>
          <button class="button is-success" phx-click="modal-2-save" >
            Save changes
          </button>
          <button class="button" phx-click="cancel" phx-target="<%= @target %>">
            Cancel
          </button>
        <% _other -> %>
      <% end %>
    <% end %>

Originally I tried using the parent LiveView as the Source-of-Truth, but it seems you can’t define handle_event’s without providing an id and state in the LiveComponent (in LiveView v0.9.0). Between that and having two spots to define/configure the widgets felt confusing and a bit cumbersome. So having the widgets send events to the parent LiveView allows a pretty simple interaction between widgets that seems pretty simple and robust so far. Though documenting it well is the tricky part.

Also there are helper functions to do things like open/close/update a widget like:

  def handle_event("modal-1-save", _params, socket) do
    {:noreply, socket |> widget_close(:modal1)}
  end

Don’t mind, it’s use to free. If I understand it correctly your Bulma Widgets behave as the source of truth, right? Maybe that’s the reason why is a composition of components so complicated. Just an idea, instead of using update function, define for each component a couple functions like handle_event/handle_info/.. which would provide a communication between these components.

Yes, I agree. The API should follow the KISS rule.

I had trouble using both of your sites on my iPhone.

We didn’t want to build this app for mobile devices. It’s only for desktop using But it’s good to know, thx.

Cool project. I am currently working with LiveComponents and Bulma myself. I wrote generic Bulma widgets to reuse them. Are you also planning to integrate the additional Bulma extensions on wikiki?

Nifty!

I might’ve got the two sites mixed up. I thought you’d posted a link to your site too?

P.S. I also added Modal Component. I’m curious if the API makes sense to others!

Oh you’re doing really cool things and inspired me a lot.

Really? which part of it? I thought it was working well because on my iPhone it seems good.

P.S. one thing I forgot to note, it that on iOS/embedded touchscreens many buttons don’t work with LiveView. I’ve got some JS code that fixes it by appending event handlers for touch. Just FYI, I had trouble using both of your sites on my iPhone.

Great! It would be good to get feedback from people. Your app looks nice, and it’s a nice complete looking setup for people to look at! Looks like you’re using POW which I haven’t tried yet.

Nice! Mind if I copy some of your components? I did a little HTML content in the tab’s component using a do block which works nicely, but that doesn’t scale to lots of components. There’s only two components currently, but the hardest part was just getting plumbing together. I’m not sure if how I’m handling the update/2 functions is the best, but it’s working.

The biggest issue in these component libraries is how to make a usable API for the more complex elements. That and it’d be nice to have a similar library for bootstrap, etc. Still having all the widgets connected so that clicking a another UI widget closes an already open dropdown. Otherwise it feels clunky and coding those interactions up is tedious.

Oh yes, that’s correct. Nerves builds a firmware image with the system and code that can be uploaded via an Upload script by ./upload.sh lacritch.xyz. Easy as can be. The code for this server is on my GitHub at Cloud Server. I should probably fix the Phoenix signing keys so they’re not in the config.exs but this is a throw-away server so I made it public so you could see it. The whole process is programmable in a few dozen lines of Elixir as well. Bootstrapping the initial VPS image is a little fiddly but not too bad. I used a Knoppix image to write the initial Nerves firmware to a VPS disk and it worked like a charm.

Another note is that I don’t see why one couldn’t take a Nerves firmware image and create a container image by dumping the squashfs filesystem to a tarball. Then you don’t need to worry about library version compatibility since it’s all cross-compiled. There’s more discussion on the topic Can you use nerves to deploy a cloud-based server? - #12 by axelson and Running Nerves on Amazon EC2

Honestly, when/if my company needs to deploy web services I’m going to use Nerves images. I don’t see the need for K8s unless you’re doing microservices and I plan to do everything in Elixir. Maybe make a nice LiveView dashboard, insta k8s alternative.