hexops
All DOM properties must be comparable
When using vecty.Property(), a panic is caused when the value is an uncomparable type.
https://github.com/gopherjs/vecty/blob/19a11ec3acc3ae6c2e095b1ace2b7134c5f28c10/dom.go#L253
comparing uncomparable type func() error
One solution could be to provide an interface the user can satisfy to prove equality of a property. Otherwise, this should be a documented limitation.
One solution could be to provide an interface the user can satisfy to prove equality of a property.
I'm not sure how that would work, but we could probably check the type and unconditionally apply uncomparable types.
Could someone clarify for me which properties are allowed to be non-comparable types?
My initial assumption was that only valid DOM properties could be specified with vecty.Property but I see the referenced commit is using properties like vecty-material-ripple and I'm curious what the use case is. I guess the use case is just associating arbitrary Go data with elements?
I guess the use case is just associating arbitrary Go data with elements?
That's correct in my case. More specifically it's for including Go data from outside of a component that needs to store the component's rendered HTML at the Apply phase, and then use the *js.Object provided by Node() at the Mount phase of the component's lifecycle. I wanted to do this truely arbitrarily, so this type of Applyer could be used with any component (not there yet in the commit/code mentioned earlier). The *js.Object of the element is needed because I'm using a binding to an external JS library -- besides that requirement I'm very open to alternative approaches. Using an Applyer seems very intuitive so far.
Edit/Summary: The use case is to hook into an arbitrary component's Apply and Mount lifecycle events, specifically so that the rendered element's *js.Object is available to arbitrary Go code. In this case a JS library binding.
Could someone clarify for me which properties are allowed to be non-comparable types?
Whilst user-defined properties are somewhat frowned upon they are valid, and may contain arbitrary data. Though I can't think of any standardised properties that accept incomparable types off the top of my head.
I can't say I'm much of a fan of using the DOM as storage like this - I'd much rather see this sort of thing stored in the virtual DOM as a field on a vecty.Component.
@bzub I think what you really need here is an applier that can subscribe to mount/unmount events of an *vecty.HTML. See #202.
That's exactly what I've shifted toward @damz. So I think this issue is primarily about adding documentation and/or a more useful error message so users doing weird things with vecty.Property() can save some time when they encounter the uncomparable type situation.