Suggestion: interactive pages by default

[dagnelies]

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.

[TechAkayy]

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:

• Automatic island hydration - Not sure how realistic this is, but idea is if user hasn't manually defined, then automatically determine (static analysis) if a component (non-islands - no parent has client directive applied to them) has event-listeners and require hydration, and apply a default client:load to it.
• Full page hydration - Have a config which when building the pages, have client:load added 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.
• Balanced - Add some logic that automatically warns user to add a client:directive when event listeners are detected in non-islands (I believe @ElMassimo had this in his mind). Once user understands how it works, it becomes natural for the user to adopt and practice.

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]

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.

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 a v-for, and iles will statically render when building the component.

[dagnelies]

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]

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]

That said, being able to have interactive pages instead of only components would be great.

You can just use a component as the only content of the page.

[TechAkayy]

You can just use a component as the only content of the page.

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.

The only workaround currently available is to put the complete "page" in a "component", which kind of misuses the otherwise intuitive file structure.

[dagnelies]

@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]

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.

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]

Just in case you missed it: vite.dev/blog/announcing-vite6 ...but that's already November 2024, so I'm kind of confused by the statement. 😅

I believe that it means #326 gets merged.

[dagnelies]

Thanks for the clarification

[dagnelies]

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]

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]

@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:

• a global config setting to make the whole site static/dynamic (very useful to make the two type of apps/sites)
• a setting on the page itself, like marking <script dynamic ... to indicate the script must be kept (very useful and fine-grained control)
• îles detects everything for you (ideal, perfect ...but might result in a difficult tricky implementation, which is also costly to maintain and evolve)

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.