Vecty has since day one been a a true re-imagining of what it means to bring reactive frontend concepts to Go: unlike many other Go frontend approaches / libraries / frameworks, Vecty started as an idiomatic Go approach and not merely e.g. a port of React or Vue to Go as others have done (which, IMO, leads to less Go-developer friendly APIs)
Still, Vecty has a few core principles that are implemented in a way I consider somewhat "weak": they show the limitations of expressing the (quite complex) functional programming concepts like used in React, in Go, in a nice way. In specific:
Properties vs. state: Today, both are expressed in your component struct as fields but the struct tag vecty:"prop" must be used to denote if a struct field is to be considered retained component state or input to a component (a property.) This feels "magical" and is a little odd-to-discover as a Go developer I think.
Component type mixing: Today, components must embed the vecty.Core struct in their struct as a form of inheritance.
Reflection usage is generally frowned upon by the Go community, and while our usage here is quite intentional and specific (there truly isn't a better objective way to express these things), it would be nice to avoid and has been a source of friction for using Vecty in e.g. TinyGo (although that has recently improved substantially).
This issue is to pose the question: how do Go type parameter generics fundamentally change the way in which we express the above? From a quick glance, it seems likely that this could enable us to parameterize most of the component types - but it's unclear as of yet how nice of an end-user API this could produce or not.
Go 1.18 will introduce type parameters: https://github.com/golang/go/issues/43651
Vecty has since day one been a a true re-imagining of what it means to bring reactive frontend concepts to Go: unlike many other Go frontend approaches / libraries / frameworks, Vecty started as an idiomatic Go approach and not merely e.g. a port of React or Vue to Go as others have done (which, IMO, leads to less Go-developer friendly APIs)
Still, Vecty has a few core principles that are implemented in a way I consider somewhat "weak": they show the limitations of expressing the (quite complex) functional programming concepts like used in React, in Go, in a nice way. In specific:
vecty:"prop"must be used to denote if a struct field is to be considered retained component state or input to a component (a property.) This feels "magical" and is a little odd-to-discover as a Go developer I think.vecty.Corestruct in their struct as a form of inheritance.Reflection usage is generally frowned upon by the Go community, and while our usage here is quite intentional and specific (there truly isn't a better objective way to express these things), it would be nice to avoid and has been a source of friction for using Vecty in e.g. TinyGo (although that has recently improved substantially).
This issue is to pose the question: how do Go type parameter generics fundamentally change the way in which we express the above? From a quick glance, it seems likely that this could enable us to parameterize most of the component types - but it's unclear as of yet how nice of an end-user API this could produce or not.