joshforisha / cycle-fire Goto Github PK

As outlined https://firebase.google.com/docs/reference/js/firebase.User

This is a similar, but not identical, storage solution offered by Firebase. It's still in beta.

https://firebase.google.com/docs/firestore/quickstart

Instead of

firebase.database().ref('users/' + userId).set({
    username: name,
    email: email,
    profile_picture : imageUrl
  });

it looks like:

firebase.firestore().collection("cities").doc("LA").set({
    name: "Los Angeles",
    state: "CA",
    country: "USA"
})

Hello,
i want to use the firebase driver in a react native app. When the app opens up the user is not logged
in so firebase returns the Currently logged in user is null. Then all the sources.FIREBASE.get do not put a Listener and when the user finally logs in he is not seeing anything. If i close the app persisting the log in info in Async storage then when the app reopens again the sources.FIREBASE.get works right.
Is this a bug or is it something completely wrong with what am i doing?
thanks

Hi @joshforisha ,

Thank you for the driver! I started a boilerplate / example of cyclejs with firebase, and your driver is the only one using firebase v3 so it has been very useful.

Since my goal is to learn cyclejs and understand how (among other things) a driver works, I rewrote it in javascript, and along the way I made a few changes to your original design which I wanted to share with you. You can find my driver here.

If I understand correctly, it is for now necessary to listen to the "error" channel of your driver to perform write operations to the firebase service. While it is of course good practice to handle errors, it doesn't seem to be the responsibility of a driver to enforce it on users. Instead, we could use a more general "response" channel, which would delegate the responsibility of handling success and error responses from firebase to an outer defined function.

One advantage of this approach is that it would match the API and formats of the official cyclejs/http driver: https://cycle.js.org/api/http.html, both for success and error handling.

What do you think about it?

I haven't used Typescript so far but I am interested in learning so if you think this API change is relevant I can open a PR.

As outlined https://firebase.google.com/docs/reference/js/firebase.messaging

Hi!

I've been fiddling a bit with cycle.js and cycle-fire recently and I couldn't seem to get the first example (sourcing and sinking a number) in your readme to work! The sourcing went fine, and manual changes to the database through the Firebase console got reflected immediately. Sinking, on the other hand, didn't propagate to Firebase. The number did not change, and no errors showed up.

Pardon my debugging, since my TypeScript skills are next to none. What I did was to augment both of the addListener calls in driver.js (yes, the generated JS file) like this (and I'm guessing there's a much better way of doing this...):

        ....addListener({
            complete: function () {},
            error: function (x) { console.error('ERROR', x) },
            next: function () {},
        });

When then clicking on the shuffle button, to trigger the set action, I got a message like the following:

{
    code: "auth/argument-error",
    message: "confirmPasswordReset failed: First argument "code" must be a valid string."
}

Looking at the enums and the ActionType declaration, I found that they share number designations:

    AuthActionType[AuthActionType["ApplyActionCode"] = 0] = "ApplyActionCode";
    AuthActionType[AuthActionType["CheckActionCode"] = 1] = "CheckActionCode";
    AuthActionType[AuthActionType["ConfirmPasswordReset"] = 2] = "ConfirmPasswordReset";
    ...
    ReferenceActionType[ReferenceActionType["Push"] = 0] = "Push";
    ReferenceActionType[ReferenceActionType["Remove"] = 1] = "Remove";
    ReferenceActionType[ReferenceActionType["Set"] = 2] = "Set";

Just changing these manually so that each number is unique fixes the issue and everything works as expected! Like I said, my TypeScript foo sucks, so I'm unable to provide you with a PR, but hopefully this will guide you in the right direction.

Looking forward to hearing from you!

As discussed in #1, currently the error source stream must have a listener bound to it in order for its write effect calls to be operational.