casetext / fireproof Goto Github PK

It seems that catch is no longer attached to the promises:

fireproof.authWithCustomToken(...).catch is not a function

Is this because angular's $q is somehow not spec-compliant?

Below is the working code to access data form firebase. It uses global variable 'Data' array to send it to the final callback function. But I don't want to declare global variable. So is there anyway I can pass my data to every callbacks after it ? below is the code.

var data = {};

getData('myKey', function(){
console.log("myCompleteData: "+ data); //both Id and finalData
});

var getData= function(key,callback) {
return fireproof.child("data").child(key)
.then(CUSTOM_getData)
.then(callback)
}

function CUSTOM_getData(snapshot) {

    var id= snapshot.val().id;
    data.id= id;

return {
then: function(callback) {

fireproof.child("otherData").child(data.id)
.then(CUSTOM_getSomethingFromId)
.then(callback)
  }

};
}

function CUSTOM_getSomethingFromId(snapshot) {

        var finalData = snapshot.val().finalData;
        data.finalData = finalData;

  return {
    then: function(callback) {

    callback(data);
      }  
  };

}

Example:

var firebase = new Firebase(...)
var baseRef = newFireproof(firebase);

function addPost (post) {
  var newPostRef = baseRef.child('post').push(post);
  newPostRef.then(function () {
    newPostRef.child('childRef').set('value', 'something');
    return newPostRef; // If promise and x refer to the same object, reject promise with a TypeError as the reason.
  });
}

addPost({...}).then(function (newPostRef) {
  // use newPostRef
});

Here: https://github.com/casetext/fireproof/blob/master/index.js#L142Promise
Because native Promise expects callback function, so there should be some placeholder.
new newQ(() => {});

From the source:

/*
 * For reasons completely incomprehensible to me, some type of race condition
 * is possible if multiple Fireproof references attempt authentication at the
 * same time, the result of which is one or more of the promises will never
 * resolve.
 * Accordingly, it is necessary that we wrap authentication actions in a
 * global lock. This is accomplished by queuing operations in an array. No, I
 * don't like it any more than you do.
*/

I understand the pain-point you are trying to avoid, but this is a bad idea. It masks the intended behavior of the underlying library.

From the Firebase docs.

All Firebase references to the same database share the same authentication status, so if you call new Firebase("https://.firebaseio.com/") twice and call any authentication method on one of them, they will both be authenticated.

