Isodata

[vavrecan]

Hello, why is isodata created?
preactjs/wmr#592
https://github.com/preactjs/preact-iso/blob/main/src/prerender.js#L37
Thank you

[rschristian]

Right now, it's primarily for hydrate to determine whether to hydrate or render.

As mentioned, we had some discussions internally a few years back, I'm not sure if we ever fully decided on what we wanted to do.

[vavrecan]

It should be defined as `text/isodata` by default, with an option to make it configurable for greater flexibility.

…

On Fri, 30 Aug 2024 at 10:53, Ryan Christian ***@***.***> wrote: Right now, it's primarily for hydrate to determine whether to hydrate or render. As mentioned, we had some discussions internally a few years back, I'm not sure if we ever fully decided on what we wanted to do. — Reply to this email directly, view it on GitHub <#38 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AANUREOWRZKL56WVNAI235TZUAXIBAVCNFSM6AAAAABNMBGDU6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMRQGUZTSOBXG4> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[rschristian]

May I ask why? And what should be configurable?

[vavrecan]

The "subtype" must always be included in the "type," just as "mimetype" is required - https://html.spec.whatwg.org/multipage/scripting.html#attr-script-type

Error: Bad value isodata for attribute type on element script: Subtype missing.
From line 1, column 1; to line 1, column 23

<script type="isodata">

[rschristian]

The "subtype" must always be included in the "type," just as "mimetype" is required

That's more of a suggestion than a legitimate requirement. This is pretty standard, for good or bad.

[vavrecan]

type without subtype/ prefix will fail w3 validator with error not warning

…

On Fri, 30 Aug 2024 at 14:45, Ryan Christian ***@***.***> wrote: The "subtype" must always be included in the "type," just as "mimetype" is required That's more of a suggestion than a legitimate requirement. This is pretty standard, for good or bad. — Reply to this email directly, view it on GitHub <#38 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AANUREKO5YEYJABQIEM4Z73ZUBSM3AVCNFSM6AAAAABNMBGDU6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMRRGEZDSNZVG4> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[rschristian]

Sorry, but we target browsers, not spec validators.

We can try to change this in the future, in a major, but adhering to specs isn't really a project goal. What browsers do > what specs say they should do, and as I far as I'm aware no browser has any issue with this.

[vavrecan]

Thank you for the clarification! I ended up writing my own prerender and hydrate methods. This allowed me to store the props data directly in <script> tags, so now all props are available in the HTML. This way, the data props don't have to be loaded from external js, and I can modify them server-side if needed

<div id="app"><div>Hello world</div><script type="application/json" id="isodata" data-route="/product">{"title":"hello world"}</script></div>

It would be great if the library had an option to save props data into isodata script tags, so this could be done more easily.

[rschristian]

Glad to hear it!

It would be great if the library had an option to save props data into isodata script tags, so this could be done more easily.

We'll probably support that via @preact/preset-vite instead, in the same API we used for WMR. I don't think that's something this, as a thin wrapper around RTS, necessarily needs to be aware of.

[vavrecan]

That's perfect! I'm also using preact/preset-vite atm

[rschristian]

Great!

I didn't originally copy it over as I wasn't quite sure where we wanted it (especially with preact-iso being separated out, as it was more tightly-bound to WMR), but never circled back around to that. Will try to get it added soon though. It'll be a data key on the return object, i.e.,

export async function prerender(data) {
    ...
    return { html, data: { title: 'Hello World!' } };
}