Explore how Go generics / type parameters could improve Vecty

[slimsag]

Go 1.18 will introduce type parameters: golang/go#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:

• 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.
• (internal) component type equality: Today this is checked via reflection.
• (internal) component copying: Today this is checked via reflection.
• (internal) component property copying: Today this is done via reflection + struct tags.

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.