This is a great idea! Well I have been busy due to the whole… global situation, and have several projects in varying states of bakedness.

Full-baked (but not sure if this library is “literally the worst” or not, so i’m too scared to generally advertise it):

• a broader toolkit for letting you shard various forms of global shared state (a la Mox and Ecto allowances) Multiverses — multiverses v0.11.0 (I also have adapters for finch, and phoenix.pubsub)

Half-baked WIP, and you should probably use Matrex for now: GitHub - ityonemo/linear_algebra: Linear Algebra for Elixir · GitHub

Cookie Dough: compile-time differentiable programming in elixir: untitled - asciinema.org

And I have one project that I just need to untangle from some other software, make better tests, and document it (and come up with a name for it - I’m thinking “Fakebooks”), it’s basically “ansible for elixir”, except using actual elixir as code instead of yaml. (so when debugging it you can drop IO.inspects in, etc)

I was working on refactoring Slick Inbox and I looked at my admin tool and didn’t like what I saw. It’s built with LIveView, but I find that I am repeating a lot of the same things (search, pagination etc) on every admin page that I have. They’re pretty simple pages, they list the entities in the DB (Newsletter, User, Webhook etc), I can edit them etc, it’s just so I don’t need to always SSH into my DB to do admin stuffs (like manually verifying user).

I looked at the repetitive stuffs, extracted them, and right now it’s looking like it could actually be generalisable for a library idea, tentatively named Backoffice, but I thought it would be good to check here first.

I actually found that it somehow end up looking quite a bit like Kaffy, which looks like a pretty great project, but my approach slightly differs in some way.

1. Kaffy uses controllers. Backoffice uses LiveView

2. You use Kaffy by using it in your router, the available paths are hidden from you, and you need to find it elsewhere (config.exs or a different Config module)

3. Kaffy works by having one controller, and then it renders things for you with a single controller as seen here. Backoffice would seamlessly integrate into your router file, you still need to declare your individual Live pages, but you can use Backoffice and that basically bootstraps your Live to an admin interface.

With Kaffy:

# https://github.com/aesmail/kaffy-demo/blob/master/lib/bakery_web/router.ex#L16

# router.exs
defmodule YourApp.Router do
  use Kaffy.Routes
end

I’m not a fan of this idea since it’s not immediately obvious what pages are available (the routes are defined in config.exs which could potentially call out to a different Config module as well, but I prefer things to be colocated)

With Backoffice, it would sit right next to your current set-up.

# router.exs

scope "/admin", YourAppWeb, do
    live("/users", UserLive.Index, :index) # these are your existing pages
    live("/users/:id/edit", UserLive.Index, :edit)

    live("/newsletters", Backoffice.NewsletterLive.Index, :index)
    live("/newsletters/:id/edit", Backoffice.NewsletterLive.Index, :edit)
end

You still need to create your own LiveView module, but you can see it sits nicely in your router, and Backoffice provides you a starting template of some sorts that you can then customize. For example, at a minimum you’d need:

defmodule YourAppWeb.Backoffice.NewsletterLive.Index do
  use Backoffice.Resources,
    repo: YourAppWeb.Repo,
    resource: YourAppWeb.Newsletter
end

This is essentially a wrapper to use Phoenix.LiveView and defines most of the callbacks for you. It also handles pagination for you (right now I’m depending on Scrivener.Ecto), and search (with a raw ilike query that doesn’t deal with input sanitization for now.. works for my internal usage ).

It has a list of things that you can override/customize, like what Kaffy does, so that part is not too surprising.

Kaffy already seems to be pretty great, but I didn’t like the way it configures. Backoffice is basically just me extracting out my current set-up, which may or may not be a good set-up as it might differ from how other people are building LiveViews.

I have already extracted it out in my codebase for a proof of concept and it’s working fine so far, but it still does make some assumption at a few places, so there’s quite a bit of work involved to remove those assumptions too.

What do you think? Is this something that is worth putting more effort into?

Making a finite-state automata library for Elixir might be worth it. People around here regularly use state machines to enforce proper state transitions and that certain persistent workers aren’t stuck in an invalid state that the code authors have no answer for.

FSTs sound like a good answer for part of these scenarios.

EDIT: There is such a library already: fsmx.