v2.0.0 Roadmap

Roadmap

Current Status

Stage: alpha

While in the alpha stage the following will apply:

• All PRs will be against the alpha branch
• Releases will be to the @alpha npm tag

Breaking Changes

• ordered and data state reducers store data differently - this will break most advanced and subcollection queries (detailed below in the open discussions section)

Features

• State value selecting utilities firestoreDataSelector and firestoreOrderedSelector to simplify loading data from state (more info in open discussions section below)

Installing

To install the alpha version run: npm i --save redux-firestore@alpha or set alpha as the version of redux-firestore in your package.json

NOTE This is an alpha version so use at your own risk

Open Discussions

If you have any input on the following pattern discussions, feel free to reach out over gitter

Subcollections No Longer On Doc

Query Config

{
  collection: 'projects',
  doc: 'myProject',
  subcollections: [{ collection: 'events' }]
}

Old State Structure

// Data
{
  projects: {
    myProject: {
      events: {
        ABC123: {
          
        }
      }
    }
  }
}

// Ordered
{
  projects: [
    {
      id: 'myProject'
      events: [
        {
          id: 'ABC123'
        }
      ]
    }
  ]
}

New State Structure

// Data
{
  projects: {
    myProject: {
      name: "My Project"
    }
  },
  "projects/myProject/events": {
    ABC123: {
      some: 'data'
    }
  }
}

// Ordered
{
  projects: ["myProject"],
  "projects/myProject/events": ["ABC123"]
}

Problems This Addresses:

• Document parameter name can not match subcollection name
• Updating subcollection and doc from same collection causes collisions requiring merge to be used
• Updating array inside document not working as expected - #140

State Selection Utilities

Utilities are being added to simplify selecting data from state. The current names are firestoreDataSelector, and firestoreOrderedSelector, but they are subject to change.

They work by creating a state selector function when passed your query config:

import { firestoreDataSelector, firestoreOrderedSelector } from 'redux-firestore'

const projectsQuery = {
  collection: 'projects'
}

// projects selectors (using query config function)
const getProjects = firestoreDataSelector(projectsQuery)
const getOrderedProjects = firestoreOrderedSelector(projectsQuery)

compose(
  firestoreConnect((props) => [
    // Projects query listener attached
    projectsQuery
  ]),
  connect((state, props) => ({
    projects: getProjects(state), // projects by key
    orderedProject: getOrderedProjects(state) // ordered projects array
  }))
)

Pattern: Query Config As A Function

It may be helpful to store you query configuration as a function. This will allow the same configuration to be used anywhere props are available including in state connection and listener attachment (firebaseConnect). There is no change in API here, it is just a nice way of generating query configurations so they can be reused:

import { firestoreConnect } from 'react-redux-firebase'
import { firestoreDataSelector, firestoreOrderedSelector } from 'redux-firestore'

// Query config function
function getProjectQuery(props) {
  return {
    collection: 'projects',
    doc: props.projectId
  }
}

compose(
  firestoreConnect((props) => [
    // Projects query listener attached (using query config function)
    getProjectQuery(props)
  ]),
  connect((state, props) => {
    // project selector (using query config function)
    const getProject = firestoreDataSelector(getProjectQuery(props))
    return {
      // projects from state to props
      projects: getProject(state)
    }
  })
)

Why? How one selects from state (a selector) directly relates to how data is queried since the query config dictates where data will be stored in state through redux-firestore

Whenever there are changes to query configurations, all queries (firestoreConnect), state connections (connect) will update as well.

Methods (add/update) updating state directly

There has been questions, including in #82, about if methods update state directly. That means that a listener does not have to be attached for state to update when calling methods such as add and update.

Currently these methods dispatch actions, but do not update their parent state. It would be nice if this was offered as an option in v1.0.0.