Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>You are on the right track I would say, but store your data in JavaScript primarily. And couple it with Local Storage when suitable.</p> <p>When I build apps such as the one you are describing I usually take care to set up JavaScript representations of the data I receive via the API. </p> <p>One such representation could look as follows below. Bear in mind that my example code below makes a couple of assumptions. </p> <ol> <li>It makes the assumption that you have an <code>api</code> object defined which takes care of API calls, and invokes a callback on completion.</li> <li>that the data returned by the API is JSON that simply can be assigned to a JavaScript variable,</li> <li>That the JSON returned is a list of objects, each with an "id" field.</li> <li>That you have some sort of event object, I usually build my own custom events that basically carry <code>function</code> objects as listeners and when fired go through the listeners and invoke the functions with or without a payload depending on the situation.</li> </ol> <p>Data container example:</p> <pre><code>MYAPP.data.BaseContainer = function (api_url, loadedEvent) { var self = { // Array to store the data returned via the APIs _data : [], // The API URL used to fetch data api_url : api_url, // Boolean flag to signify whether the _data variable has been populated is_loaded : false, // The even to fire once _data has been populated loadedEvent : loadedEvent, /** * Returns the state of the is_loaded variable */ loaded : function () { return self.is_loaded; }, /** * Takes an ID and returns any member of the _data array * that has that ID. * * @param id : an String or integer representing the ID. * @returns {Object} */ byId : function (id) { var toReturn = null; for (var i = 0, len = self._data.length; i &lt; len; i++) { if (self._data[i].id == id) { toReturn = self._data[i]; break; } } return toReturn; }, /** * Returns the entire _data array. */ all : function () { return self._data; }, /** * This simple callback just stores the json response in * its entirety on the _data variable. */ callback : function(data) { self._data = data; self.is_loaded = true; loadedEvent.fire(self._data); }, /** * Calls the API, if no callback has been specified as a parameter * self.callback is used. */ getFromAPI : function(callback) { if (typeof callback === 'undefined') { callback = self.callback; } api.get(self.api_url, callback); } }; self.getFromAPI(); return self; }; </code></pre> <p>With this blueprint I can now create specific data containers like this:</p> <pre><code>/** * Stores a list of "friends" gotten from the API. * This is basically an instance of the BaseContainer object defined above. */ MYAPP.data.Friends = (function () { var self = MYAPP.data.BaseContainer("API_URL_TO_FECTH_FRIENDS_LIST", FriendsLoadedEvent); return { byId : self.byId, all : self.all, loaded : self.loaded }; }()); </code></pre> <p>As soon as this code is run, an API call is made, and the <code>FriendsLoadedEvent</code> will be fired when it is done. So, to put it bluntly, I use JavaScript to store my stuff usually. But if you want to throw LocalStorage into the mix that is easy too! </p> <p>Just add local storage code to the BaseContainer object that first detects whether the client actually supports localstorage, and if so mirror the _data field in local storage. This is handy to keep often used data quickly available between sessions. Use the readily available JSON parsing tools to convert the data from JSON to LocalStorage "text"and back.</p> <p>Just keep in mind that you cannot rely on LocalStorage as your primary data structure, you have no guarantee that the client supports it, and even when it does the upper bounds for how much data you can actually store is different between the browsers. So use it to store data that:</p> <ul> <li>You want access to very often, </li> <li>that you feel should just be there, immediately as soon as the user logs in,</li> <li>and that does not change often enough to warrant refreshing API calls constantly.</li> </ul>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload