Currently I've been working on a CLI tool [1] for my WebASM UI library [2] with the idea that all the gluecode generating stuff is abstracted away in nice CLI wizards.
Essentially like yeoman back then, to bootstrap your webapp and all the necessary files more easily.
Currently I am somewhat stuck because of Go's type system, as the UI components require a specific interface for the Dataset or Data/Record entries.
For example, a Pie chart would require a map[string]number which could be a float, percentage string or an integer.
A Line chart would require a slice of map[string]number, where each slice index would represent a step in the timeline.
A table would require a slice of map[string]any where each slice index would represent a step in the culling, but the data types would require a custom rendering method or Stringifier(?) of sorts attached to the data type. So that it's possible to serialize or deserialize the properties (e.g. yes/no in the UI meaning true/false, etc).
As I want to provide UI components that can use whatever struct the developer provides, the Go way would be to use an interface. But that would imply that all data type structs on the backend side would have this type of clutter on them attached.
No idea if something like a Parser and Stringifier method definition would make more sense for the UI components here...or whether or not it's better to have something like a Render method attached per component that does all the stringifying on a per-property basis like a "func(dataset any, index int, column string) string" where the developer needs to do all the typecasting manually.
Manual typecasting like this would be pretty painful as components then cannot exist in pure HTML serialized form, which is essentially the core value proposition of my whole UI components framework.
An alternative would be offering a marshal/unmarshal API similar to how JSON does it, but that would require the reflect package which bloats up the runtime binary by several MB and wouldn't be tinygo compatible, so I heavily would wanna avoid that.
Currently looking for other libraries and best practices, as this issue is really bugging me a lot in the app I'm currently building [3] and it's a pretty annoying type system problem.
Feedback as to how it's solved in other frameworks or languages would be appreciated. Maybe there's an architectural convention I'm not aware of that could solve this.
[1] https://github.com/cookiengineer/gooey-cli
[2] https://github.com/cookiengineer/gooey
[3] https://github.com/cookiengineer/git-evac