Migrate from templates to Gomponents #103
Conversation
|
Thanks! Glad to hear you like it. As I mentioned in the linked issue, I was not a fan of it at first but the headaches and limitations of Go templates kept bringing me back to it and I finally decided to give it a full try and I'm very happy that I did. I like the end result much better and I think it will improve this project substantially. It wasn't too much work once I got the hang of it and built out the re-usable components, layouts, and overall patterns (plus this HTML converter is awesome: https://gomponents.morehart.dev/). I should be able to wrap this up within a week or two, I think. If you do have any specific feedback or thoughts/opinions about gomponents, templating, frontend, etc, please share on the linked issue. |
|
Code is all done, I think. Just need to update the README. |
mikestefanello
changed the title
|
Just why? Returning to this project after 4 months and all is changed... Sorry, I can't follow this. Anyway, your project, your freedom. |
|
@neilyoung I completely understand the reaction. When I first came across gomponents I was strongly against the idea. Please read through my thoughts about the switch in the readme. After spending a lot of time with it, I personally feel it is a major improvement over standard templates. I do not think the dynamic admin entity panel would even be possible without it - the templates are just way too difficult to use to produce re-usable components. Even just comparing the standard form examples before and after should be quite clear.. it was very cumbersome to produce a new form with all of the required things for inline validation, etc. Now, each form component is generic and provides everything without you needing to do anything at all. I suggest spending some time with it and keeping an open mind. I would be surprised if you didn't reach the same conclusion as I did after a little while. I'm also working on swapping Bulma for DaisyUI and having a ton of useful, re-usable components is really illustrating the growing benefits of using gomponents. I find the DX and productivity when creating additional pages to be substantial. Let me know what you think. |
|
Thanks for your elaborated comment. Indeed, there might be a benefit, comparing the new structure with the old. I unfortunately have spent a lot of time with additions to the old structure back in February, I have some doubts to be able to start from scratch again. I simply have no idea where to start with the refactoring... |
|
Well, remember, with Pagoda, it's just a starter kit - so once you start, the code is yours and it's highly unlikely you'd want to bring in changes going forward. It's not like a library or framework where you continue to stay up-to-date with it. It's completely up to you what, if anything, you want to attempt to bring in. If you have a project going already and it's using templates, and you're happy with them, then definitely stick with it. It depends on the size of your project, but migrating to gomponents, if you want to, is quite easy once you get the hang of it and once you have things structured the way you want. Once I became familiar with it, porting the HTML was actually quick and easy. I found this tool to be incredibly helpful. |
|
Other than that I have no doubt, that something like your user entity can be build with old style go templates. That is IMHO pretty common stuff, what should be that difficult? But can the new structure deal with several forms per page? With pages like this one the fun begins (inspired by Laravel/Jetstream) 
|
|
Yes, I checked this tool out. It was able to convert that complex page into components. Do you think it would be possible to have both, the old and the new way in order to get familiar with this? EDIT: No it is not, obviously. I tried to use pgk/ui and changed one handler to make use of it, but couldn't overcome 500. Even though I see your point, I fear I can't jump on that train. I would have to rewrite nearly everything, and since there is no real migration receipt, I'm lost with that. So the bad taste remains to bet on a dead horse (again)... |
|
I'm not sure what you mean by dead horse or again. Can you elaborate a bit more on that? I haven't tried to mix gomponents and templates. I'm sure it's possible but the DX will probably not be too enjoyable. I'd imagine you'd need to render the overall response with a template but pass in rendered gomponents (strings) to the templates as variable and inject them where you'd like. |
|
Oh disregard that comment. You know how happy I was to have finally found something, which was using the power of go and HTMX to mimic the reactiveness of modern frontend apps server side. And I'm sure the step to Gomponents is a logical step to drive this even further. But it is also a big abstraction away from plain HTML, which was at least recognizable in old times. In other word: This is a breaking change, and I will have to spend hours and hours to follow to have at least a chance to follow the technical progress on your side. This is impossible to me now. That's why I'm riding a dead horse now, and I'm pretty alone with this, I guess. Not your problem, so please ignore that. |
|
I felt neilyoung's pain initially too because I had to go through the refactoring exercise myself, but the switch to gomponents is a huge improvement over the html templates. Thanks mikestefanello for a great project. |
|
@Jimmy99 Thanks for encouraging me. Maybe once there is a slot I’ll reconsider this. |
|
@Jimmy99 As always, thank you for the great feedback and praise. @neilyoung I somewhat understand the frustration, but I want to reiterate that this is a starter kit and what you're experiencing is very much a feature and not a bug. This is meant to get you started and be as productive as possible out of the gate. Once you clone this kit, the code is yours, and you, for that particular project, never look back at Pagoda. It's completely impossible to ever support or expect to bring in changes because you're cloning an entire app and, by design, you will change close to everything. The alternative is using a complete framework, such as Gobuffalo. I'm not saying one approach is better than the other, just that they are different. With a mega framework like that, you do expect to be able to continue to upgrade to future versions, bring in changes, etc, but at the cost of betting on a potential "dead-horse" (lack of maintainers), being locked in to strict systems and patterns, a lack of flexibility across the board, possibly out-growing it, etc. You can't have both, unfortunately. This situation is no different than if Pagoda never changed, and you came across gomponents yourself, and decided you wanted to switch to it. From the feedback I've received, I don't think a single person has ever been entirely happy with every single decision I've made for this project - whether that's about which libraries to include, the coding patterns I've introduced, or whatever else. That's also impossible - and by design, that you can easily and freely swap in/out whatever it is you want. Whenever I make a major change, I tend to create a branch prior to merging, so people can easily reference the project before the switch - here is the branch before the switch to gomponents. So, you can keep using that for future projects, if you want. Pagoda started out as, and will continue to be, an exploration in what I would personally want if I (alone) were to decide to build out a web app with Go today. It will evolve over time, as long as I keep putting in the time to work on this, as new libraries, frameworks, concepts, technologies emerge and as my personal tastes and personal experience changes. In fact, I'm close to doing what I didn't think I would consider, bringing in DaisyUI/TailwindCSS. That will also be another pretty major change. And tying back to this original conversation, I would never have considered doing this without gomponents. It would have been way too difficult and the result would be a mess, I think. And if I had to ensure that all prior users of Pagoda stayed perfectly up-to-date, change would be impossible. |
|
All fine with me. Got that Edit: I’m not frustrated at all. I’m happy with what I have here and maybe some day there is a time to make the switch. But I saw there is still no support for more than one form on page OOB, even this is a low hanging fruit. But as of today I’m not even able to do a PR to add support for this, because the caravan has moved on 😀 |
|
I have that issue open and I will try and get to it. |
|
Thanks for considering this :) |
Overview
Despite all of the work done to make Go templates as easy and flexible to use as possible, they still fall quite short. This is currently an attempt to migrate the entire project off of Go templates and on to gomponents.
Discussion
#75