Git Product home page Git Product logo

app-storage's People

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

app-storage's Issues

Data binding breaks with 2 app-localstorage-document elements referencing the same key

Description

I have a JSON-serialized object in localStorage and two separate app-localstorage-document elements referencing it at the same time. Then I have a text input bound to a property of the stored object (2-way) using one app-localstorage-document, and then a read-only binding of the same property to a text label, but using the other app-localstorage-document. When the property is changed via the input the text label gets updated once, but then the binding breaks and it stops reflecting the changes in the input. The value seems to be correctly written to localStorage.

In my particular case I have the app-localstorage-document elements in different parts of the application, so I can't just use the same one.

Expected outcome

Both labels should contain the same value, which should reflect the contents of the input

Actual outcome

The first label is correctly kept synchronized with the input, but the second label is updated only on the first change and then the binding is broken. The second label uses a different app-localstorage-document.

Live Demo

https://output.jsbin.com/kehabulitu
http://jsbin.com/meqijot

Steps to reproduce

Just type something in the input and observe the 2 labels above. Type in at least 2 characters!

Browsers Affected

all

app-network-status-behavior:refreshNetworkStatus trying to set readonly property: online.

Description

app-storage is trying to the a read-only property. Results in a console error at load time using Polymer^1.6.

Console Error: Uncaught TypeError: this._setOnline is not a function
Source & Line #: app-network-status-behavior:68

More Detail:
Uncaught TypeError: this._setOnline is not a functionrefreshNetworkStatus @ app-network-status-behavior.html:68attached @ app-network-status-behavior.html:53_invokeBehavior @ polymer-micro.html:434_doBehavior @ polymer-micro.html:427(anonymous function) @ polymer-micro.html:211_makeReady @ polymer-micro.html:109(anonymous function) @ polymer-micro.html:115

Expected outcome

No console errors or warnings.

Actual outcome

Console warning about there not being a setter for a read-only variable (online).

Live Demo

N/A

Steps to reproduce

Browsers Affected

  • Chrome
  • Firefox
  • Safari 9
  • Safari 8
  • Safari 7
  • Edge
  • IE 11
  • IE 10

Quick-load option for app-indexeddb-mirror?

Would there be any interest in a "quick-load" option in app-indexeddb-mirror? Right now I'm having to deal with getting data from a flaky server, so loading from cache at the beginning makes for a better user experience. I would imagine this would be true on iffy/slow mobile connections as well.

Who will use the feature? Those with slow/flaky connections.
When will they use the feature? When loading pages with cached data.
What is the user’s goal? Use the app without waiting for data.

For myself I've implemented it the following way, but would be willing to build out with it as an option with a pull request if there is interest.

     __updatePersistedData: function() {
      this._log('Updating persisted data..');
      this._enqueueTransaction(function() {
        return this.client.validateSession(this.session);
      });

      if (this.online) {
        this.persistedData = this.data;
        this.linkPaths('data', 'persistedData');
      } else {
        this.__retrievePersistedData();
      }
    },

    __retrievePersistedData: function () {
      this.unlinkPaths('data', 'persistedData');
      this._enqueueTransaction(function() {
        return this.getStoredValue().then(function(value) {
          // We may have gone online since retrieving the persisted value..
          if ((this.online && this.data !== undefined) || !this.client.supportsMirroring) {
            return;
          }
          this.persistedData = value;
        }.bind(this));
      });
    },

    ready: function () {
      this.__retrievePersistedData();
    }

parseValue error in app-localstorage-document

I am not really sure this is an issue or it should be handled differently.
It happened for me when the this.storage.getItem(this.key) returns a string of 'undefined'

error in app-localstorage-document

And this problem is caused by setStorageValue of an undefined variable.
I wonder it would be better to check if this.data is undefined before using JSON.stringify and save it

      __setStorageValue: function(key, value) {
        this.storage.setItem(this.key, JSON.stringify(this.data));
      }

and why there is a "value" parameter in the above __setStorageValue method?

Document `Polymer.CarbonNetworkStatusBehavior`

As a Polymer element author,
when I consider Polymer.CarbonNetworkStatusBehavior for my element,
I want the behavior to be well documented,
so that I understand how it works and how to use it.

Can app-indexeddb-mirror receive liveData from several sources?

Description

A question about the relationship between the app-indexeddb-mirror element and its source element(s).

This is from the app-indexeddb-mirror doc page:

<firebase-query
    app-name="cats-app"
    path="/cats"
    order-by-child="name"
    data="{{liveData}}">
