Support Ash

[Flo0807]

Support Ash framework. Users should easily be able to create Backpex LiveResources for Ash resources. We probably need to implement an abstraction layer between data and UI so we can support multiple data sources.

At the start, we could support ash resources and plain Ecto schemas. In the future, other sources may be supported.

[Alt-iOS]

Hi, I am new to elixir and was liking the UI of Backpex and also the facilities ash provides, in its current state how complicated would it be to add support to ash? would you be open to a PR?

[Flo0807]

Hey, I think we first need to work on an abstraction regarding the UI and the data source. This way we can support multiple data sources, e.g. Ecto and Ash. This includes not only CRUD operations, but also filters for example. At the moment we are tightly coupled to Ecto. The first step is to remove this coupling.

We also do not need to build Ash support all at once, but can prepare it by isolating the data source more and more to be able to build something like an Ash adapter in the end.

It is hard to say how complicated it is, but I think that working on an Ash support means dealing with Backpex in every detail and getting to know the source code very well.

We are very happy to receive PRs on Ash support, but we would like to know about the technical implementation first and work closely together to make sure it goes in the right direction (of course, this does not mean we want to discuss every detail, but rather the rough plan).

[Alt-iOS]

I understand, and it makes complete sense to first separate the UI from the data source. I'll spend some more time experimenting with both Backpex and Ash since I encountered some rough edges today with Ash. Once I’ve explored these options further (And also practiced my elixir, like I said I am somewhat new😅), I would like to help with the separation of the UI and data source to support different providers such as Ecto and Ash. Thank you for your response and openness.

[MartinElvar]

Maybe some documentation around using Backpex with Ash in its current form you be a work around for now. I'm probably gonna have to take the plunge soon, so I'm atleast gonna give it a shot. 🙂

[enoonan]

Hello hello!

Over the weekend I started working on an Ash integration for my app. I read the adapter warnings etc, but this still seemed like a better business decision than any other way of building the admin I needed. I used the current Ash adapter as a starting point.

https://github.com/enoonan/ash_backpex

At the moment, this repo is intended as an example to follow, not a dependency for other folks' projects. It doesn't even have a mix.exs file.

I'd be happy to generalize it and take the lead on Backpex+Ash integration, provided that I can be in the loop with y'all about future changes, and offer input about pain points.

Thanks for an incredible library! 🎉

[enoonan]

I made a lot more progress on my Ash+Backpex implementation, with some assists from Zach Daniel in the Ash Discord.

It now uses a Spark DSL and can derive sensible defaults for most fields. It's very incomplete, but I'm enjoying the heck out of this:

# myapp_web/live/admin/post_live.ex
defmodule MyAppWeb.Live.Admin.PostLive do
  use AshBackpex.LiveResource

  backpex do
    resource MyApp.Blog.Post
    load [:author]
    layout({MyAppWeb.Layouts, :admin})

    fields do
      field :title
      field :published_at

      field :author do
        display_field(:name)
        live_resource(MyAppWeb.Live.Admin.AuthorLive)
      end
    end

    filters do
      filter :state do
        module MyAppWeb.Live.Admin.Filters.PostStateFilter
      end
    end
  end
end

https://github.com/enoonan/ash_backpex

[enoonan]

Here I'm going to create a sort of to-do list of places where we'd need the assigns available in order for Ash to be able to set the current_user as the actor and satisfy its authorization requirements. I'll start with the Adapter callbacks and sort of "work outward" from there.

Adapter Behavior Callbacks

Assuming the following type exists ...

  @type assigns() :: map()

Then these (link)...

@callback insert(struct(), module()) :: {:ok, struct()} | {:error, term()}
@callback update(struct(), module()) :: {:ok, struct()} | {:error, term()}
@callback update_all(list(struct()), keyword(), module()) :: {:ok, non_neg_integer()}
@callback delete_all(list(struct()), module()) :: {:ok, term()} | {:error, term()}

Would need to be more like this:

@callback insert(struct(), assigns(), module()) :: {:ok, struct()} | {:error, term()}
@callback update(struct(), assigns(), module()) :: {:ok, struct()} | {:error, term()}
@callback update_all(list(struct()), keyword(), assigns(), module()) :: {:ok, non_neg_integer()}
@callback delete_all(list(struct()), assigns(), module()) :: {:ok, term()} | {:error, term()}

Basically I just added assigns() before module() in all those functions.

It doesn't seem like there are too many places where this will affect Backpex itself, but unfortunately it will probably cause BC issues in user apps.

