jharton:

<@197905764424089601> has offered $20 to anyone who removes Surface from Ash Admin and converts it to a “plain old” LiveView library.

Folks matching his $20:

• <@346791515923939328>
• <@111498226867134464>

Anyone else?

seven_seacat:

oh that’s a good call

zimt28:

• $20

jharton:

I have created an issue on the repo. https://github.com/ash-project/ash_admin/issues/46

sevenseacat:

Having a tinker with this now - the one thing I do like about Surface is defining props/data for a LiveComponent. LV doesn’t yet have this functionality 😦

I haven’t touched any of the forms yet. I have a feeling they’ll be painful.

zachdaniel:

oh really? You can’t do declarative props for LiveComponent?? Thats really lame

zachdaniel:

I had no idea

sevenseacat:

no, only function components

zachdaniel:

😢

zachdaniel:

Seems like a pretty big missing piece

jharton:

I guess make everything as a function component?

zachdaniel:

I just feel bad because ash admin is really not a good liveview

zachdaniel:

I really didn’t know that much about liveview when I wrote it.

zachdaniel:

I’m half tempted to say that ash admin needs a full rewrite with the intention of supporting user logins with ash authentication, custom pages, getting rid of the info/schema pages (no one needs those really), and making it better all around really.

sevenseacat:

that’s not a rewrite, that’s probably a whole separate project

zachdaniel:

🤔 potentially. But you wouldn’t really need both. It has support for setting an actor, and will respond accordingly (although not limiting the UI/buttons or anything like that, just limiting data/giving forbidden errors), but its currently set up so that you can like…intentionally “be anyone” (by configuring resources as “actor resources”).

zachdaniel:

So it wouldn’t be too difficult to configure the current thing with something like “look for the actor in X assign”

zachdaniel:

but I think the real problem is that if its going to do that kind of thing it should be designed with that in mind. Whatever the new thing is, it would effectively supercede the need for ash_admin at some point (and might as well just be called ash_admin v2 )

sevenseacat:

yeah quite possibly, like an ash_admin v2 rebuild from the ground up w/ no surface and all nice and componentized

sevenseacat:

add it to the roadmap!

zimt28:

At that point, what would be the difference between ash_admin and a more generic ash_ui package? An admin would just be another user with more permissions, or no?

sevenseacat:

fair point

sevenseacat:

‘define your resources, add ash-ui, boom instant crud app’

zachdaniel:

In my eagerness to make useful things for people, I think its easy for me to want to push the boundaries on what ash_admin can do, and honestly that is probably a bad idea. I think perhaps the biggest problem is that its called ash_admin instead of something like ash_dashboard , where the idea is that its essentially a developer dashboard that can be used to quickly prototype and test. Its okay to run it in prod behind ash_authentication , but trying to make it something that people wrap up and ship as a product (even if its just restricting some actions to super users and anyone else with access can do the rest) is likely a recipe for disaster. So I think that UI libraries like <@433654314175692800> ‘s phlegheton are the way to go in the end. And if we want to provide even higher level components for people to do this, we can ship those as UI components too. Like:

<AshUI.ResourceTabs resources={[resource1, resource2]} :let={resource}>
  <AshUI.CreateForm actions={:all}>
    ...
  </AshUI>
</AshUI>

Or perhaps if someting else was designed for this purpose it would look more like something like kaffy: https://github.com/aesmail/kaffy

Where there is a separate DSL for your admin site.

defmodule MyApp.AdminUI do
  use AshAdmin.AdminUI

  pages do
    ...
  end
end

Either way, probably best to keep the current ash_admin as “dumb as possible”, because its not really a viable solution for more than “dev console” type work (and I think we agree on that front/that is what others have already been saying)

sevenseacat:

agreed

dblack1:

Crazy idea incoming… but if “the idea is that its essentially a developer dashboard that can be used to quickly prototype and test”, why don’t we use what’s already available during dev and hook up an “Ash” page to LiveDashboard where you can get basic crud for your resources. LiveDashboard supports additional pages via:

dblack1:

