Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cool idea, any docs? #1

Open
luandro opened this issue Dec 6, 2015 · 8 comments
Open

Cool idea, any docs? #1

luandro opened this issue Dec 6, 2015 · 8 comments

Comments

@luandro
Copy link

luandro commented Dec 6, 2015

The idea of creating a declarative API to interface with Firebase from Redux is awesome. Did it really work? Is it worth it? Will you be maintaining it?

Cheers!

@nelix
Copy link

nelix commented Dec 14, 2015

I'm also curious :)

@colbyr
Copy link
Owner

colbyr commented Dec 15, 2015

I don't have a ton of spare time to work on this right now, but I'll try to give you a broad overview. It's pretty proof-of-concept, but I've been using for a side project (https://limelist.xyz) over the last couple months and it mostly works.

Below is the source of one of my containers in that app. The main thing to notice is the query function which is a bit like a redux select function. Like select, query is used to build a higher order component. It returns a "query" object that the h.o.c. dispatches to the middleware which manages firebase subscriptions and syncs the data it receives from firebase into the store.

The query object kind of looks like the data in my firebase instance. The keys are keys in firebase. The values are functions I've been calling "resolvers" which describe how to process the data found at that keypath. Some resolvers are really simple. For example r.value just returns the value found at it's keypath. Others are more complex and their results generate more subscriptions. r.index(['lists']) assumes it will find an "index" (I'm referring to an "index" as described in the firebase docs) and will resolve each key in the index to a path prefixed with whatever was passed into the resolver call (in this case it will subscribe to a bunch of "lists/{listId}" paths).

Once the data described by the query is loaded it's passed as props to the component wrapped by the h.o.c. In the example below, the result of query is passed to the select which does some rearranging and then passes the final data on to SelectListContainer.

import fetch from '../lib/fetch'
import * as ListActionCreators from '../actionCreators/ListActionCreators'
import React, { PropTypes } from 'react'
import { connect } from 'react-redux'
import { bindActionCreators } from 'redux'
import { resolvers as r } from 'redux-firebase'
import SelectList from '../components/SelectList'

function query({auth}) {
  return {
    users: {
      [auth.uid]: {
        lists: r.index(['lists']),
      },
    },
    listCollaborators: r.byIndex(['users', auth.uid, 'lists']),
  }
}

function select({auth, firebase}, {users}) {
  return {
    lists: users
      .getIn([auth.uid, 'lists'])
      .sortBy(list => list.get('name').toLowerCase()),
    uid: auth.uid,
  }
}

const SelectListContainer = React.createClass({
  propTypes: {
    dispatch: PropTypes.func.isRequired,
    listCollaborators: PropTypes.object.isRequired,
    lists: PropTypes.object.isRequired,
    uid: PropTypes.string.isRequired,
  },

  render() {
    const {dispatch, listCollaborators, lists, uid} = this.props
    return (
      <SelectList
        {...bindActionCreators(ListActionCreators, dispatch)}
        listCollaborators={listCollaborators}
        lists={lists}
        uid={uid}
      />
    )
  },
})

export default fetch(query)(connect(select)(SelectListContainer))

In my dreams, I would want too build this against some sort of firebase schema definition, but that's probably a whole other problem!

I'm interested to hear your thoughts.

@AndersDJohnson
Copy link

+1 @colbyr Any updated thoughts since your last comment? I really want Firebase support with Redux.

@natac13
Copy link

natac13 commented Jan 4, 2016

I am looking for this as well. I started building a middleware to handle all of my firebase actions. It seems this is taking a very similar approach! Glad to see I am on the right track

@AndersDJohnson
Copy link

@luandro, @nelix, @natac13, others: Feel free to try and/or contribute to my brand new work-in-progress project firedux, which has the same goal of integrating Firebase + Redux for ReactJS.

@nyura123
Copy link

I've been using a similar solution (declarative subscriptions, firebase path resolving, nested subscriptions) for my firebase subscriptions - here it is in case anyone finds it useful.
It's not a redux middleware but can easily be turned into one as shown in the README.
https://github.com/nyura123/firebase-nest

@simenbrekken
Copy link

I've just released something similar, while it doesn't actually use Redux it has basically the same API surface.

https://github.com/unfold/react-firebase

@prescottprue
Copy link

Trying to get all of the contributors of these libraries in discussions about which things can be combined in this redux-firebase gitter. Everyone is welcome!

Having a similar discussion with the author of redux-react-firebase, he noted that multiple libraries with different names could add to JS fatigue, and I totally agree.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants