hexops
Consider changing (*HTML).Node return type from *js.Object to interface{}
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 (#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.
- It's possible that once we figure out testing (#29), we might want it to return some mocked DOM object type.
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.
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.
Something to figure out before 1.0, but after Go gets wasm support and after we figure out what to do about server-side-rendering.
https://github.com/gopherjs/vecty/tree/sg/node-interface for if we decide to do this eventually. (wrote it before your comment)
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.
