You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Today, the (*HTML).Node method returns *js.Object. For right now, this works well. But in the future, it could be bad for several reasons:
If server-side-rendering (Server-side rendering #23) happens eventually, we may want this to return some other data type (not sure what).
When WebAssemby is supported in Go, it probably won't expose JS through the existing github.com/gopherjs/gopherjs/js package. Or, at the very least, it probably won't be at that exact location (but rather in the stdlib somewhere). The return type will be different.
Now, one could argue that instead of overloading Node() to return an interface{} and making the caller deal with the type, we could instead use more methods (ServerNode(), WebAssemblyNode(), TestNode(), etc.) but I think this would lead to us pulling in too many unwanted dependencies for specific use cases of Vecty, to the point where changing the return type to interface{} is probably warranted.
If nobody objects, we can change the return type to interface{} and add an entry in docs/CHANGELOG.md to reflect it.
The text was updated successfully, but these errors were encountered:
My preference would be to leave it as is for the time being - if we have a concrete reason to change it, we'll have more understanding of why. Making people cast stuff without a good reason is not doing them any favours.
This sounds like a change that you should defer doing until the very moment you actually need this. Doing it sooner has no benefits IMO, but has downsides in that you might end up changing your mind or gain additional insight by the time you need it.
Today, the
(*HTML).Node
method returns*js.Object
. For right now, this works well. But in the future, it could be bad for several reasons:Now, one could argue that instead of overloading
Node()
to return aninterface{}
and making the caller deal with the type, we could instead use more methods (ServerNode()
,WebAssemblyNode()
,TestNode()
, etc.) but I think this would lead to us pulling in too many unwanted dependencies for specific use cases of Vecty, to the point where changing the return type tointerface{}
is probably warranted.If nobody objects, we can change the return type to
interface{}
and add an entry indocs/CHANGELOG.md
to reflect it.The text was updated successfully, but these errors were encountered: