Do <script> tags work in template files?

[RobinManoli]

Hi!
I tried to load a template file using x-template, and the code inside the <script> tag didn't work. Is it supposed to work?

Previously I've had to obfuscate <script> tags when including such code dynamically, like this:
document.write('<script type="text/javascript" src="..."><\/script>'); // from https://stackoverflow.com/a/17542683

[rehhouari]

Honestly I can't figure how to make them work, I've checked other routers and they don't seem to be doing anything special for scripts neither
To show the templates I'm using el.innerHTML to put it inside the target element not document.write, the latter seem to be deprecated but I don't see any alternative

[boustanihani]

How about using eval() ?

[rehhouari]

It'd have to go through all elements inside the route to find the script then run it. also there is the thing about eval being unsafe. There used to be a saferEval function in Alpine but it's gone now.
I'm currently replicating x-if functionality to render templates, which should make scripts run but it doesn't. So i'll look into why

[rehhouari]

after some testing, scripts inside x-if and therefore templates only work when it's in the same file
I do not how to optimally approach this.
for now you can use x-init inside templates or x-handler if you don't intend to interact with the template since handlers are ran before the templates are rendered

[boustanihani]

Hope this gets solved in an elegant way, cause it would make alpine.js also suitable for large SPAs :)
I love the simplicity of alpine, and mostly, that we simply edit html files, with no build/compile steps needed..

[RobinManoli]

Okay, well the workarounds that worked for me is to have the script somewhere else, or to use inside attributes such as onclick or @click

[boustanihani]

@rehhouari is there a special way for importing a js module inside x-init?

I am getting the following error:

Alpine Expression Error: Cannot use import statement outside a module

Expression: " import * as loginModule from 'pages/login.js' "

This is my code =>

login.js

export function sayHello(){
    return "Hello";
}

login.html

<div x-init="import * as loginModule from 'pages/login.js'" x-data="loginModule">

    <h1>Login</h1>

    Message: <span x-text="sayHello()"></span>

</div>

[rehhouari]

I don't quite get what you're asking, Alpine.data method already works, I don't know what dynamic imports are. I don't see that feature documented anywhere

[boustanihani]

I'm just trying to find a way that makes splitting and importing files more elegant with minimum code.
Those are dynamic imports:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/import

[rehhouari]

Are you using a build tool like vite? if so you can just do it like this
dropdown.js:

export default () => ({
    open: false,
 
    toggle() {
        this.open = ! this.open
    }
})

main.js:

import dropdown from 'dropdown.js'
import Alpine from 'alpinejs'
Alpine.data('dropdown', dropdown)
Alpine.start()
...

home.html:

<div x-data="dropdown">...

[rehhouari]

Those are dynamic imports:

I don't think alpine supports them, ask in their discord maybe someone could help.

[boustanihani]

Thanks

[rehhouari]

Fixed with v 6.2.1 test it out and let me know if it works as intended
(See documentation](https://github.com/pinecone-router/router/#embeded-scripts)

[boustanihani]

Hey @rehhouari thanks for the very nice work. I still haven't tested this, will do soon.

Could you just explain how you implemented this?

And what does this exactly mean:
The script tag is added to the document when the route is matched, and removed when the route changes?

Will the script tags get excecuted multiple times (each time the route is matched)?
Is there a possibility to let the scripts inside the templates only execute once?

Another cool feature I would like to suggest is the ability to define "Single File Components".
Components that are always available to all templates (regardless of which route is being matched).
(Something similar to https://vuejs.org/guide/scaling-up/sfc)

I think you are almost there with this new "Embeded Scripts" feature.

[rehhouari]

Hey @rehhouari thanks for the very nice work. I still haven't tested this, will do soon.

Could you just explain how you implemented this?

And what does this exactly mean:
The script tag is added to the document when the route is matched, and removed when the route changes?

Will the script tags get excecuted multiple times (each time the route is matched)?
Is there a possibility to let the scripts inside the templates only execute once?

Another cool feature I would like to suggest is the ability to define "Single File Components".
Components that are always available to all templates (regardless of which route is being matched).
(Something similar to https://vuejs.org/guide/scaling-up/sfc)

I think you are almost there with this new "Embeded Scripts" feature.

it will run once only once just like handlers.
I implemented it by taking the second element in the template, and if it's a script insert it into the document to execute it. and of course remove it when the route has changed.

as for sfcs, if you mean a component you can add to every template then well you're asking for a templating library and a build tool here tbh, you can do this with Astro easily using Astro components. When ran they automatically turn into plain html so there is no need for any runtime compilation or fetching cause although I keep implementing feature requests I dont want it to end up as bloated as a full fledged framework. There was a time when templates weren't even in the library but an middleware! :)

I'm still working on the astro template with pinecone and other niceities, but typescript is agonizing to work with since Alpine.js wasn't written in TS and definitely-typed types sucks. I might abandon ts entirely atp.

[boustanihani]

I keep implementing feature requests I dont want it to end up as bloated as a full fledged framework.

I totally understand this.

As for sfcs, if you mean a component you can add to every template then well you're asking for a templating library and a build tool...

I meant a component, which is nothing more than a template which is not tied to a route :)

One idea how this could be implemented:
Because components need to have their own data scope when attached several times, the difference to regular templates (tied to routes) would be that components need to be passed data from their parents.

So instead doing this:
<template x-route="/page" x-template="/page.html"></template>

We would then change the content of x-data each time we place a component somewhere:
<template x-data="{...}" x-template="/component.html"></template>

And inside the component, Pinecone router would then add (or edit) the outer x-data attribute and attach the data passed.
component.html:

<div x-data>
	<h1>My Component</h1>
	<p x-text="message"></p>
</div>

To keep things simple, maybe components should not be allowed to have a script tag (for now).
And the feature "Embeded Scripts" would not apply to components.

I'm just thinking loud, if you think this would make Pinecone router bloated, just ignore what I said :)

[rehhouari]

@boustanihani I managed to implement this! I've got to test it further for edge cases but seems to work as intended.

However I've refactored the code base and organized the code, with better Typescript support.

This means this will be part of the next major version, v7, which contains more breaking changes than say 6.0.0.

I know people are already using this router as is so further breaking changes aren't nice but it's using semantic versioning so there is no need to upgrade. And I plan to support v6 with bug fixes if any comes up for those still using it.

And of course I'll document the changes in the CHANGELOG to make it easier to upgrade

Can't say when it will be out as I want to polish and get the documentation right, I might give also give "beta" release a try

[boustanihani]

@rehhouari thanks a lot for the great work, I will be happy to test the next version.

I have a feeling that we will end up with functionality similar to that of a bundler, but without having to deal with the complexity of using a bundler :)

That's why I like Alpine, for its simplicity..

[rehhouari]

Well maybe we celebrated too early.
Trying to get bundler DX without a bundler isn't an easy task after all.
For once multiple instances of the same component means that the same script would be added to the DOM multiple times.
I gave it a shot to handle this case but it's too complicated with many edge cases when introducing adding and removing components dynamically such as with x-if.
This isn't in issue in frameworks which use bundlers.

This could be resolved by having the script somewhere else, but that's literally the opposite of what this discussion is about..

I hoped this was as simple as adding a couple of lines but I may end up scrapping it rather than having to support it with the issues it will eventually get.