</firebase-query>
<app-indexeddb-mirror
    key="cats"
    data="{{liveData}}"
    persisted-data="{{persistedData}}">
</app-indexeddb-mirror>

But what if I want several sources (of identically structured items) to end up in a single app-indexeddb-mirror. I.e. something like:

<template is="dom-repeat" items="[[names]]">
   <firebase-query
       app-name="cats-app"
       path="/cats"
       order-by-child="name"
       equal-to="[[item.name]]"
       data="{{liveData}}">
</template>
<app-indexeddb-mirror
    key="cats"
    data="{{liveData}}"
    persisted-data="{{persistedData}}">
</app-indexeddb-mirror>

I tried this and it does work, but only sometimes. It seems to break when names changes.
So two questions:
1 Is this a valid use case for use of app-indexeddb-mirror?
2 If not, any recommendation of how something like this should be implemented?

app-indexeddb-mirror clears indexeddb entries when firebase-query path changes

I built a simple page that has multiple tabs. Each tab loads a feed (collection/list) of articles from Firebase and renders cards on the page. Everything works as I wanted until I tried to persist the visited feeds into indexeddb with app-indexeddb-mirror.

Here's what I did:

<dom-module id="my-view1">
<template>
    <style include="shared-styles">
    </style>

    <paper-tabs id="tabs"
                attr-for-selected="value"
                selected="{{selectedFeed}}"
                scrollable>
        <template is="dom-repeat"
                  items="[[feeds]]"
                  as="feed">
            <paper-tab value="[[feed.key]]">[[feed.name]]</paper-tab>
        </template>
    </paper-tabs>

    <firebase-query id="[[selectedFeed]]_feed"
                    app-name="myfirebaseapp"
                    path="/myfirebaseappdb/feed/[[selectedFeed]]"
                    data="{{articles}}">
    </firebase-query>

    <app-indexeddb-mirror
            key="[[selectedFeed]]"
            data="[[articles]]"
            persisted-data="{{persistedArticles}}">
    </app-indexeddb-mirror>

    <template is="dom-repeat"
              items="[[persistedArticles]]"
              as="article">
            <paper-card image="[[article.image]]" alt="image">
                <div class="card-content">
                    <h1 class="card-text">[[article.title]]</h1>
                    <h4 class="card-text">[[article.abstract]]</h4>
                </div>
            </paper-card>
    </template>

</template>

<script>
    Polymer({
        is: 'my-view1',
        ready: function () {
            this.feeds = [
                {name: "Feed1", key: "feed1"},
                {name: "Feed2", key: "feed2"},
                {name: "Feed3", key: "feed3"},
                {name: "Feed4", key: "feed4"}
            ];
        }
    });
</script>

Expected outcome

What I want to do is cache each feed into indexeddb as an entry (feed name as key and the data as value), so they can be loaded when the app is offline.

Actual outcome

However I keep getting indexeddb entry overwritten/emptied when switching tabs. I cannot get my head around the data flow between firebase-query and app-indexeddb-mirror.

Once selectedFeed changes, wouldn't it also change the key of app-indexeddb-mirror immediately (data bindings are synchronous)? In that case the cache with previous key should not be cleared/emptied right?

Live Demo

Steps to reproduce

The question was also posted on stackoverflow:
http://stackoverflow.com/questions/39695594/app-indexeddb-mirror-with-polymerfire

Browsers Affected

  • Chrome
  • Firefox
  • Safari 9
  • Safari 8
  • Safari 7
  • Edge
  • IE 11
  • IE 10

having two different keys in app-localstorage-document

Description

When using the app-localstorage-document element to store data on different keys the data of key1 is overwritten by data for key2 when key2 data is updated.

Expected outcome

When data for key2 is updated it should only write to key2 data in localStorage. Not overwrite data of key1.

Actual outcome

The data for key1 is overwritten

Steps to reproduce

  1. Create an app-localstorage-document element with key="key1" and bind data to something like {{dataone}}
  2. Create another app-localstorage-document element with key="key2" and bind data to something like {{datatwo}}
  3. Make a simple interaction from your app to change the data for key2 (datatwo)
  4. dataone(key1) will now be overwritten with the contents of datatwo

Browsers Affected

Only tried Chrome (Windows) so far

Workaround

I made this patch to make it work but I'm not sure it's the right approach. My data for the different keys are updated as expected anyway.

Implement "cold boot" Firebase capability

As a Polymer (plus Firebase) app user,
when I start the app offline,
I want data input to "just work",
so that I don't have be online to use the app.

