Re: Static data for web pages

> On 11 May 2020, at 5:00 pm, Melvin Carvalho <[email protected]> =
wrote:
>=20
> Hi Marcos
>=20
> 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.
>=20
> Perhaps I can illustrate a slight difference by means of a use case
>=20
> High Score Table
>=20
> 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).
>=20
> The table would be a simple data structure with a user, and a score.  =
Let's say it stores 10 entries.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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. =20
>=20
> Let me know if I'm making sense here!

Well, if you wanted to make them "the same concern", you could use a =
custom element like `<my-highscore-table>`, then you could either inline =
the scores as other custom elements, or you could have the custom =
element pull the data from one of the available stores (or even fetch it =
from the web, and store it)...=20

You can see something similar used by the ReSpec project. It has a =
`<rs-changelog>` element [1] (implementation [2]) that shows the change =
log for a specification by pulling down Git commit history data from =
GitHub. That data is then stored locally, using the Cache API and reused =
when an app is reloaded (for, say 24 hours).

The element also has custom elements, so you can say, "show the change =
log from commit/tag X to commit/commit Y, but filter out things I don't =
want to list via JavaScrpt":

```
<rs-changelog from=3D"CR" to=3D"123123asdjdflhk"  =
filter=3D"respecChangelogFilter"></rs-changelog>

```

However, the architectural fundamentals don't change here, when talking =
about the separation of concerns... you still need the backing store =
(IDB, localStorage, cache API, whatever) - each can do it's own thing, =
and then you can use a higher level of abstraction to build what you =
want (i.e., a thing that inlines the scores or whatever).

Hopefully that makes sense! =20

[1] https://github.com/w3c/respec/wiki/rs-changelog
[2] =
https://github.com/w3c/respec/blob/develop/src/core/custom-elements/rs-cha=
ngelog.js


=20=