Support for fine-grained internal event handling (element creation, re-creation, removal)

[hexops]

Support for fine-grained internal event handling (element creation, re-creation, removal)

[slimsag]

HI @pdf ! First, cool username :)

Second, yes, I've been aware of this issue for a while and agree a Mounter interface would resolve it. If you don't mind, I'd like to get into the nitty-gritty details of why you need this. For example, could you point me to the exact JS library / relevant code that you would need to interoperate with?

There are absolutely caveats to working with Vecty on an element, e.g. the case of elements being replaced as you already stated. In your situation, would you have to deal with that element-replacement situation?

I'm OK with adding a Mounter interface to get access to the underlying element. But only if we have a really solid real-world use case that can't be solved some other way more cleanly. (I want to avoid the React situation of having a million different *Mount *Unmount handlers that have subtle differences)

[pdf]

The first example I encountered this with was looking at bringing in some UI enhancements, like Materialize or Material Components, both of which expect to enhance the DOM with JS.

I have it working in a rudimentary fashion via a very naive first pass at Mounter in 462e338 , though I need to look at it in more detail, especially into how to handle replacement behaviour - I basically just slapped the Mount call everywhere the DOM was updated to get up and running, though this is almost certainly not correct.

Material Components, for example, requires calling a destroy function when the element is removed from the DOM, which makes me think maybe we'll be leaking something if replace is performed without Unmount, though I haven't looked into exactly what they're doing in destroy.

Hitting replacements seems pretty certain when dealing with dynamic lists and the like from my brief look at the vecty code, but I just started to have a poke at GopherJS/vecty yesterday, so I'm still in exploration mode.

[pdf]

For my use-case, Unmount definitely needs to be called on node replacement, and I've updated my branch to reflect this in b50ec7c

[slimsag]

So, the thing that I wanted to uncover here has been uncovered. In short:

1. You need Mount to be called and give you access to the DOM element -- I'm OK with that.
2. You need Unmount to be called on each node replacement -- but that is incredibly misleading because the component hasn't been 'unmounted' -- it's just had it's element swapped out. I would only expect Unmount to be called when the component itself is no longer being rendered entirely. So this is tricky behavior to nail down...

[pdf]

I agree, what I'm working with currently doesn't feel right at all. If #76 was implemented though, I think replacements would go away entirely, except for when components are actually mounted/unmounted.

[slimsag]

Something I've been thinking of over the past couple of houors: I would be OK exposing a more fine-grained API for implementing things like this if it wasn't exposed through the public Go API / was more hidden away as to not mislead new users.

I'm wondering if we could expose it (and allow access to it) only via JS itself. e.g. perhaps via dispatching an event or checking for some global variable (I'm not suggesting this yet, just throwing out ideas). Another option would be maybe like a github.com/gopherjs/vecty/internals package that allows hooking fine-grained things like this.

We'll def. come up with a solution :)

[pdf]

I think Mount/Unmount would probably be sufficient if node replacements were removed, except where a node is actually replaced with a different type.

[pdf]

Now that I understand more of what's going on during render thanks to #76, I believe ca1025f is pretty much correct, though I need to do some testing - I have a feeling we're already not unmounting everywhere we should.

[pdf]

I believe the current behaviour for Unmounter is incorrect. In the case where two components return the same HTML tag, the previous component will be replaced without Unmount being called.

Only way I can see to produce the correct behaviour here is via reflection. I've implemented this in 3df8654, and I'm now seeing consistent Mount/Unmount behaviour when I'd expect it.

I'd like to cache the reflect.TypeOf result, but I've hit what appears to be a GopherJS bug (see the commented block), though I'm having trouble producing a minimal test case.

[pdf]

If you have any thoughts on the odd GopherJS behaviour above, I'd be keen to hear them. Alternatively, would you be okay with accepting a PR for this implementation, sans-caching? I'd like to get this out of my tree if possible so that I can start pushing some functional code.

[slimsag]

@pdf Sorry for the latent response, I've been super busy recently. Also, if possible, let's try to keep issues properly scoped :)

1. reflect.TypeOf: If I had to guess, the reflect.TypeOf result would be useless to cache because it is probably already stored as part of the JS object or can be auto-determined cheaply somehow by GopherJS. Regardless, I'm not really sure / don't work on gopherjs itself. You should open a GopherJS issue for this: github.com/gopherjs/gopherjs/issues/new
2. Let's not make invalid Unmounter behavior be globbed into this issue, I've created #85 just now to track this.

That means that this issue is about:

1. A Mount callback that provides access to the DOM element after it is created.
2. A Unmount callback that provides access to the DOM element prior to its destruction, unlike the current one.

Which of those two do you believe you will need for your use case? I can prioritize based on that.

[pdf]

I understand, time is the most precious commodity.

1. I've taken a look at the GopherJS reflect code, and it looks like they're doing caching on the first call to reflect.TypeOf there, so we can indeed avoid it here. I'll try harder to produce a minimal example of the undefined issue discovered here to report upstream, though I'll have to spend more time in the debugger to work out precisely how this is triggered, as it did not happen in my more trivial tests.

2. I can split this into two PRs if you like, however there is some overlap in the code, so one PR will have to depend on the other.

I need both callbacks. However, they're useful for more than just accessing the DOM - I'm using them to manage store subscribe/unsubscribe as an example.