Phoenix 1.7 has radically changed the generators again in a way that makes it hard to adapt Mandarin. Maybe I should just quit trying to support the idiomatic project format in new phoenix versions?
You might find this useful?
2 Likes
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 Like
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.
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 Like