Places Where Those Functions are Called

insert

backpex/lib/backpex/resource.ex

Line 103 in 8cd40f3

|> adapter.insert(live_resource)

update

backpex/lib/backpex/resource.ex

Line 124 in 8cd40f3

|> adapter.update(live_resource)

update_all
First appears in resource.ex, but the assigns is not available in that function.

It seems like this function is only meant to be invoked inside of user-defined bulk actions, like the soft-deletes example in the demo.

delete_all
Like update_all this first appears in resource.ex but the assigns is no available.

It's referenced in item_actions/delete.ex

---

I am happy to try to take a crack at making these updates unless you'd rather make them yourselves. I'm mostly just not sure how you'd want to handle the BC issues.

[Flo0807]

I am happy to try to take a crack at making these updates unless you'd rather make them yourselves. I'm mostly just not sure how you'd want to handle the BC issues.

If you need some functionality for AshBackpex, feel free to create PRs. It is okay if it is breaking, as we are still at v0.X. We can provide upgrade guides.

[gmazzamuto]

Hi folks,

I am sorry for being late to the Ash party, but I just wanted to share with you that I had implemented almost full Ash support for Backpex just before Ash support was dropped in v0.17.0 (see #1675). I was planning to test it more and I still have some work to finish (e.g. passing around the author, context, scope), but unfortunately I've been very busy lately. However it's already pretty much fully functional and well integrated into Backpex (sorting, filters, forms, policies, etc all work).

If interested, you can find my implementation in this branch:
https://github.com/gmazzamuto/backpex/tree/feature/ash-support

Please refer to the Demo.Helpdesk.Ticket and DemoWeb.TicketLive modules for an example of how to use, and also please build the documentation and refer to the page for Backpex.Adapters.Ash to see how Ash actions can be specified for the different action types (otherwise, the primary action for that type will be used).

Any observations are welcome! I wonder whether I should keep this custom branch or switch to ash_backpex as you suggest (haven't tried it yet). @enoonan would love to hear your view, great work btw! :)

Cheers!
Giacomo

[enoonan]

Hello!

@gmazzamuto Let's consolidate our efforts! Definitely check out AshBackpex and if there's anything you've built that's currently missing, let's see if we can get it in.

[enoonan]

@Flo0807 really excited to see you are now recommending AshBackpex! Banner day for us! 🎉

Quick question about the 0.17 release.

The release notes in the tagged release look like there aren't any breaking changes we need to worry about on our side. We don't support the InlineCRUD field yet so we should be good there.

But then the Upgrade guide says "Add Translations." So I just want to double check: adding translations is fully opt-in and is in no way breaking?

[Flo0807]

But then the Upgrade guide says "Add Translations." So I just want to double check: adding translations is fully opt-in and is in no way breaking?

yes, this is fully optional.

[gmazzamuto]

@enoonan I've taken a look at AshBackpex. First of all, as I said congrats for the great work with Spark! I bet that wasn't easy...

That said, at the moment I can't fully port my DemoWeb.TicketLive to AshBackpex without losing some functionality. One thing is to add support for Ash resources, another thing is to rewrite the whole Backpex API as a DSL. Isn't this a burden to maintain in the long run? Just trying to understand :)

Additionally, in a project one might have Ecto resources alongside Ash resources, and I would like to use the same API to handle all the Backpex-related stuff. Wouldn't it be better to have just an adapter, leaving everything else as is? like this:

defmodule DemoWeb.TicketLive do
  use Backpex.LiveResource,
    adapter: AshBackpex.Adapter,  # <------------ Here
    adapter_config: [
      resource: Demo.Helpdesk.Ticket
    ],
    layout: {DemoWeb.Layouts, :admin}

  @impl Backpex.LiveResource
  def fields do
    [
      subject: %{
        module: Backpex.Fields.Text,
        label: "Subject",
        orderable: true,
        searchable: true
      },
      body: %{
        module: Backpex.Fields.Textarea,
        label: "Body",
        orderable: false,
        except: [:index]
      }
    ]
  end
end

On the other hand, I must admit that my implementation isn't limited to just the Ash adapter, it also touches other areas in the Backpex codebase (especially because I take advantage of ash_phoenix for forms). Which I also don't like, but maybe is easier to maintain? Or maybe the internal adapter interface in Backpex can be further refined in the future so that the adapter functionality can be extracted in a separate module, fully outside the Backpex codebase. From the developer perspective however, the Backpex API stays exactly the same for both Ecto and Ash resources.

[enoonan]

You shouldn't need to use one or the other. You can use regular Backpex resources alongside AshBackex ones.

I'm pretty sure that for functionality we haven't implemented yet, you can just write Backpex functions onto modules that use AshBackpex.LiveResource and they should work as normal.

If that doesn't work, you also always have the option to just use the adapter, as you suggested.

Wouldn't it be better to have just an adapter, leaving everything else as is? like this:

The reason to use a spark DSL is that it allows us to derive Backpex configs directly from the Ash resource attribute declarations. Generally it's a lot less typing and a lot less room for error. You can often write the same resource in way less code this way. The example you have above would be something like this:

defmodule DemoWeb.TicketLive do
  use AshBackpex.LiveResource, layout: {DemoWeb.Layouts, :admin}
  
  backpex do 
    fields do
      field :subject do
        orderable true
        searchable true
      end
      field :body do
        module Backpex.Fields.Textarea
        except [:index]
      end
    end
  end
end

Spark DSLs are not all that hard to write / manage once you get the hang of it.

We do also use AshPhoenix for forms. Kinda have to!

[enoonan]

Feel free to make PRs or request features via github issues! Also there's an #ash_backpex channel in the Ash discord!

[gmazzamuto]

You shouldn't need to use one or the other. You can use regular Backpex resources alongside AshBackex ones.

Sure, what I meant is that the two resource types have different APIs. Actually, though, the DSL is a great help in the IDE for autocomplete... in a sense it would be nice to have it also in regular Backpex! However, I find there are advantages also with using regular functions instead of the DSL. For example I sometimes group my list of fields into sublists, and apply functions to the subgroups to further modify the fields in a given group. Another thing I often do in the :index (and :show) views is that I have custom columns (rows) that do not correspond to any field or calculation in the model. Is this possible with AshBackpex?

I'm pretty sure that for functionality we haven't implemented yet, you can just write Backpex functions onto modules that use AshBackpex.LiveResource and they should work as normal.

Almost, for example to use render_resource_slot/3 I need to add use Phoenix.Component, but that's not a big deal.

If that doesn't work, you also always have the option to just use the adapter, as you suggested.

Doesn't work out of the box, it says that a lot of config options are missing (:schema, :repo, :update_changeset, etc, but probably these are leftovers from the old adapter). Speaking of which, why are there options such as :load? Shouldn't this be already taken care of by the corresponding Ash action with a preparation?

What about Metrics and Filters? Do they work?

Spark DSLs are not all that hard to write / manage once you get the hang of it.

good to know!

We do also use AshPhoenix for forms. Kinda have to!

I see it listed as a dependency, but can't find anywhere in the code where it is used. Instead there seems to be an implementation of the Phoenix.HTML.FormData protocol for Ash.Changeset.

Thanks for your feedback! :)

