Feature: cdn.no-start(.min).js version

[vanodevium]

This request adds the ability to use the CDN version without automatically starting Alpine.

This version allows you to use a CDN file even if your data is coming from a server after page initiation.

Please remember to manually call Alpine.start()

[ekwoka]

Why does this need new files for all the plugins?

They're literally the same thing as what already exists...

[vanodevium]

@ekwoka

This is only so that the build process is not changed.
This functionality can be easily changed, your requests or commits are welcome

[ekwoka]

This version allows you to use a CDN file even if your data is coming from a server after page initiation.

I'm not sure what exactly you mean by this.

Can you give an example of the use case?

Is there a reason, even after the recent Chinese supply chain attacks you still think using a public third party CDN is a good idea?

[vanodevium]

@ekwoka

No, no, no Chinese attacks have any effect here.

This is an attempt to make a version of Alpine that can be included through a normal CDN.

I will try to explain my case:

I require Alpine through normal CDN as cdn.min.js file by <script> tag.
And only after that, my main application receives the configuration and additional data from the server in an asynchronous way.
But the CDN version of Alpine has already started automatically, and there is no data for rendering components.

So, I only want to

1. include CDN version of Alpine by <script> tag.
2. load from the server my configuration and another data, init Alpine data and store in app.js file
3. manually call Alpine.start()

[ekwoka]

Yeah can you be more specific?

What do you mean it gets the data in an asynchronous way that conflicts with Alpine?

Alpine can already handle getting data asynchronously.

So it would be helpful to see more of a real world example, as I've made tons of Alpine sites, and this isn't something that has ever been a concern, even when loading data asynchronously. So it might be an XY problem.

And I meant, there was a big supply chain attack on a public CDN just these past weeks.

Why do you still feel it's a good idea to use a public third party CDN at all? It's a bad idea with no benefits.

So this is two concerns there, but the main is just

What actually is the conflict you're running into? Specifically.

[vanodevium]

@ekwoka

Fine.

To begin with, please note that I am using Alpine for the first time, so maybe I am doing something useless. Sorry.

I will try to explain as simply as possible.

---

Important point: I can't use the builders like webpack or vite, these are the conditions of the task.

On my page, in the HTML, there are two lines:

<script src="https://cdn.jsdelivr.net/npm/alpinejs@3.14.1/dist/cdn.min.js"></script>
<script src="./js/app.js"></script>

With the first script tag everything is clear, with the second: I use async fetch to receive an JSON object from the server with data that I need to push into Alpine data and storage (by using Alpine.data() and Alpine.store()).
But Alpine has already started automatically, so there is an error - there is no data.

If I change the order of the script tags, the Alpine.data() or Alpine.store() are not yet available.

Please let me know if it's unclear, I'll try to explain in more detail.

Again, if you already have a possible solution, I'd be happy to hear it.

[SimoTod]

The Alpine tag should be deferred. But you can also include your app.js before alpine. You can find a lot of example but you need to wrap your Alpine.data and Alpine.store call inside an event listener for alpine:init (https://alpinejs.dev/essentials/lifecycle#alpine-initializing).

[vanodevium]

@SimoTod Yeap, but when alpine:init is emitted there is no data yet because async way of retrieving server's data

[SimoTod]

If I change the order of the script tags, the Alpine.data() or Alpine.store() are not yet available.

That is what you wrote above, if the call is async and takes longer Alpine should available then and you have another problem instead.

I suspect you are designing your component in a non intuitive way.

Is the issue that you are adding the html but you don't have data yet? You can use x-ignore and remove it when you receive the data although your page will be flickering. Probably you shoul only add the html when ready. Hard to say without seeing an example or a more accurate description of the issue.

[vanodevium]

@SimoTod @ekwoka

Forgive me for such a question, but it is really interesting:
is this reaction resistance to just one more variant file without automatically calling the start method or there is another reason?

[SimoTod]

No restrictions, I was trying to suggest you a different way to fix your problem. The maintainer is the one who will make the final call anyway.

As a side note, there's no documentation for other developers about how the build can be used, if it gets merged into the main branch.

[vanodevium]

@SimoTod No problem, I can try to write documentation for this use case

imho, I don't think I'm the only one with such a complex and rare use case, most likely someone will find this use case useful.

[ekwoka]

Seems like what you really want is to just have the data fetched inside the Alpine component.

So your script can be

Alpine.data('stuff', ()=>({
   myData: [],
   async init() {
     getDataHere()
   }
}))

And then it just works.

Your use case isn't complex or rare. Just off the information you provide, it's more a design issue.

Deferring the loading of Alpine until the data is fetched is mostly a bad solution. Since then your more small interactions will be disabled until that data is ready. That's not good.

For reference example: this sandbox does such a call in the example to get external JSON to render. Alpine still initializes right away, allowing other things to work, while that data is gathered.

is this reaction resistance to just one more variant file without automatically calling the start method or there is another reason?

To this, more complication of things is generally not a good idea. CDNs are generally not a good idea as well.

But the biggest thing is that I believe that the issue you are having is in how you're designing your components, and should not actually warrant deferring Alpine in such a way to begin with.

There can sometimes be things where "yes, that could be useful in a limited situation, but this actually is more an indication you're doing something strange". I am personally open to the idea that this might be legitimately useful and important for some case, but I can't actually imagine what that would really be, as I've made tons of crazy stuff and this hasn't been a concern before...

Even if it might be legitimately valuable, I also feel like that's a situation where bundling should be done as well...

[calebporzio]

Thanks for the contribution @vanodevium and for the suggestions @SimoTod and @ekwoka. I agree with them, I think this is something that should be handled in userland. If you can't find a way to make the current CDN work, I suggest hosting your own build like this or something along those lines. Thanks!