go-app
go-app copied to clipboard
maxence-charriere
FR: html2goapp converter
Many existing websites (e.g. #455) use, and design tools emit, HTML. Would it be possible to parse HTML and generate equivalent go-app code corresponding to that initial state?
//go:generate and other tool chain features could help keep things up-to-date, and I like the separation of concerns it might permit between designers and developers.
The generator would probably also need to populate some kind of lookup table to map an element path or id to a static object. It would also be great if we could munge names so the go code can fail at compile-time if required elements aren't in the HTML.
// compile error if generated HTML doesn't include corresponding element
_ = convertedHTML.ElementIDThatMustBePresent
If I understand well, your workflow would be:
- designer give html
- html is converted
- You add go logic like event handlers, states, etc.
What would be the workflow in the event where you already implemented the go logic and your designer submit you another version of the html?
I think the way it would work is that the go-app code would reference elements by id (or path or whatever). If the HTML file updated those ids, the code would have to change.
I think it's not necessarily that the designer is a completely separate person and they just throw HTML over the fence. More like the developer can use HTML as the canonical representation of the initial state in their codebase (gaining the ability to use tools or other people to create/manage that HTML), and the go-app code for that initial state is merely a generated resource. As with any change to the codebase, if you change one file (e.g. HTML) in breaking ways then you'd have to update references to it elsewhere, but that's true with the current situation where we build the initial state programmatically in go code.
That's why we'd need to generate static names, so we get compile-time errors for references that don't line up. After updating the HTML, one can generate the go-app code and if it builds, the references are intact.
There are a lot of non-breaking changes a designer can make in the form of layout, style, etc., that don't affect the IDs of buttons and menus and things the go-app needs to care about. So in the common case of layout/style changes, the new HTML would just work.
I did not get the time to work on this yet but look like @pojntfx made a tool for this: https://pojntfx.github.io/html2goapp
@vsekhar I pretty much ran into the same issue (tried to use Patternfly/Bootstrap/Carbon to get a boilerplate of each component, then manually translated it - which took a long time, and was quite a hindrance. React has this problem to a certain degree too (JSX != HTML after all) but in the case of go-app the changes where significant enough to prevent non-Go devs from converting). html2goapp is what I'm using for it now and it also has a CLI you can use for go:generate if you prefer :)
https://github.com/pojntfx/html2goapp
That looks awesome @pojntfx !
I wonder if it'd be possible to add static names matching the IDs, to get compile-time warnings and help with code completion.
Less important, but just a side thought: if Maxence agrees, it might make sense to contribute it back into go-app so the community can use and maintain it from one repo.
@vsekhar Thanks :) From my POV I'd be happy to contribute it back of course :+1:
Depending on the static names matching the IDs, what do you mean exactly? I'd be happy to look into it :)
@pojntfx repo looks great. I think it would make more sense to reference his project rather than include it. He should definitely get the credits and stars for his work.
@pojntfx A really nice project, thnks! @maxence-charriere I suppose it would be great to add a link to this project in https://go-app.dev/ .
