Re: Static data for web pages

On Mon, 11 May 2020 at 05:31, Marcos Caceres <w3c@marcosc.com> wrote:

> Hí Melvin,
>
> > On 10 May 2020, at 7:27 pm, Melvin Carvalho <melvincarvalho@gmail.com>
> 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!