Support Component initialization about purescript-halogen

[natefaubion]

One possibility is by providing an API to virtual-dom hooks, you could create an onInit hook that only runs once on a particular element. If we could put hooks in attributes, this would provide a nice event-like API for initialization. One possible implementation is in the hook method just check if the previous value (3rd argument) is undefined, and run the initialization function. On subsequent diffs, the previous value will be there.

[garyb]

Hooks are triggered based on reference equality I think, so wouldn't that potentially cause some issues? Or is that where you're going with using the 3rd argument to check if they're required?

[natefaubion]

Yeah, on the first hook, there's no previous value, so you can run it. Subsequent hooks wouldn't run the initialization callback since there would be a previous value. You could potentially trigger it multiple times if you removed the attribute, and then added it again, but I think that would be expected behavior.

[natefaubion]

Would it make sense to define stateful hooks/widgets as an SF1, with an internal state, an input representing a transition (eg Hook | Unhook), and producing effects?

[jdegoes]

Information has to flow between a widget implemented by a 3rd party lib, and its container; e.g. for purescript-ace, you have to create the widget, set the content of the editor, and be able to retrieve the content of the editor, as well as miscellaneous other things. This seems to require Component like ability, though how to tie that to the vdom widget is not clear to me.

[garyb]

Actually, that reminds me. There is a slight problem with the hook approach (I think I mentioned this elsewhere too) - hooks fire during patching, but for 3rd party components you would probably want to wait until after the DOM has been updated before running init - they often require an element to exist in the DOM, have dimensions, etc.

[jdegoes]

they often require an element to exist in the DOM, have dimensions, etc.

👍 Yeah, that.

[natefaubion]

Actually, that reminds me. There is a slight problem with the hook approach (I think I mentioned this elsewhere too) - hooks fire during patching, but for 3rd party components you would probably want to wait until after the DOM has been updated before running init - they often require an element to exist in the DOM, have dimensions, etc.

I don't think you can ever depend on a node existing in the DOM with virtual-dom. Maybe with update for Widget, but even that can be triggered without anything touching the DOM. In init you are creating the node, but it doesn't exist anywhere yet on the page, so its useless for layout. With both Widgets and Hooks you are going to have to use some sort of nextTick if you depend on it existing for layout purposes.

[garyb]

Yeah, the way I've done it before (in a non-PS-suitable way) is to have the hook/widget register itself with a central authority on init or hook as needing initialisation, and then immediately after the diff is applied to the DOM the registry is checked and any pending widgets are initialised "for real" at that point.

[natefaubion]

In that case, why would using a Hook be a disadvantage?

[garyb]

I guess I was thinking an onInit hook would need some magic, but I read your original post as suggesting a way of allowing hooks in general, one of which being onInit - maybe there is a way to give hooks enough power to do this kind of thing.

[paf31]

What's the goal here? Do we want the initializer to run when runUI is called? That should be simple.

Or do we want it to run on initial render? I think that is trickier and would need some kind of custom hook, right?

The weird thing about the second case is that the initializer could run twice in some cases. Consider a "card panel" with two states given by the Left and Right constructors of the state (Either a b). If we switch from Left to Right, and back to Left, the initializer for the Left card will be called again, but that's probably not the intention.

[jdegoes]

I assume this would be used for things like, "go do an AJAX request to get a list of items we can use to populate some list," and stuff like that. So probably the first one, but interested in @natefaubion's use cases.

[natefaubion]

the initializer for the Left card will be called again, but that's probably not the intention.

This depends on how a hypothetical install works. If a component's existential state persists even if you remove it from the virtual DOM (and then add it back), you can tell in the component if you need to run the effects again or not, but you still need the impulse to check. That may be when you call runUI or may not. For example, lazy loading tabs. You'd want to run effects the first time the tab is loaded. I think this goes along with making Widget as powerful as Component. You probably also want the inverse. A Widget has insight and control over the lifecycle of its element. Wouldn't a Component also want to know when its mounted/embedded?

[jdegoes]

A Widget has insight and control over the lifecycle of its element. Wouldn't a Component also want to know when its mounted/embedded?

True, maybe such unification would solve the issue.

[paf31]

So shall I just add an initialization hook then, as an Attr? It seems like it would deal with these cases (lazy loading tabs etc.).

If we want one-time initialization to happen, I'd rather have the user use the hook and manage the "is loaded" state manually, since it will force people to think about asynchronous loading of data (as opposed to having Component support an asynchronous initializer).

[jdegoes]

@paf31 This change only included initialization, right? Should we open another ticket for finalization?

[paf31]

@jdegoes No, I put in a change to support finalization too, last night.