feat(utils): new utilities to simplify common queries

[nt4f04uNd]

What is the feature?
Populates syntax sugar

What version would this apply to?
I wrote my examples on 2.2.6.

Do you have thoughts/examples on how the feature would be used (i.e. API)?
I have a bunch of ready functions I wrote on Typescript. I want you to include them into your library, or something like these ones, because current query structure is very annoying.

Here's a straightforward example, how I use them

import { IAppState } from 'src/store/rootReducer'
import { createFirestoreQueries, createPopulates, populateWithDocId, IMapStoreToProps } from 'myModule'
import { compose } from 'redux';

interface IProps extends
   IMapStateToProps,
   IMapDispatchToProps,
   IMapStateToProps2 { }

interface IMapStateToProps {
   uid: string
}
interface IOwnProps { }
const mapStateToProps = (state: IAppState, ownProps: IOwnProps): IMapStateToProps => ({
   uid: state.firebase.auth.uid
});

interface IMapStateToProps2 {
   privateCollection: object
}
interface IOwnProps2 {
   uid: string
}

// just convinient to have an object, when you have a lot of populates in one firestoreConnect
const populates = {
   privateCollection: createPopulates(
      populateWithDocId('incomingRequests', 'users', 'profile')
   )
}
const mapStoreToProps = (ownProps: IOwnProps2): IMapStoreToProps[] => createFirestoreQueries({
   path: `users/${ownProps.uid}/private/friends/incomingRequests`, populates: populates.privateCollection
})
const mapStateToProps2 = (state: IAppState, ownProps: IOwnProps2): IMapStateToProps2 => ({
   privateCollection: populate(state.firestore, `users/${ownProps.uid}/private/friends/incomingRequests`, populates.privateCollection)
});