If you point your ref's at two different firebase base URL's (https://firebase1.firebaseio.test, and https://firebase2.firebaseio.test), you should be able to authenticate both of those concurrently without the odd behavior.

You really should not be calling auth twice (concurrently) in your code. If you are it is probably an error. The authorization token from the second call will be used to authenticate the first - even if you have created separate ref instances.

If you really want to avoid this behavior, you can use firebase-copy, which gives you a new Firebase constructors each time, with its own set of global state. In addition to avoiding the auth idiosyncrasies that are frustrating you here, it also improves some client side code testing by ensuring async behavior behavior between ref.set and ref.on('value', listener)

var firebaseCopy = require('firebase-copy');

var Firebase1 = firebaseCopy();
var Firebase2 = firebaseCopy();

var ref1 = new Firebase1(URL);
var ref2 = new Firebase2(URL);

ref1.on('value', listener1);
ref2.on('value', listener2);

ref1.set(newValue);
// => listener1 will trigger synchronously (before roundtrip to server, potentially triggered twice if write is denied).
// => listener2 will fire once asynchronously (after roundtrip to server. Potentially never triggered if write is denied).

I do not recommend firebase-copy for production, just testing.

The global state behavior of Firebase is intentional. It is better to structure your app to deal with those idiosyncrasies directly than trying to hide them.

Now that Promise is standard JavaScript I don't see any reason to fall back to Q promises. Native promises are much easier to debug.

Currently new refs created with the push method cannot be resolved in promise chain. Since the return from .push is an object with the prototype of Fireproof and a .then method, returning it from a promise callback will result in it being treated as a promise thus resolving with undefined since .push doesn't have a resolve value.

Temporary work around:

Fireproof.prototype.getRef = function () {
    let ref = new Fireproof(this._ref);
    delete ref.then;
    return ref;
};

https://github.com/casetext/fireproof/blob/master/dist/fireproof.js#L153

Since it has been deprecated in Bluebird 3 and therefore it shows unnecessary warnings.

Warning: Promise.defer is deprecated and will be removed in a future version. Use new Promise instead.

If the blessed promise library supplies a done() function, we should make that available on Fireproof instances.

If there is no done, we could probably just alias Fireproof#done to the promise library's then().

I was trying to use ref.authAnonymously().then(...) code, and it failed. So, i started debugging it and foud this:

function findOptions(onComplete, options) {
  if (typeof onComplete !== 'function' && typeof(options) === undefined) {
    return onComplete;
  } else {
    return options;
  }
}

Pretty obvious, that typeof(options) will return "undefined" that is string, even when options are not set. This means that condition will never evaluate to true here, so we will receive return options; no matter what we pass as arguments into findOptions.

Hello, based on the contributors list we may have some mutual acquaintances. I am building a new open-source project called fireproof (it's a database that uses cryptographic proof trees).

Is there any chance I could take over the fireproof npm project name? 🍰 Thanks! I can offer the contributors to this project free Fireproof database hosting when it's ready.

Returning a ref from an async function seems to break when the promise is awaited. This is likely do to the regeneratorRuntime checking for Promise-like objects being returned from promises so that they are also awaited. I suppose a temporary work around is to return myRef._ref from any async functions so that there isn't a .then method. Could the return from refs look more like the following?:

let childRef = baseRef.child('child').set('childValue', true);

console.log(childRef);
/* Fireproof {
  _ref: Firebase {...},
  promise: {
    then: function (ok, fail) {...},
    catch: function (err) {...}
  }
} */

This should not be picked up my the regeneratorRuntime's since at the top level it doesn't have any promise methods.

When Demux::get() is called with a count of 1, the method returns the same item over and over again and does not advance down the list of Firebase items. Works when Demux::get() is called with any count greater than 1.

Support Firebase 3.x.

otherwise nobody can find you!

After reading the Firebase docs and playing with this repo, I would expect the following to work, but it seems not to:

var ref = fp.child('myref')
var record = await ref.push({ /* some object */})
console.log(record.key()) // This is undefined

I haven't dug into the code yet, but will do so soon. If this does work, please update the README with an example, thanks!

please check closed commit, thank you

ed: see #14 (comment)

First of all, thanks for this library, very nice.

A question: I have a function call that returns a promise which I resolve with a Fireproof, which I then plan to use to run a on('child_added') query or something similar. However, returning the Fireproof as part of a promise chain means that the .then of the Fireproof object gets called, and I end up with a snapshot instead:

function getFireproof() {
  return doSomething()
    .then(() => {
      return new Fireproof(new Firebase('firebase.io/whatever'));
    });
}

getFireproof()
  .on('child_added')  //explodes here because it's getting a snapshot val back
  .then(doSomething);

Is there a nicer way to do this that I'm missing in the API? I can get around it by hacking out the .then from the Fireproof instance, but that's not ideal.

When blessed, the thing returned from Fireproof is not an actual promise, just an object with a then that is bound to the blessed library's then function. The object is missing the catch method required by ES6 § 25.4.5.1.

Ideally, Fireproof would return a real promise from the blessed library. (When un-blessed -- ie using native promises -- it does appear to return real promises.)

I'm pretty sure this is new to 3.1.

Firebase has a DataSnapshot.exists() method, but FireproofSnapshot is missing this method.

https://www.firebase.com/docs/web/api/datasnapshot/exists.html