The Firebase client library has a "hidden" cold boot mode. Here is an example of how you use it:

// always online ref
var onlineRef = new Firebase("https://my.firebaseio.com");
// always offline ref
var offlineRef = new Firebase("https://my.firebaseio.com", "__offline__");
offlineRef.goOffline();

The second parameter (__offline__) allows the Firebase instance to be booted up and respond to local data changes caused by other such Firebase instances in the app. This is a very useful feature for implementing a "cold boot" mode for Firebase.

In order for this feature to work, the app's online / offline state needs to be monitored. When offline, the "offline" Firebase ref should be used. Then, when transitioning to the online state, the element should switch to using the "online" Firebase ref.

Auto cleanup (LRU)

We cache the user data in local storage for offline usage. We can't use pure Web Worker because we need to support browsers that don't support it and because the cached data can be changed during offline usage.
Since the space for local storage is limited (depending on the browser), it will sooner or later be filled up. At this point, local storage won't accept new entries.

What's the adviced way to regularly (automatically) clean up local storage (eg LRU) using the app-storage elements?

Document `carbon-offline-storage`

As a Polymer element author,
when I make a carbon-offline-storage-based element,
I want the base element to be well documented,
so that I know WTF I am doing.

app-indexeddb-mirror-worker.js and common-worker-scope.js not copied on build

Description

polymer build does not copy app-indexeddb-mirror-worker.js and common-worker-scope.js to the proper folders. This causes common-worker.html:46—return new SharedWorker(workerUrl);—to fail silently. The symptom is that the console logs out App IndexedDB Client connecting.., but the IndexedDB Client never connects.

Expected outcome

If the two files are copied correctly, the new SharedWorker call succeeds and the IndexedDB Client connects as expected. This works fine in development.

Actual outcome

Running polymer build && polymer serve build/unbundled will surface the problem, because the two *.js files are missing in the build. The client never connects.

Temporary Solution

Add the two files to polymer.json in the includeDependencies array. This causes them to copy over correctly during the build process.

"includeDependencies": [
    "manifest.json",
    "bower_components/webcomponentsjs/webcomponents-lite.min.js",
    "bower_components/app-storage/app-indexeddb-mirror/app-indexeddb-mirror-worker.js",
    "bower_components/app-storage/app-indexeddb-mirror/common-worker-scope.js"
  ]

unreachable code after return statement

Description

Firefox logs "unreachable code after return statement"

Expected outcome

For it to work?

Actual outcome

firefox logs "unreachable code after return statement"

Browsers Affected

  • Chrome
  • [x ] Firefox
  • Safari 9
  • Safari 8
  • Safari 7
  • Edge
  • IE 11
  • IE 10

Implement This As A Strategy Pattern

Since the development process often starts by using static JSON files before migrating to other forms of storage, it would be useful if this were implemented as a strategy pattern, with the ability for the developer to switch back and forth between implementations. Something like:

<app-storage config-name="cache+firebase" config="myapp-config.js"></app-storage>

The config file would let you have different named configurations.

[{
  "name":"cache+firebase",
  ... caching config
  ... firebase config
},
{
  "name":"cache+file",
  ... caching config
  ... file config
}
]

how to use app-indexeddb-mirror with firebase. docs issue

Description

the docs show the liveData property 2-way, bound to a firebase-query data attribute, which is immutable. I assume you are supposed to make changes to the app-indexeddb-mirror persistedData property and not firebase, otherwise how would it work offline? so the question is: if you make an observable change to app-indexeddb-mirror.persistedData how can that persist to firebase if it is bound to an immutable firebase-query?

Implement or repurpose thin IndexedDB adapter library

As a carbon-offline-storage user,
when I use the element in my app,
I want offline writes to cache in IndexedDB,
so that they can be re-applied when users of my app go online again.

Currently, the IndexedDB interface is a mocked API that doesn't actually write to IndexedDB. We should change this to something that actually writes to IndexedDB.

The current API (or something very similar to it) should probably be maintained. At least, it should continue to be promise-based so that it fits well with the rest of the carbon-storage (internal) APIs.

Documentation insufficient to use element

The documentation is lacking and not useful when trying to use app-localstorage-document. It is not clear at all how to initialize the storage correctly and get the element to work correctly. I am now trying to use the element, but since it is not clear how to initialize correctly, the value in the localstorage is undefined. However, the element does have the correct key.

With logging on, it lets me know that it is correctly calling the initialized method and got a new value: undefined.

Document `carbon-local-storage`

As a Polymer app author,
when I use carbon-local-storage in my app,
I want the element to be well documented,
so that I know WTF I am doing.