live_dashboard "/dashboard",
  additional_pages: [
    _profiler: {AshAdmin.Dashboard, []}
  ]

zachdaniel:

All for it 🙂

zachdaniel:

I wonder if we could actually deprecate the stuff we have in favor of showing them as custom pages. Would have to research it.

dblack1:

One drawback would be that we’d tie ourselves into the LiveDashboard ecosystem - I’m not sure if that’s as changeable as everything else in LiveView (would we be swapping one dependency on surface with another)

dblack1:

You’ve talked about “building blocks” previously, maybe we should be starting at the resource level and provide a way to do crud operations on a resource:

<.ash_crud resource={MyApp.Blog.Post} api={MyApp.Blog} />

This would let you add crud operations in a standard way into your existing app, and ash_admin (wherever that may be hosted) is just a collection of these

zachdaniel:

Yeah, I like that idea a lot 😄

zachdaniel:

I think its what we ultimately need to do

zachdaniel:

And we could have something like AshAdmin that is composed of those blocks and just does the default work

zachdaniel:

but then say “look if you want to copy this, use these components and make your own”

dblack1:

yep, and the navigation between different api’s and resources

dblack1:

I’ll have a look next week… I should be able to get what I need for an ash_crud component from ash_admin already. The hardest bit for me will be constructing nested forms which I’m guessing ash_admin already does?

zachdaniel:

Yeah, it does

zachdaniel:

Might be worth it to talk with <@433654314175692800> as well about how phlegethon could help?

dblack1:

ah, ok, will do - if this is touching on what phlegethon will be doing, even better! I’ve not had a chance to look yet

zachdaniel:

It depends really, I’ve been meaning to look at it for ages now, just been so bogged down

frankdugan3:

In a nutshell: Phlegethon isn’t ready to handle all of that, but it is planned to provide components and declarative extension config for a hierarchy of components. So you could use it all the way up to the page component level, or all the way down to just a form/table/card, or just a plain non-smart component, or at any point in between.

frankdugan3:

I would really like to make some chart/graph components, but haven’t done any of that yet. If you want to jump in with some PRs for that, would love to have the help!

frankdugan3:

Today I’m working on an autocomplete component and datatables.

frankdugan3:

frankdugan3:

I would imagine the SmartForm and SmartDataTable components would go a long way to refactoring Surface out of AshAdmin.

frankdugan3:

But, not quite ready yet. 😅

zachdaniel:

Yeah that would be so useful. We already require manually entering ids and things like that

\ ឵឵឵:

A production-ready dashboard, or set of UI components that can be quickly wired up to become one, implemented as an Ash transformer would be absolutely grand. I like the component approach because it lets you have deep control over how the dashboard looks based on things like actor roles and other forms of customisation, and because it’s pretty easy to ship entire common dashboard configurations that users can then deconstruct and customise as necessary.

\ ឵឵឵:

I’d be happy to discuss, test, and contribute code to such an endeavour.

kernel_io:

you can wrap live components with function components

kernel_io:

to get the whole ability to have compile time validation on props etc

kernel_io:

but yeah, hopefully next release it’s actually supported

frankdugan3:

Also a note: You can declare the attributes in anticipation of them being supported. It doesn’t crash if you define them, it just doesn’t run the validations. Could even create a third-party validator. I’m actually using the attributes for LiveComponents in Plegethon, the macros do work correctly as far as getting built/collected.

frankdugan3:

I did a pretty deep dive in the prop system, and LiveComponent calls the same Component setup macro.

frankdugan3:

For example:

iex(7)> Phlegethon.Components.Autocomplete.__components__
%{
  render: %{
    attrs: [
      %{
        doc: "Enable autofocus hook to reliably focus input on mount",
        line: 45,
        name: :autofocus,
        opts: [default: false],
        required: false,
        slot: nil,
        type: :boolean
      },
      %{
        doc: "(overridable, `:tails_classes`, required)",
        line: 12,
        name: :class,
        opts: [],
        required: false,
        slot: nil,
        type: :any
      },
      # ...