Repository navigation
Suggestion: interactive pages by default #327
Description
Imagine the following: you spend hours, days, weeks developing an app and it works wonderfully in dev mode. After a lot of sweat and effort, you finally "build" it and ...nothing works at all. You then realize that dev mode (interactive by default) and the build (static by default) behave totally differently. That's not "joyful" but rather "frustrating", even more so because there is no quick fix to produce the same you had in dev.
This already popped up in the past in a couple of issues. Nevertheless, I think the need for interactive pages is underestimated. Perhaps it's just a simple login dialog or a complex page with dynamic language selection. The only workaround currently available is to put the complete "page" in a "component", which kind of misuses the otherwise intuitive file structure.
By default, everything is pre-rendered. Now that's fine for all those static pages, but if a page has a <script> part, it's highly likely because it is somewhat interactive. It's both counter-intuitive to drop scripts during build (but not dev) and problematic because there is no straightforward way to achieve it. That's why I'd humbly suggest having pages with a script tag be interactive by default, behaving like client:load, or at least have an iles option to do so. I think this would be more intuitive, versatile and solve all the above-mentioned problems.
That said, thanks for the framework. It's a nice lightweight alternative to nuxt.
Activity
TechAkayy commentedon Mar 8, 2025
We have all experienced this at some point @dagnelies, thanks for sharing your feedback. That said, we can't forego the DX with HMR like how Astro does hot-reload way (no HMR) during development. Here are some thoughts from my end in terms of solutioning this:
client:loadto it.client:loadadded to the root-level to hydrate the whole page (div#app shell). If this config is defined, ignore all client:directives within the component tree within the pages.With first two options, applying client directives to improve site performance becomes an optional optimization which is very helpful especially for new users who are not familiar with the concept and simply want to build a site with or without interactivity.
TechAkayy commentedon Mar 8, 2025
Having a script tag might not mean the component is interactive. It could have an array like
const products = []and used in the template looped with av-for, and iles will statically render when building the component.dagnelies commentedon Mar 9, 2025
Thanks for the quick response. In addition to what I said before , I wanted to emphasize two points. The first is that I understand why the dev DX is as it is, because of HMR during development. And it's completely fine too! This is not about making dev/build identical, but rather highlighting the discrepancy between dev/build to avoid unpleasant surprises. A warning in the docs and the CLI stating that dev/build hydrate things differently would be very helpful. As long as you know it, you can avoid that pitfall instead of walking straight into it. 😅
That said, being able to have interactive pages instead of only components would be great. Components can be hydrated just fine with the
client:*directives, I think that's fairly straightforward and well communicated. However, the page itself cannot be hydrated as far as I know, although I think it's a fairly common use-case for page to dynamically fetch data from a service to render it. It would be great if there was a global option or a per-page option to let the page itself be interactive.TechAkayy commentedon Mar 10, 2025
Good stuff 👍🏽. Im waiting for the vite 6 and other important stuffs in my latest PR to go through, after which I will try solving this along with few other ideas.
ouuan commentedon Mar 10, 2025
You can just use a component as the only content of the page.
TechAkayy commentedon Mar 10, 2025
OP already explained (below) why it's not nice, and I agree with him as well. Workaround is an easy one for now, but it would be nice as a config to have hydration at a page-level.
dagnelies commentedon Mar 10, 2025
@ouuan Indeed, that's what I did as a workaround. However, from a conceptual POV, I'd prefer to keep the "page" as a "page", and the "components" as (more-or-less) reusable "components". It's more to keep the intuitive file structure than anything and be able to have the same result in production as in dev.
dagnelies commentedon Mar 24, 2025
Just in case you missed it: https://vite.dev/blog/announcing-vite6 ...but that's already November 2024, so I'm kind of confused by the statement. 😅
Anyway, I'd be glad if things get rolling with this little bit of old news. 😜
ouuan commentedon Mar 24, 2025
I believe that it means #326 gets merged.
dagnelies commentedon Mar 24, 2025
Thanks for the clarification
dagnelies commentedon Mar 25, 2025
If you point me in the right direction, I may attempt to implement this feature/option and make a concise PR. A bit of guidance would be good though.
ElMassimo commentedon Mar 26, 2025
This is probably the biggest pain point in îles for newcomers.
Detecting listeners and automatically disabling them, or inferring that those components must be islands would both be good ways to ensure that what you see in development is what you get in production.
Technically, these are not trivial to pull off consistently, which is why it hasn't been added so far, but it is something that I'd like to see improved.
dagnelies commentedon Mar 27, 2025
@ElMassimo Automatic detection and "everything works magically" would of course be perfect and ideal. However, sometimes a more humble and pragmatic solution is a very fine thing too. I see it as a kind of three level thingy:
<script dynamic ...to indicate the script must be kept (very useful and fine-grained control)Please don't understand me wrong, I'm not saying "don't do it". It's your call by any means. I just wanted to indicate that sometimes a simple practical solution is preferrable to an ideal complex one. But you know the details of your own project much better than I do, this is just a comment from a user perspective.