x-defer, x-reloaded, Control components lifecycle

[tanthammar]

It would be great if one could take control of a components lifecycle,
a missing piece when Alpine has to co-exist with other libs like Turbolinks or any js that loads serverside rended html fragments that could contain alpinejs.

(Revised edition, after comment from @SimoTod )

Directives

x-defer
x-reloaded

Hooks

Alpine.reload( refName )

Event handler:

reloaded( ) { ... }

Example:

inline

<div 
     x-data
     x-ref="myComponent"
     x-defer="someWindowEvent"
     x-init="console.info('myComponent is initiating')"
     x-reloaded="console.info('myComponent was reloaded')"
     x-cloak
</div>

js

<div 
     x-data="myComponentScript()"
     x-ref="myComponent"
     x-defer="someWindowEvent"
     x-cloak
</div>

function myComponentScript() {
    return {
      reloaded() {
         console.info('myComponent was reloaded')
       }
    }
 }

document.addEventListener("myEvent", function() {
  Alpine.reload('myComponent')
})

x-defer="windowEvent"

The x-defer directive should tell Alpine to defer the initial loading to the named window event. Would require x-cloak to avoid flickering.

Alpine.reload(refName)

Should trigger alpine to reinitiate the named component and run the x-reloaded directive.

window.deferLoadingAlpine

I've seen that there are topics on taking control of Alpines loading state with this method but this feature request targets individual component control instead of interfering with all.

[KevinBatdorf]

I think anything that allows for Alpine to be extended through plugins and other abstraction will be useful to me.

Personally, I'd also like all Alpine events to be fired on the window, for example when Alpine discovers a new component and about to initialize it.

Here's some examples of current ways to accomplish some of the above, in case it's useful now to someone:
Load in "named" component: https://codepen.io/KevinBatdorf/pen/yLexNKq
Deferred component loading: https://codepen.io/KevinBatdorf/pen/vYLzOOY
Reload component: https://codepen.io/KevinBatdorf/pen/WNrgvQj

Alpine.on() would basically just be x-on though, right?

Looking forward to thoughts from others.

[KevinBatdorf]

@tanthammar I removed the comments about the PR as it's not necessary.

Alpine should discover the components as you drop them in (as long is it's not inside x-init).

When the html fragments are injected to the DOM, Alpine does not know they exist

Can you share some code where this is happening?

[ryangjchandler]

@ryangjchandler Alpine only watches for nested components and not surrounding elements, right?

@tanthammar The dev tools is a little helper I wrote. It needs a lot more work so I'm not making it super accessible yet. Hopefully I'll have time soon though. You could use it but note it could change at any moment.

Just add this along with the code snippet you pasted
https://codepen.io/KevinBatdorf/pen/236afb4466871b6444ce7f1ceebaf89c.js

There is a global mutation observer here:

alpine/src/index.js

Line 51 in d37e32e

listenForNewUninitializedComponentsAtRunTime: function (callback) {

[KevinBatdorf]

@ryangjchandler Yeah SimoTod pointed that out on Discord just now. I never knew because the only times I was adding components directly like that was in x-init, which runs before listenForNewUninitializedComponentsAtRunTime

(maybe x-init should run later?)

[ryangjchandler]

Nah I think x-init runs at the right time since it runs when a component initialises or after it initialises, not after Alpine has initialised.

[KevinBatdorf]

True, and I suppose moving listenForNewUninitializedComponentsAtRunTime up would cause a whole mess of issues as well.

[msnegurski]

Great idea! Would be a godsend for people working with Livewire/Turbolinks stack

[SimoTod]

I think there are a few challanges.

1. X-init doesn't run if the componant hasn't started so an impotetic Alpine.on like the one in your example would never be called.
2. Alpine.on is just x-on using the window modifiers. It's a different way to to something that is already possible using a different syntax (i think Caleb prefers to avoid those situations).
3. X-defer would cause an unnecessary flickering if people is not careful because the component starts late. I'm pretty sure a lot of people would open tickets even if they are not right.

As a separate note, Ryan created a PR to add lifecycle events in the past but it was decided not to merge it.

It would be good to know what other people's (and Caleb's) thoughts are.

[tanthammar]

Thank you for your explanatory input, I do not know the Alpine source as you do.
All your points makes sense.

Flickering
Maybe x-defer could set style display:none, then load could reverse the display setting.

x-init doesn't run
Instead of tying the window events to x-init, x-defer could require the window event that should load the component.
Any defined x-init would of course be executed when the component is loaded.

Alpine.on is just x-on
Of course, silly me... That would mean we could just use x-on:someEvent.window="trigger reload of this component"

x-name = x-ref
Just hit me that x-name is a pretty stupid suggestion when we could just use x-ref.

Will revise my suggestion based on your input :)

[tanthammar]

With the help from people participating in this discussion I learned that these two exist:

Alpine.initializeComponent(element)

// and

window.deferLoadingAlpine = function (callback) {}

For my needs, they are enough so I'll close this thread.

[Lomacar]

Where did you find out about these? How do they work?

[ryaninvents]

If you need to make sure Alpine is correctly handling interactivity on descendants of a DOM element (e.g. you've rendered from a template string, or loaded HTML over the network) you can call Alpine.initializeComponent(element) on your target.

I've made a small demo that shows how you can use this method to reinitialize. I haven't found anything in the documentation so far that describes it, but it seems to work well!