Thanks, that looks great!
mindreframer
arrowsmith
Thanks, I’m really excited to try this in my app!
Just wondering - the current installation guide says to follow DaisyUI’s instruction installations. But when I follow those instructions as written, it applies DaisyUI styles to my entire app, not just the admin pages, which isn’t what I want as my main app already has its own styles.
Is there a simple way to install DaisyUI so that it only applies to my Backpex routes and not my whole?
I came up with my own solution involving making a separate tailwind config file called tailwind.backpex.config.js, compiling another CSS file that’s separate from the normal app.css then rendering my backpex routes with a layout that only loads the new CSS file. It works, but I’m just wondering if there’s some obvious simpler way that I don’t know about.
If not I’m happy to write up my own solution in more detail, maybe as a PR for the Backpex docs?
0
thomas.fortes
I also run two different tailwind configs for admin and the main site, I also run two different javascript files because some custom fields have deps that I don’t need in the main site and I probably do the same thing that you do, split the files and edit the config and aliases.
I don’t think there’s anything wrong with it, the tailwind docs even provide a way to use different configs when using the tailwind cli without passing it in the command line.
2
arrowsmith
Okay so if anyone else is wondering how to do this, here’s what I did:
- copy
assets/tailwind.config.jsto a new fileassets/tailwind.backpex.config.js. - Update the new config file like so:
content: [
"./js/**/*.js",
"../lib/*_web.ex",
"../lib/*_web/**/*.*ex",
+ "../deps/backpex/**/*.*ex"
],
…
plugins: [
+ require('daisyui')
…
- Add a new tailwind command in
config/config.exsthat compiles backpex-related CSS (including DaisyUI) tobackpex.css:
config :tailwind,
version: "3.4.0",
default: [
args: ~w(
--config=tailwind.config.js
--input=css/app.css
--output=../priv/static/assets/app.css
),
cd: Path.expand("../assets", __DIR__)
- ]
+ ],
+ backpex: [
+ args: ~w(
+ --config=tailwind.backpex.config.js
+ --input=css/app.css
+ --output=../priv/static/assets/backpex.css
+ ),
+ cd: Path.expand("../assets", __DIR__)
+ ]
- Add a new watcher in
config/dev.exs:
config :my_app, MyAppWeb.Endpoint,
…
watchers: [
esbuild: {Esbuild, :install_and_run, [:default, ~w(--sourcemap=inline --watch)]},
tailwind: {Tailwind, :install_and_run, [:default, ~w(--watch)]},
+ tailwind_backpex: {Tailwind, :install_and_run, [:backpex, ~w(--watch)]}
]
Then add this line in your backpex layout so it loads the new CSS:
<link phx-track-static rel="stylesheet" href={~p"/assets/backpex.css"} />
Hope that helps someone.
10
Flo0807
Backpex v0.8 release - Starting to support Ash
We’ve just released a new version of Backpex. We have asked for feedback many times in the past, and by far the most requested feature was Ash support.
So this release lays the foundation to support multiple data sources (e.g. Ash).
With v0.8 we introduce an adapter module that sits between the UI and the data. We tried to move all current Ecto specific code into an Ecto adapter and have already started to implement an Ash adapter.
We added a new helpdesk section to our demo application that lists tickets that are retrieved from an Ash resource.
There is still some Ecto code that we need to move to the Ecto adapter. Moreover, the adapter pattern / API in Backpex is in an early alpha stage and is likely to change in the future.
In addition, the ash adapter is limited to listing and displaying items. You can’t edit items, use filters or delete items. Therefore, we recommend that you do not use the Ash adapter in production code. If you use the Ecto adapter, everything works as before.
However, we wanted to release these WIP changes as early as possible to get feedback from you and let you experiment with them. What are you looking for besides editing, filtering and deleting?
This release has some breaking changes, so make sure to read the upgrade guide. The guide also contains more information about the adapter pattern.
Release Notes: Release 0.8.0 · naymspace/backpex · GitHub
Upgrade Guide: Upgrading to v0.8 — Backpex v0.18.3
10
zachdaniel
Creator of Ash
Does the getting started guide need to be updated with these changes? It looks like the live resource example given in the getting started guide doesn’t have the changes applied from the upgrade guide.
EDIT: should also probably change the version listed in the getting started guide to 0.8.0 
1
Flo0807
tmbb
I really like this Backpex library, and I’d like to ask whether the following feature would be in scope.
Currently, one has to supply a lot of information for each individual resource (repo, layout, topic, event names, list of fields, etc.), which makes sense because it allows Backpex to be decoupled from the user’s app.
I wonder if one could introspect the ecto schema and automatically generate the list of fields and the corresponding input types (which could be overridden by the user if needed). Also, we could have a MyApp.LiveResource module which could be used in the individual live resources.
I’m thinking of something like this:
defmodule MyAppWeb.LiveResource do
use Backpex.AutoLiveResource,
repo: MyApp.Repo,
layout: {MyAppWeb.Layouts, :admin}
# possibly other options, like preferred
# input types for each ecto field type
end
Now we can use the above for super concise resource definitions:
defmodule MyAppWeb.MyResourceLive do
use MyAppWeb.LiveResource,
resource: MyApp.MyContext.MyResource
# everything else is taken from the
# common parameters given to the
# use macro above or inferred from the
# resource module name.
# fields are inferred from the ecto schema
override1: ...,
override2: ...
...
end
I could implement this if you think it’s in scope, otherwise I’ll just implement this in a different package.
1
tmbb
I have implemented a new macro, which does pretty much what I’ve explained in the last message:
defmodule MyAppWeb.LiveResource do
# Could be added into the Backpex namespace too
use BackpeXtra.LiveResource,
repo: MyApp.Repo,
layout: {MyAppWeb.Layouts, :admin},
pubsub: MyApp.PubSub
end
This module will encapsulate all the infomration that’s specific to your app
The next module will use the above module to very succintly declare a new live resource. Lots of things are inferred automatically from the resource module name.
defmodule MyAppWeb.MyContext.MyResourceLive do
use MyAppWeb.LiveResource,
resource: MyApp.MyContext.MyResource
end
The use ... macro above generates the following code:
def __update_changeset(item, attrs, _opts) do
# The macro has been smart enough to notice that
# there isn't an `update_changeset/3` function in
# the ecto schema and that there is a `changeset/2`
# function. For that reason, we will use that function.
StartTrials.Roster.Trial.changeset(item, attrs)
end
def __create_changeset(item, attrs, _opts) do
StartTrials.Roster.Trial.changeset(item, attrs)
end
use Backpex.LiveResource,
adapter_config: [
schema: StartTrials.Roster.Trial,
repo: StartTrials.Repo,
# Use the wrapper defined in this module, so that we
# can adapt the `update_changeset/3` function to the
# functions taht are implemented in the ecto schema.
update_changeset: &__MODULE__.__update_changeset/3,
create_changeset: &__MODULE__.__create_changeset/3,
item_query: &__MODULE__.item_query/3
],
layout: {StartTrialsWeb.Layouts, :admin},
# topic and event_prefix names inferred from the resource module
pubsub: [name: StartTrials.PubSub, topic: "trial", event_prefix: "trial_"]
@impl Backpex.LiveResource
def singular_name do
# Inferred from the resource module
"Trial"
end
@impl Backpex.LiveResource
def plural_name do
# Inferred from the resource module
"Trials"
end
@impl Backpex.LiveResource
def fields do
# List of fields built automatically from introspecting the
# fields in the ecto schema.
[
description: %{label: "Description", module: Backpex.Fields.Text},
name: %{label: "Name", module: Backpex.Fields.Text},
inserted_at: %{
except: [:new],
format: "%Y-%m-%d %H:%M:%S",
label: "Inserted at",
module: Backpex.Fields.DateTime,
readonly: true
},
updated_at: %{
except: [:new],
format: "%Y-%m-%d %H:%M:%S",
label: "Updated at",
module: Backpex.Fields.DateTime,
readonly: true
}
]
end
# Make this functioin overridable so that the user can implement
# their own fields if our automatic implementation is not a good fit
defoverridable fields: 0
Now, I plan on implementing overrides for everything so that the initial functionality can be replicated with a minimum amount of code. My goal is to be as succint as this: Introduction — Flask AppBuilder (Python code)
PS: the generated code at the bottom was obviously generated from a different macro evocation, I can’t edit it now but it does get the idea across
4
Flo0807
Hey!
I can see the problem that providing all the information can be tedious at first, but I also think that hiding the live resource configuration behind another module is not perfect either. Especially when it comes to supporting multiple data sources, like Ecto or Ash.
The setup is not that easy anyway, and creating another abstraction (live resources are already an abstraction for resources) makes it even more complicated.
I really appreciate your work and ideas to simplify the setup, but I guess we will not add such an auto live resources to the core at the moment. We are open to an add-on package if you need this feature and want to maintain such an automatic resource generation.
When it comes to making setup easier, I’d like to see Mix tasks that do the resource introspection and automatically generate live resources for you. The advantage of a Mix task is that we’d simplify the setup, but end up with the same configuration (both manually and programmatically via running a mix task).
Looking forward to hearing your thoughts!
1