You might find this useful?
mayel
tmbb
I’d like to ask the community how useful people think a generator-based admin/CRUD system would be, and how likely they would use it in their projects. Mandarin and forage aren’t going anywhere because I’m using them myself, but I wonder if I should spend any efort to adapt it in order to beidiomatic for Phoenix 1.7. The hardest part is of course the adaptation of the Auth system, which is very complex, and a translation into the new “vertical layout” isn’t easy at all. Also, with the new liveview-based generators, the layout is already “more vertical” than it is with the default MVC file layout. Still, not vertical enough for me, as too many unrelated files are dumped in the same directory.
I also have a number of gripes against the new generators, idiom changes and the new liveview-based crud.
I have been dissatisfied with the liveview-based generators in general, especially the decision to have the form appear in a modal on top of the items list. I think that decision brings too much additional complexity in terms of JS and CSS and is not useful to my use cases. Although I understand that it might be useful in other cases, it seems like too much complexity to bundle by default.
The CoreComponents file is a good idea, and I could make forage work with something like a CoreComponents file, but that would require the CoreComponents file to implement a behaviour ti ensure it had all of the required functions.
I also don’t like much how Tailwind is now proposed as gold standard way of styling your application, and the way the generators seem to have been created with tailwind in mind. I spent a long amount of time writing a CoreComponents file based on bootstrap with vanilla CSS (not tailwind) and it wasn’t easy at all. And worse of all, the way that local validation (before contact with the server) works required me to “manually” (actually programatically with a script) edit the bootstrap CSS files to add some classes.
These changes make me somwhat unwilling to rewrite the Mandarin generators again for 1.7, unless there is some actual demand for Mandarin-like functionality for Phoenix 1.7. Of course the pages generated by Mandarin do work (phoenix is backward-compatible between 1.6 and 1.7), the “problem” is that the layout and conventions would clash with the new conventions.
1
dimitarvp
I had a phase during which I loved such libraries / frameworks but quickly found out that the generated code bit-rots, a lot, and quite quickly too (as you yourself also found out).
This outlines one general gripe with programming tools that I have for a long time: they can generate code but they cannot edit it. 
Still, I would love for Elixir to have one proper CMS / “backend” solution (in business terms this means the “under the hood” dashboards where they can control how the customer-facing parts of the app work). It would build extra goodwill towards Elixir so TL;DR if you are willing to invest in this, do it mostly for marketing purposes.
…Or luck out and land a lucrative contract with a company that’s stuck with one of them and you will maintain and extend it for a hefty sum. 
But my vote goes to “yes”: IMO pick one of both and modernize it.
EDIT: As for Tailwind, I get your point that not everyone is willing to use it but if I remember correctly it was mostly picked up for the ability to rid us of using webpack (hope I am not unwillingly lying here) and maybe because it requires less class decorations (unsure on that one, it was months since the last time I touched frontend code). Again I get if you don’t like it but I am not sure there’s something much that can be done except just use Bootstrap and webpack yourself; Phoenix is not stopping you.
0
tmbb
One of the things I love the most about such tools for Elixir is that the new source manipulation features allow for limited changes to AST and source code (and sometimes pretty complex changes!).
I have tried to develop a solution for that: CodeGen - simple, succint and customizable code generation for your libraries. This library should only generate the code you ask it to generate, and keep the rest as a hidden AST. You can dynamically ask the library to dump the source code of a given group of functions in the module’s source code. I believe it would be interesting to convert Mandarin into something that uses this.
Oh, but I am not using webpack at all! I am using a much more “interesting” solution. I’ve written a script that downloads the bootstrap theme and the “standard” bootswatch themes (which work well with default bootstrap classes without any customizations and can be swapped with each other) and after downloading the files uses Regexs to “parse” critical parts of the CSS file contents, namely the highlight colors. Then, using the colors it has extracted from the file I build a new CSS class for validated/unvalidated forms and insert it into the minified CSS. Everything is done in Elixir, of course. The generated CSS files modified in such a way are then shipped by the library and can be served directly as static assets. This is either very cool or totally horrifying, but I prefer the first interpretation.
1
tmbb
I have began working on Mandarin again, and I’ve decided to go all in on LiveView. Everything (show, edit, browse, delete) is a LiveView, and I use the PubSub to send events from one LiveView to the other so that people can work concurrently and be notified of changes that happen on other sessions.
As an example of what’s possible, here is a screencast of two windows where the edits made in one window are propagated to the other window.
This is mostly done using generators, so that the code can be easily customized. If such granular notifications are not required, it’s easy to delete them from the code. Video here: https://imgur.com/a/8YhAfbR
The only thing left is handling some problems with the pagination widget I’m using.
2
BartOtten
Know that the LiveView generators will change in the next release. Can’t link to the diff as GitHub is having problems in my region.
I do know the modals are gone (even from core_components)
0
tmbb
I had no idea, but I have long quit trying to match the enormous amount of churn in the default Phoenix components. My components and generators are now my own thing, and they share no actual code with the Phoenix generators themselves. I don’t reuse any actual Phoenix code. Everything is set up so that it can work independently of what Phoenix does to its generators.
1
tmbb
BTW, if you’re talking about removing the thing where you were supposed to edit forms from the “index view” in the shape of a modal, then I’m all for it! I’ve always thought that to be very awkward from a UI point of view.
0
tmbb
Just to bem a litte clearer: initially, I’ve tried to match the Phoenix generators pretty closely, and I’ve even wrote a script to git pull the source from the Phoenix repo and replace the namespace to put ir into my own project, with the idea of occasionally adding what few changes new Phoenix releases wetre to introduce.
But then I’ve seen the switch from bootstrap, to milligram.css, to tailwind and then the CoreComponents module (as well as the phx.gen.auth generators, but that one was actually great!) and decides I’d just stop keeping up with it. Developing generators os extremely hard because they are so hard to test: you basically have to run then on a different project and ser if they work, and you have to write a weird form of “meta-elixir” which os actually elixir with some parts replace by eex tags
0