Re: Static data for web pages

> On 11 May 2020, at 5:00 pm, Melvin Carvalho <melvincarvalho@gmail.com> wrote:
> 
> 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!

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)... 

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="CR" to="123123asdjdflhk"  filter="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!  

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

Received on Monday, 11 May 2020 07:13:42 UTC