export default compose(
   connect(mapStateToProps, null) as any, // as any because something goes wrong in types and I'm getting strange error
   firestoreConnect(mapStoreToProps),
   connect(mapStateToProps2),
)(class Requests extends React.Component<IProps, IState> {

Description

Since I discovered that third argument in populate() from your lib can be a function, I started to write my sugar

createPopulates()

A higher order function. Basiclly is just accepts as many populates objects or populate functions and returns an array of them

Example:

const populates = createPopulates(
    populateWithDocId('incomingRequests', 'users', 'profile')
)

This is same as if you had written like this:

const populates = (...args: any) => [
    populateWithDocId('incomingRequests', 'users', 'profile')(args)
]

populateWithDocId()()

This function proceeds doc id to to the result of query as custom field

parameters:

1. childCollection — name of collection which contains document
2. rootCollection — name of collection which contains values to populate
3. fieldName — alias name to stored field

Second invocation passes dataKey and originalData

createFirestoreQueries()

Creates an array of queries, accepts infinitely many objects of structure { path: <pathString>, populates: <resultOfCreatePopulates>}

Example:

const mapStoreToProps = (ownProps: IOwnProps2): IMapStoreToProps[] => createFirestoreQueries({
   path: `users/${ownProps.uid}/private/friends/incomingRequests`, populates: populates.privateCollection
})

This can be written as:

const mapStoreToProps = (ownProps: IOwnProps2): IMapStoreToProps[] => [{
collection: 'users', doc: ownProps.uid, subcollections: [{
      collection: 'private', doc: 'friends', subcollections: [{
         collection: 'incomingRequests'
      }]
   }],
   populates: populates.privateCollection
}]

pathOptions() ???

Alias of JSON.stringify()
For using in createFirestoreQueries()'s path

Basiclly you can add additional query params to path on every level.
I wrote this function, but now I doubt in her need.

parameters:

1. options — object with additional query params, such as where or startAt

Example:

createFirestoreQueries({
   path: `users/${ownProps.uid}/private(${pathOptions({
      where: ['nicknameId', '==', 'example']
   })})/friends/incomingRequests`
})

It's replacement for

[{
   collection: 'users', doc: ownProps.uid, subcollections: [{
      collection: 'private', doc: 'friends', where: ['nicknameId', '==', 'example'], subcollections: [{
         collection: 'incomingRequests'
      }]
   }],
   populates: populates.privateCollection
}]

[nt4f04uNd]

I can send you all my source code if you want

[prescottprue]

Love the idea! I was working on something similar to createFirestoreQueries for standardizing query config in v1.0.0 of redux-firestore.

Not sure I fully understand the upside of populateWithDocId, but definetly open to discussing that some more.

[nt4f04uNd]

Not sure I fully understand the upside of populateWithDocId, but definetly open to discussing that some more.

It just adds doc id to the result of a query as field, that you pass in third argument

e.g.
such structure

becomes that

so then you can easily populate it

[prescottprue]

@nt4f04uNd I understand what it is doing, but how is that different than just using populate directly? The basic example in the populate docs is actually a population of a single field by id.

As for pathOptions, I was hoping to go more towards object query configurations instead of building out string paths (especially since v1 has helpers which build these paths based on query configs for use in the store anyway).

[nt4f04uNd]

@prescottprue but in those example we have preset 'owner' field. In my example I do not have such, instead I take this information directly from document ID and add it as field on end request. Or I just misunderstood something?

[prescottprue]

@nt4f04uNd I misunderstood what it was doing because of the naming populate being within the name made me thing that it was doing what populate does (i.e. replace a key with a value) - you are saying that you use that to actually put the key of the document onto the document itself, so you can then use it. Usually folks use ordered for their list, then data for items by key, so the key is already available not actually on the document data (usually as a route parameter, or some other prop). I'm open to the idea, but would like to figure out the potential impact and other possible solutions before adding to the API surface (which is already larger than I had hoped).

[nt4f04uNd]

Usually folks use ordered for their list, then data for items by key, so the key is already available not actually on the document data (usually as a route parameter, or some other prop)

But how am I supposed to populate profile with that information? With my approach it's being populated automatically.

Can you provide me with a simple example, please?

[prescottprue]

@nt4f04uNd just to be clear, I believe you are asking "how would I access the id of the profile within profile object" (i.e. adding the id parameter, not "populating", which describes actually replacing an id with a value).

If that is the case, you shouldn't really need the id directly on your data since you will actually need that id to lookup the data. You can see what I mean in the Project detail page of the material example. In that example, you already need the id to be looking up the project anyway, so you can just use that id from the route param (turns to a prop) instead of it being on the object.

If you are looking for your own user's uid, that is available through state.firebase.auth.uid (matches the firebase auth object which contains identifiers like your UID) instead of state.firebase.profile (the data under your user object).

If you could explain a little bit more why the id must be on the object if you already needed to know the id to lookup the object, then maybe I could provide a better example specific to your case.

[nt4f04uNd]

@prescottprue I have the following structure of firestore on my firebase project. (idk how to image that, so will use json format)

{
   "users": { // users collections
      "userId": { // public user profile documents
         "nicknameId": "nick#0000",
         "private": { // private collection
            "friends": { // document
               "list": { // collection
                  "userId": {},
                  ..... // empty documents with IDs from users collection
               },
               "incomingRequests": { // collection
                  "userId": { 
                     "createdAt": timestamp
                  },
                  .....// documents with IDs from users collection
               },
               "outcomingRequests": { // collection
                  "userId": { 
                     "createdAt": timestamp
                  },
                  .....// documents with IDs from users collection
               }
            }
         }
      }
   }
}

I need to render data from subcollections of friends document on some page in my app, so I have to populate every user profile from these subcollections for I could display their nicknameIds. To do this I must add userId from title of every document to it's body, because it's the only way to make population - the populateWithDocId()() does exactly that.
Just to be clear I remind that populateWithDocId()() is function that breaks into third argument of populate() from your library and adds dataKey to originalData when dataKey equals ID (not equals undefined or childCollection, it's just how your lib works, idk).

In this piece of code I invoke it
Here I say, that I want to populate collection incomingRequests from users collection and store this population with profile key. args are dataKey and originalData from your lib

const populates = (...args: any) => [ 
   populateWithDocId('incomingRequests', 'users', 'profile')(args) 
]

Use result of invocation

const mapStoreToProps = (ownProps: IOwnProps2): IMapStoreToProps[] => [{
collection: 'users', doc: ownProps.uid, subcollections: [{
      collection: 'private', doc: 'friends', subcollections: [{
         collection: 'incomingRequests'
      }]
   }],
   populates // here it is
}]

Structure of collection without using populateWithDocId()()

 incomingRequests: { // collection
    G1Du7bXodeR3JLKdFuDhlD4t6WW2: {  // user doc
         createdAt: timestamp
    },
    ......
 }

With using

incomingRequests: { // collection
    G1Du7bXodeR3JLKdFuDhlD4t6WW2: {  // user doc
         createdAt: timestamp,
         profile: { 
              id: 'G1Du7bXodeR3JLKdFuDhlD4t6WW2', // this property appears without my want, likely comes form you lib
              nicknameId: 'nick#0000'
         }
     },
     ......
 }

I hope I explained this thing clearly