[enoonan]

I honestly don't have answers to all of your questions right now. It sounds like you've got a pretty involved and extensive fork and I can't promise we'd be able to support all the things you've gotten it to do.

Up to this point, features have been added to AshBackpex by people who have contributed them as they needed them for their own projects. So I'd say, tinker around with it, see what you can and can't get to work, and either request features or send PRs?

Doesn't work out of the box, it says that a lot of config options are missing (:schema, :repo, :update_changeset, etc, but probably these are leftovers from the old adapter).

Ahh yes. So a lot of that default config is actually set up during compilation. You can look at the config schema of AshBackpex.Adapter to see what's required etc - the descriptions there should help. This would be a good thing for us to document! Because just using the adapter without the DSL will be a great escape hatch of last resort.

I'd have to check if it's safe to remove load because a lot of that does get derived automatically now. It might be good to keep around in case people want to override the default behavior. For now you can just put def load(_, _, _), do: [] on your model to satisfy that.

Instead of continuing the convo on this thread, would you mind posting these as Issues / PRs / Feature Requests in AshBackpex?

[Flo0807]

Hey!

First, thank you so much for your effort on Ash support 🎉

I just wanted to share with you that I had implemented almost full Ash support for Backpex

I wonder whether I should keep this custom branch or switch to ash_backpex as you suggest (haven't tried it yet).

@gmazzamuto this is wonderful! As @enoonan mentioned, we should continue working on ash_backpex to bring Ash support to Backpex. I see from the chat that you are already working on converting your work to ash_backpex. This is great!

From now on, most Ash-related features should be implemented in ash_backpex. However, some changes to the Backpex Core may be needed. If so, just let us know and we will try to make it work. We welcome PRs, too!