[](https://www.webcomponents.org/element/purr-sist) # purr-sist purr-sist-* are web component wrappers around various services used to persist (history.)state. What follows purr-sist- indicates where the state is persisted. For example, purr-sist-myjson persists state to the [myjson.com](http://myjson.com/) api service. The service allows anyone to save and update a JSON document, with zero setup steps. See discussion below about the pro's and significant con's of this service. purr-sist-idb persists state to the local indexed db for offline storage (and potentially cross window state management). **NB**: Quite a bit of the functionality described here overlaps significantly with the slightly better known [Polymer data elements](https://www.webcomponents.org/element/@polymer/app-storage), which I remembered about recently. At this point, there's no doubt those components support useful features not found here for now (like orchestrating data moving as the user's status switches between offline and online mode). ## Syntax Reference ## Basic Syntax purr-sist has two modes: ```html ``` The first tag ("read") above will only read from the remote store. The second will only write. One tag cannot serve both roles. The write mode tag cannot retrieve existing data on its own. It must be passed a record (if one exists) from the read mode tag. If you place write mode tag on the page with the new attribute: ```html ``` since no "store-id" is specified, a new "{}" record will be created on initial load. If you inspect the element, you will see the id of that new record reflected to the element with attribute "store-id". Once you have the id, you *could* set it / hardcode it in your markup (after removing the create attribute). ```html ``` As we will see, this can be useful in some cases, particularly for "master lists". ## Master Index purr-sist adds some fundamental support for scaling large saves, so they can be broken down somewhat. First, there is a property, guid, which stands for "globally unique identifier." There are [many](https://duckduckgo.com/?q=online+guid+generator&t=h_&ia=web) [tools](https://marketplace.visualstudio.com/search?term=guid&target=VSCode&category=All%20categories&sortBy=Relevance) that can generate these for you. Second, there's a property "master-list-id" which specifies the id of a DOM element outside any Shadow DOM. That DOM element should also be a purr-sist element, which serves as the master list indexer. It contains a lookup between the guid, hardcoded in the markup (or initialization code), and the id defined by the remote datastore (myjson.com in this case). So the markup can look like: ```html ... #ShadowDOM #EndShadowDOM ``` Note the value of the master-list-id attribute starts with a /. This is to explicitly state that the id is expected to be found outside any Shadow DOM. The ability to reference a master list sitting inside some Shadow DOM realm is not currently supported. # Examples Part A -- persisting to myjson.com ## Why myjson.com? myjson.com is easy as pie to use. It is so simple, in fact, that it kind of mirrors the (overly?) simple api we get with the browser's history api. One of the objectives of this component is to provide persistence of the history.state object, so myjson.com would appear to have no "impedence mismatch" with the window.history.[push|replace]State calls, which probably is not a very flattering thing to say about the window.history api. In addition, myjson.com requires no account set up, so it just works, with zero fuss. ## What's the problem with myjson.com? Due to the extremely trusting nature of myjson.com, it would be quite dangerous to use in a production setting, so use of this service should be restricted to storing and retrieving harmless data, such as URL paths or public data, or for academic / prototyping purposes. myjson.com is similar, but not nearly as powerful, as other, far more robust solutions like [Firebase](https://firebase.google.com/docs/database/rest/save-data) (or mongoDB, or countless other solutions). Firebase's ability to save to a path, and not overwrite the entire record, is certainly quite appealing. I'm 99% certain that using Firebase instead of myjson.com would reduce the packet size in a fairly significant way. But I would argue that the approach of creating a master list, detailed below, helps whether you are using Firebase or myjson.com. ## Update pieces of the remote store To send a new object to the remote store, replacing the old one, use the newVal property: ```JavaScript const myValue = {chairman: 'meow'}; document.querySelector('purr-sist-foo').newVal = {'kitty': myValue} ``` ## Example A.1 -- Time travel support (aka back button) [See it in action](https://bahrus.github.io/purr-sist-demos/Example3.html) Data flow is **almost** unidirectional (see tag p-u for bad code smell exception). Markup shown below. ```html ```