Re: Static data for web pages

--000000000000cf009a05a559e7e7
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, 11 May 2020 at 05:31, Marcos Caceres <[email protected]> wrote:

> H=C3=AD Melvin,
>
> > On 10 May 2020, at 7:27 pm, Melvin Carvalho <[email protected]>
> wrote:
> >
> > Let me add the class of storage APIs such as SessionStorage,
> LocalStorage, Cookies, File System API, WebSQL etc. as mentioned here:
> >
> > https://web.dev/storage-for-the-web/
> >
> > The static variable idea relates more to something in the page itself
> (body or head)
>
> The DOM is not dissociated from local storage, so the solution is to use
> the local storage solutions provided by the browser. Just rehydrate state
> based on those storage solutions.


Hi Marcos

I absolutely love local storage, and use it all the time.  This was one of
the first things someone suggested to me when I was sharing he idea.

Perhaps I can illustrate a slight difference by means of a use case

*High Score Table*

I wish to create a simple page that has a game that you can play and also
persists the "high scores" into a sorted array (high score table).

The table would be a simple data structure with a user, and a score.  Let's
say it stores 10 entries.

Local storage would be great for a single user system.  But for a multi
user web scale system you would need a store that's independent of a
particular browser, or a particular device.

As I see it, in order to persist the scores, you could either do it in an
*external* store e.g. a REST API, a linked file etc.

Or you could persist the scores *inline* within the same document that
served the app.  This would be a kind of self modifying file.  Where for
example the data is stored in a script tag with globalThis.  Or you would
have a clean declarative data island with a way to translate that into
globalThis and initialize the app.  In this case by populating the high
scores.

Different approaches to solve a solved problem.  But I think what's
potentially interesting here is the architectural of keeping variables
close to where they are used.  The external store is two separate concerns
and a protcol.  The inline version is one concern and a protocol.

Let me know if I'm making sense here!

--000000000000cf009a05a559e7e7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Mon, 11 May 2020 at 05:31, Marcos =
Caceres &lt;<a href=3D"mailto:[email protected]">[email protected]</a>&gt; wrot=
e:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">H=C3=AD Melvi=
n, <br>
<br>
&gt; On 10 May 2020, at 7:27 pm, Melvin Carvalho &lt;<a href=3D"mailto:melv=
[email protected]" target=3D"_blank">[email protected]</a>&gt; wr=
ote:<br>
&gt; <br>
&gt; Let me add the class of storage APIs such as SessionStorage, LocalStor=
age, Cookies, File System API, WebSQL etc. as mentioned here:<br>
&gt; <br>
&gt; <a href=3D"https://web.dev/storage-for-the-web/" rel=3D"noreferrer" ta=
rget=3D"_blank">https://web.dev/storage-for-the-web/</a><br>
&gt; <br>
&gt; The static variable idea relates more to something in the page itself =
(body or head)<br>
<br>
The DOM is not dissociated from local storage, so the solution is to use th=
e local storage solutions provided by the browser. Just rehydrate state bas=
ed on those storage solutions. </blockquote><div><br></div><div>Hi Marcos</=
div><div><br></div><div>I absolutely love local storage, and use it all the=
 time.=C2=A0 This was one of the first things someone suggested to me when =
I was sharing he idea.<br></div><div><br></div><div>Perhaps I can illustrat=
e a slight difference by means of a use case</div><div><br></div><div><u><b=
>High Score Table</b></u></div><div><br></div><div>I wish to create a simpl=
e page that has a game that you can play and also persists the &quot;high s=
cores&quot; into a sorted array (high score table).</div><div><br></div><di=
v>The table would be a simple data structure with a user, and a score.=C2=
=A0 Let&#39;s say it stores 10 entries.</div><div><br></div><div>Local stor=
age would be great for a single user system.=C2=A0 But for a multi user web=
 scale system you would need a store that&#39;s independent of a particular=
 browser, or a particular device.</div><div><br></div><div>As I see it, in =
order to persist the scores, you could either do it in an <u>external</u> s=
tore e.g. a REST API, a linked file etc.</div><div><br></div><div>Or you co=
uld persist the scores <u>inline</u> within the same document that served t=
he app.=C2=A0 This would be a kind of self modifying file.=C2=A0 Where for =
example the data is stored in a script tag with globalThis.=C2=A0 Or you wo=
uld have a clean declarative data island with a way to translate that into =
globalThis and initialize the app.=C2=A0 In this case by populating the hig=
h scores.</div><div><br></div><div>Different approaches to solve a solved p=
roblem.=C2=A0 But I think what&#39;s potentially interesting here is the ar=
chitectural of keeping variables close to where they are used.=C2=A0 The ex=
ternal store is two separate concerns and a protcol.=C2=A0 The inline versi=
on is one concern and a protocol.=C2=A0 <br></div><div><br></div><div>Let m=
e know if I&#39;m making sense here!<br></div></div></div>

--000000000000cf009a05a559e7e7--