app-localstorage-document push data not sync

page1

<app-localstorage-document key="location" data="{{items}}"></app-localstorage-document>
<paper-button on-click="add_data">add</paper-button>

page1-button-script

add_data:function(){
      this.push("items",{text:"test"})
}

page2 not sync

<app-localstorage-document key="location" data="{{items}}"></app-localstorage-document>
<template is="dom-repeat" items="[[items]]">
        print [[index]] 
</template>

Demo uses `contenteditable`, and it really sucks

What I did

In the demo, I tried to write a note body with multiple lines.

What I expected to happen

The demo let me type multiple lines without any issues.

What actually happened

The demo added a new line but caused the cursor to jump up to the end of the first line.

Proposed fix

Use stylized input and textarea elements instead of contenteditable when editing notes.

Add user authentication to demo.

As a Polymer app author
when I consider carbon-storage for my app,
I want the demo to show how authentication is handled,
so that I know that my practical use cases are addressed.

Demo that shows offline-first Firebase storage capability

As a Polymer app author,
when I evaluate carbon-firebase-storage for use in my app,
I want to see a demo of the element in action,
so that I know how it is intended to be used.

Our first demo is going to be a carbon-firebase-storage demo that shows off offline-first use cases. Proposed offline use-cases:

User goes from online to offline

  1. User is online and loads the app at least once.
  2. ServiceWorker caches the app locally so that it is available offline.
  3. User's network state changes to offline, but data changes can still be made.
  4. User's network state changes to online, and changes made while offline are sync'd to remote storage.

User leaves the app and returns while offline

  1. User is online and loads the app at least once.
  2. ServiceWorker caches the app locally so that it is available offline.
  3. User leaves the app, and returns while offline.
  4. Data changes are made while still online.
  5. User goes online, and changes made while offline are sync'd to remote storage.

Document `carbon-firebase-storage` and friends

As a Polymer app author,
when I use carbon-firebase-storage in my app,
I want the element to be well documented,
so that I know WTF I am doing.

This should include documentation for carbon-firebase-query.

Adding app-indexeddb-mirror-worker.js causes site not to render. Solved.

Adding the require javascript file to my main polymer shell element causes the site to not render.
<script src="../bower_components/app-storage/app-indexeddb-mirror/app-indexeddb-mirror-worker.js">

Solution:
Add the javascript file from the main index.html.
<script src="/bower_components/app-storage/app-indexeddb-mirror/app-indexeddb-mirror-worker.js">

Build Syntax Error

Description

When building with polymer-cli v0.16 causes syntax error. In dev mode everything works as expected.

Actual outcome

App IndexedDB Client connecting...
SyntaxError: expected expression, got '<'
Polymer.AppIndexedDBMirrorClient.prototype.connect/this[e]</<()

Live Demo

Steps to reproduce

Syntax error appears when the page loads

Browsers Affected

Any browser

How I resolve SyntaxError: expected expression, got '<'

Description

Have been dealing with the evil SyntaxError: expected expression, got '<' on Firefox in the last couple of days and had totally no idea what had been gone wrong. Everything worked fine and great on Chrome 55, Opera 41, Safari 10 but not FF 50+.

***Update: This error SyntaxError: expected expression, got '<' is most likely to happen when Service Workers is enabled and working fine on the browser. Since Service Worker in SPA will re-route basically anything that is not found to /index.html (according to default configuration) and so it does the same for .js. That's why when app-indexeddb-mirror is looking for its .js files Service Worker couldn't find it and just routed it to /index.html which then caused SyntaxError. In order to resolve that, we have to deliberately tell Service Worker to cache all the .js files within app-indexeddb-mirror like the following:

// sw-precache-config.js

module.exports = {
  staticFileGlobs: [
    '/index.html',
    '/manifest.json',
    '/bower_components/webcomponentsjs/webcomponents-lite.min.js',
    '/bower_components/app-storage/app-indexeddb-mirror/app-indexeddb-mirror-worker.js', // Ask sw to cache `app-indexeddb-mirror`'s .js files
    '/bower_components/app-storage/app-indexeddb-mirror/common-worker-scope.js' // Ask sw to cache `app-indexeddb-mirror`'s .js files
  ],
  navigateFallback: '/index.html',
  navigateFallbackWhitelist: [ /^\/[^\_]+\/?/ ] // Firebase Auth's exception route.
};

***Additional step for Firefox: Head over to about:debugging#workers in Firefox and unregister all service workers. Clear your offline storage in FF. Do a page refresh and boom!!! Everything works as expected without throwing SyntaxError anymore. Hope this will help those struggling with the evil SyntaxError. 😄

Expected outcome

app-indexeddb-mirror caches all JSONs from Firebase for offline use on all modern browsers.

Actual outcome

FF50+ suffers from SyntaxError: expected expression, got '<'.

Live Demo

N/A

Steps to reproduce

Browsers Affected

  • Chrome 55+
  • Firefox 50+
  • Safari 10+
  • Edge 14+
  • IE 11

Default initialization value is sometimes ambiguous.

As a carbon-storage user,
when I configure carbon-storage with a default data value,
I want deterministic semantics to govern the ultimate value assigned to data,
so that I can expect the same initialization for different storage backends.

Currently, the outcome of initializing a (potentially empty) storage location with a default value is ambiguous. Different storage layers will handle initialization differently, because their zero value for unset locations is different. We should find a way to normalize this so that it is easy to implement new storage layer elements consistently.

Persisted data becomes live data if online state changes

Description

app-indexeddb-mirror
Persisted data gets unlinked when going online from an offline state, why?

__updatePersistedData(client, key, session, online)

Expected outcome

Persisted data stays the same until live data gets updated.

Actual outcome

Persisted data becomes live data when going online even though live data stays the same e.g. undefined

Steps to reproduce

  1. Load some data online (live=persisted)
  2. Go offline & reload (live = undefined, persisted = persisted)
  3. Go online (live = undefined, persisted = live)

Document `carbon-indexeddb-mirror` and friends

As a Polymer app author,
when I use carbon-mirror in my app,
I want the element to be well documented,
so that I know WTF I am doing.

This should include documentation for Polymer.CarbonIndexedDBMirrorClient and carbon-indexeddb-mirror-worker.js.

Fill out compatibility test suite

As a Polymer element author,
when I implement a carbon-storage-based element,
I want a test suite to validate my implementation,
so that I know it is consistent with other working carbon-storage elements.

Storage layers all have unique semantics and constraints related to how data changes over time, and this makes it easier than it might otherwise be to create inconsistent implementations. The compatibility test suite exists so that we can reduce or eliminate inconsistencies between various carbon-storage-based elements.

unreachable code after return statement

app-storage-behavior.html, line 470:

__pathRefersToArray: function(path) {
        return (SPLICES_RX.test(path) || LENGTH_RX.test(path))
            Array.isArray(this.get(this.__parentPath(path)));
},

Missing && expression in return statement:

__pathRefersToArray: function(path) {
        return (SPLICES_RX.test(path) || LENGTH_RX.test(path)) &&
            Array.isArray(this.get(this.__parentPath(path)));
},

Implement Firebase authentication element.

As a Polymer app author,
when I use Firebase elements in my app,
I want an element enables declarative user authentication,
so that it is easy to add user authentication to my app.

Document `Polymer.AppStorageBehavior`

As a Polymer element author,
when I make a Polymer.CarbonStorageBehavior-implementing element,
I want the base element to be well documented,
so that I know WTF I am doing.

common-worker.html#L23 uses incorrect BASE_URI breaks indexeddb SW on Firebase

Description

common-worker-scope.js fails to load with 404 when using polymer cli starter kit and firebase hosting because BASE_URI at https://github.com/PolymerElements/app-storage/blob/master/app-indexeddb-mirror/common-worker.html#L23 is wrong

see also:

Expected outcome

URI should be https://mojibrag.firebaseapp.com/bower_components/app-storage/app-indexeddb-mirror/common-worker-scope.js

Actual outcome

URI generated is

https://mojibrag.firebaseapp.com/src/common-worker-scope.js

service worker fails to load

Live Demo

https://mojibrag.firebaseapp.com

Steps to reproduce

  1. open https://mojibrag.firebaseapp.com on android device
  2. Start chrome remote debugging
  3. reload page
  4. note service worker fails to load

I was able to work around this issue by hacking the currect BASE_URI into common-worker.html but I don't think this is the correct solution

var BASE_URI = "/bower_components/app-storage/app-indexeddb-mirror";

Browsers Affected

  • [X ] Chrome Android

Uncaught TypeError: Cannot read property 'ownerDocument' of undefined

I get the above error when I when I include the app-indexeddb-mirror tag in my element. It also fails to store any data. Any thoughts on the problem?

Uncaught TypeError: Cannot read property 'ownerDocument' of undefined
(anonymous function) @ common-worker.html:17
(anonymous function) @ common-worker.html:102

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.