Improve hooks naming convention

[WebReflection]

Hooks are great but not super user-friendyl to deal with so we discussed a way to better separate their namespace.

Proposal

• split hooks into main and worker
• use onReady for both cases:
  • on main it means onInterpreterReady: there is an interpreter and it's just about to run its code
  • on worker it means the xworker dance has been completed and all the features to enrich the worker world are available out of the box
• use main.onBeforeRun, main.onBeforeRunAsync, main.onAfterRun and main.onAfterRunAsync
• use worker.codeBeforeRun, worker.codeBeforeRunAsync, worker.codeAfterRun and worker.codeAfterRunAsync

This should both help understanding the different nature of the main VS worker fields + it clears out hooks that requires strings as code

[antocuni]

+1 for all of the above.
Two questions:

1. what is the relationship between onReady and the py:ready event which is raised by pyscript? Do they map to the same concept or two slightly different ones?

2. I don't really know whether it's a good idea, but we might consider hooks.ui.*, hooks.mainthread.*, hooks.uithread.* in case hooks.main sounds "too generic".

[WebReflection]

1. consumers that don't need hooks to retrieve both the wrapper and the element can simply add an event listener instead of dealing with the module + that event listener can be added even without the module. onReady is triggered pragmatically to allow hooks to pre-instrument or pre-react to elements via the wrapper utilities any way they like, while the py:ready event is more like a passive listener that simply communicates the currentTrget element is going to execute its related code. In short these are companions, not overlaps.
2. everything in the docs disambiguate workers with main thread and so does the Web standard / documentation here and there. I think main works fine.

[antocuni]

• consumers that don't need hooks to retrieve both the wrapper and the element can simply add an event listener instead of dealing with the module + that event listener can be added even without the module. onReady is triggered pragmatically to allow hooks to pre-instrument or pre-react to elements via the wrapper utilities any way they like, while the py:ready event is more like a passive listener that simply communicates the currentTrget element is going to execute its related code. In short these are companions, not overlaps.

yes but my question is: is the py:ready event raised at the exact same time that the onReady callbacks are called, or they are two similar-but-different phases?

[WebReflection]

py:ready is rised when the worker and its xworker setup is ready and when the node is going to execute ... there's no documentation, example, or mention to the fact these are equivalent to any hook so I am not sure what is your question or why you'd expect hooks and events to be the same ... they can't be the same by definition because on the main JS is sync so one or the other gotta fire before the other + hooks are tools to let you control everything you like, even preventing py:ready to bubble up. In short, hooks are about controlling the JS life-cycle of the element, events are just notifications around the executing code: before and after ... that's it.

[WebReflection]

if it helps anyhow:

• py:ready is triggered when all hooks already executed and the content of the script or tag is going to be executed ... nothing literally happens between the event and the code execution
• py:done is triggered when all hooks already executed and the content of the script or tag has been executed

changing order anyhow is not wise nor possible, because hooks gotta run, they can't prevent events out of the box, and events are there only for plugins purpose, not for internals, so these are decorations around hooks and code lifecycle.

I hope this clarifies. This issue is also kinda going off-topic though ...

[WebReflection]

P.S. if you think this should be better documented please file an issue, as I can copy and paste my previous answer to clarify for anyone the current state of hooks/events affair, thanks! ... or maybe I just do that ...

[WebReflection]

P.S.2 if you want to know why hooks are always executed before py:done is because these are part of the code to run, these can't run after the code already did run. The py:ready instead is before the node gets setup so that advanced hooks there could instrument the node differently and always before the event is triggered.

[WebReflection]

HA ... to provide even more context, worker hooks as Python code run after py:ready because the event is from workers with the worker detail ... that's different in main so there we have a different behavior but that's only because main doesn't inject Python code (not yet, we could have codeBeforeRun in main too) but I don't think this should be changed by any mean, as it would drop the ability to control and instrument the node or the wrapper before code runs on main, something not possible in workers as we can only inject code in there. Is your quest to want events running before hooks at all costs?

[WebReflection]

I am going to work on the issue without touching the when part of the conversation, if that's OK, still curious to know if your quest was around consistency for when events get triggered around hooks, considering that main and worker are inevitably different in terms of possibilities or execution logic (one is callback, the other one is just code).