Open luandro opened 8 years ago
I'm also curious :)
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.
+1 @colbyr Any updated thoughts since your last comment? I really want Firebase support with Redux.
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
@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.
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
I've just released something similar, while it doesn't actually use Redux it has basically the same API surface.
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.
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!