Blinking/Uncatching Behaviour

I’m using this repository with a react application with react router, and what I’ve found is that it has a problem regarding blinking before things actually start loading; that makes sense because it’s the time that it takes the request to be performed to the update the state.

Also if I have no connection during an operation it will just, never work; it will not even seek for old data in that was already used.

I have a proposal, I could make a PR for it in which I’d use mozilla’s localForage library to store objects, being in, IndexedDB, WebSQL or even localStorage; and use them to populate the element rather than firebase itself.

Eg. in browsers that support IndexedDB the flow will be Firebase -> IndexedDB -> ReactFire

If for some reason it’s disconnected Firebase -/-> IndexedDB -> ReactFire

IndexedDB will keep serving ReactFire, and will avoid blinking if resources have not changed as it’ll be pretty fast accesible, the app will keep working even without internet unless a resource that has not been catched is asked for, load times of pages will be basically none and it’ll sync first with the local and then with the remote. In very old browsers that don’t even have localStorage, then it’ll work as normal.

Precaching previous using a resource will be also possible, and of course, deleting resources from the local. eg.

ReactFire.catch(myRef)
ReactFire.delete(myRef)

//or

ReactFire.catch('/documents/-123124dkfasd')
ReactFire.delete('/documents/-123124dkfasd')

In the case of browsers with no support this function will do absolutely nothing.

once in a component I do.

this.bindAsObject(myRef,'value')

I’ll get, in fact; the value stored in my IndexedDB, WebSQL; database, rather than directly from firebase, and any update done by firebase inside those storages will cause my element to update, in fact, it’ll be totally backwards compatible.

Without support of those storages it’ll work just as designed now.

There are several considerations with this, and it’s that the product will be somewhat bigger and it’ll have dependencies.

Also for some reason I can’t get how your source code is structured, it seems like it’s already processed by browserfy or the like; is there any original source code?

[alexwilson]

I could see that working really well, and best of all would be framework agnostic. This kind of client-side caching seems almost like an absolute necessity when pulling information to build the state of an app, when the network can be slow or unavailable.

[jwngr]

Hey there, thanks for the discussion so far. I agree that this seems like more of a thing that belongs in the core Firebase SDK, not ReactFire. Unfortunately, the core Firebase SDK is not yet open sourced, so for now, you’d have to build a wrapper around the SDK which has this behavior. Note that we have longterm plans to bring true offline persistence to the JavaScript SDK like we have with the mobile SDKs, but it is still a good deal off.

Marking as “invalid” just because this isn’t the right place to introduce this kind of behavior. I definitely would love to see you make something like this, but I think it should live independent of ReactFire.

Let me know if you’ve got questions.