What do you think about exposing dynamic imports in scittle? There are CDNs like https://www.skypack.dev/ which might resolve some of the trickier aspects of very modular packages
@tgg I think it might be possible to use those modules from other <script> tags and then use them from scittle, right?
You're 100% correct, I typed too soon... just having a fiddle now
@tgg Trying myself now too. This kind of works:
<html>
<head>
<script type="module">
import confetti from '';
globalThis.confetti = confetti;
</script>
<script src="" type="application/javascript"></script>
<script type="application/x-scittle">
(js/confetti)
</script>
</head>
<body>
</body>
</html> We could support
(require '["" :as confetti])
probably but this requires a different way of evaluationthe hack above probably is sufficient for now
I'm writing sci.async and migrating to that makes the require + skypack possible
Nice, I wound up with something like this:
<script type="text/javascript">
var ChakraUI = import('');
</script>
<script src="app.cljs" type="application/x-scittle"></script>
and then:
(.then js/ChakraUI
(fn [chakra]
(let [ChakraProvider (.-ChakraProvider chakra)
Button (.-Button chakra)
my-component (fn []
[:> ChakraProvider
[:div
[:p "Clicks: " (:clicks @state)]
[:p [:> Button {:on-click #(swap! state update :clicks inc)}
"Click me!"]]]])]
(rdom/render [my-component] (.getElementById js/document "app")))))
However, more refinement required!Ah this is a but ugly since confetti will be a promise. The approach I had doesn't require that
Ah, I had thought the modules were asynchronously loaded, I was using the promise based syntax to guarantee ordering.
Ideally I would love it to be synchronously loaded and added to the global context, I feel like I'm suffering the asynchrony purely as a result of the module syntax here. The real solve would be to package up the dependency so it's a UMD type thing and available in the same way as other packages like react, but that doesn't seem to be the modern approach thinking-face
I'm happy with either of the approaches above though! 😀
<html>
<head>
<script type="module">
import confetti from '';
window.confetti = confetti;
</script>
<script src="" type="application/javascript"></script>
<script type="application/x-scittle">
(js/confetti)
</script>
</head>
<body>
</body>
</html>
Yeah, so here confetti is the already imported module, not a promiseAh, I wonder if it's just the latency in acquiring all the resources for the package I'm pulling in.
<script type="module">
import * as ChakraUI from "";
console.log(ChakraUI);
globalThis.ChakraUI = ChakraUI;
</script>
<script type="text/javascript">
console.log(globalThis.ChakraUI);
setTimeout(() => console.log(globalThis.ChakraUI), 1000);
setTimeout(() => console.log(globalThis.ChakraUI), 2000);
</script>
=>
index.html:16 undefined
index.html:17 undefined
index.html:12 Module {…}
index.html:18 Module {…}And here I was thinking HTTP2|3 had solved all my problems!
aaah interesting
but when scittle is being kicked off it should be there
right...? now I'm not sure ;)
I'm sort of surprised skypack isn't using server push come to think of it; there seems to be a cascade of dependencies 🤔
I think it might make sense to expose promesa.core in scittle anyways, to deal with promises, like nbb and joyride
Do you think you'll split it into a separate require as with reagent or default scittle? I can't imagine it adds too much to the payload
yes
everything will be split
It makes a lot of sense
This allows use to add a plethora of libraries without worrying about size and load times
Perhaps when we migrate to sci.async we could make pulling those libraries automatic ;)
the wonders of an open system