I created a fork - and sent a PR that fixes something I noticed in with the custom css applied.
I’ll take a look at adding more custom class stuff in future PRs!
harmon25
tfwright
Very small release with a couple of improvements:
- Override new and edit views independently
- Array enum support using checkboxes (Phoenix: casting multiple checkboxes to {:array, Ecto.Enum} - #6 by marcandre)
1
tfwright
- Support for decimal field types
- Switch to component-focused override model
The second is a major change that will likely break things if you are using the old components option. Originally I conceptualized this as a “view” override using a render function MFA (similar to other option values) but that model turned out not to make much sense with LiveView, because views are by default fairly tied to their components if there is any state involved, which, in the case of forms, there is a good deal. So I decided to change the option value to a module instead, which makes it much cleaner and more straightforward to customize the form behavior when needed.
Migrating to the new model should not be difficult, all that should be required is to move your custom render function into a LiveView component module and pass that as value to the component you want to override instead. I updated the dev app with a more useful example of how and why to do this. Basically, the main non-cosmetic reason I’ve found is to be able to use virtual fields (like passwords) in the form. While working on this I considered some ways I might be able to support those automatically without overrides but for now this is the best approach to handle things like password encryption in form actions.
4
tfwright
Forgot to include it in my post above, but v0.5 also includes this: switch to type specific classes for index table cells · tfwright/live_admin@b269877 · GitHub
0
tfwright
For this most part this is a maintenance release with various minor bugfixes and a somewhat hefty refactor of some of the business logic. However it also includes some UI changes that might break CSS overrides, as well as a config change that brings the home page override API into line with the other views, so there’s a decent chance upgrading will require changing some code.
2
tfwright
Mostly QoL improvements but there are some notable changes/features:
- LV dep updated to 0.18 - if you are including as a separate dep you will need to upgrade
- Configurable list field rendering - previously all table cell contents were simply ‘stringified’ field values, now you can control how those fields are rendered. as usual the dev app has examples
- Add/remove embeds - no longer restricted to editing existing embed structs
There are also various UI changes, mainly an “actions” columns is now prepended to table rows for easier access to actions. Initially these were at the end of the row, and then moved to a per-cell drop down. I moved them back to a separate column mainly to simplify/facilitate markup in custom cell rendering functions. If anyone with stronger UI skills and/or opinions wants to take a crack at improving the look and feel, DM me 
There are some nice features in LV 0.18, especially the app level layout, that I think will help with feature I have planned around user settings, like css/themes, default prefix, etc, so that should be coming up next. If there’s something else you’d like to see, let me know here or in GH issues 
6
tfwright
0.8 is still in progress but, just a quick note because I have gotten a few questions and bug reports about this:
I have published a few bugfix releases so if you have encountered issues on 0.7.0, especially related to Phoenix/LV deps, I would recommend updating to 0.7.3. As any of you using LV in your own apps know by now, recent versions of Phoenix core libs contain a lot of changes to dependencies and several of them affect LiveAdmin.
In particular, if you are trying to use LiveAdmin with LV 0.18.x and/or Phoenix 1.7.x, please make sure to make these 2 adjustments to your Phoenix app:
- Ensure route helpers are still enabled by removing
helpers: falseoption fromuse Phoenix.Routerif necessary (should only apply to apps created with 1.7) - Ensure you are including
phoenix_viewin your deps
If you have completed both of those steps and are still encountering errors with LiveAdmin, feel free to open a new issue–but please use the bug report template with as much info as possible as these problems can be very hard to track down without adequate info.
Even better, if you are feeling brave try out the changes in main which should have better compatibility with Phoenix 1.7, obviating the need for the 2 step patch above. 
1
tfwright
Finally releasing v0.8 today 
Lots of subtle and not so subtle UI changes in this release, including a revamped nav menu. But also, if you’re not a fan of the changes, the nav menu is now one of the components that is available to override 
The new nav bar also contains a new link to manage the Session. LiveAdmin has had a session concept since the beginning, but until now it has been used only to store the prefix to be passed to function overrides so they would be aware of which tenant to run queries in. The new view exposes the session object, including a new metadata key, for editing/adding arbitrary data (using a new MapInput component for map fields). Since the session should be passed to any component/function overrides, you can use it to customize behavior for the current user in all sorts of ways. For example, the css_overrides config now accepts a MFA and the session will be prepended to the arguments. This means you can implement “css themes” using a function that inspects the metadata.
This session has been backed by a very simple Agent so that if you closed the window and later returned, it would remember which prefix you were using. However, due to the state being in a GenServer, this would be erased when that process ended, for example after restarting the app. 0.8 introduces a new session_store config, which allows you to provide your own module implementing the behavior for storing/loading session state. Since the init! callback receives the current conn object, you can use it to identify a logged in user and load/persist their session state to your app’s repo, for example a Postgres DB. That way, any session metadata that user has configured will be preserved even through restarts.
This was the last major feature I planned on adding before releasing 1.0, so please add any requests to the project’s GH issues if there additions you’d like to see included. Other than that future minor releases should focus on documentation, refactors and minor improvements, and bugfixes of course.
14
tejpochiraju
Thanks @tfwright and wanted to add a note here that LiveAdmin was the only admin UI that worked out of the box for our multi-app, multi-repo use case. I have documented the use case and approach in case it helps anyone else.
1