redux-firebase/Lobby

Discussion of all things Redux and Firebase (offical room of react-redux-firebase)

gregfenton

@gregfenton

You might use BOTH - Firestore for big things (products, orders, comments) and RTDB for smaller things (likes/rating)

Alfred-Mountfield

@Alfred-Mountfield

That's painfully obvious and I hadn't thought about it (as in mix and matching) which I'm sure comes with its own challenges but yeah that's a good point. Thank you

gregfenton

@gregfenton

Here’s my opinionated view on this whole topic: build it quickly and see if it becomes popular; optimize later.

Alfred-Mountfield

@Alfred-Mountfield

Are there common patterns for trying to bucket actions together into the same request or do people generally just treat it like a standard DB and keep their calls similar to the calls they'd make to redux for example

gregfenton

@gregfenton

The hard part is not optimization, but you can spend a TON of time on it.

If you build something quickly and it doesn’t become popular, you haven’t wasted too many cycles.

Alfred-Mountfield

@Alfred-Mountfield

Luckily I'm not really trying to build an app to make an app, more using this as time to invest into thinking about these problems even if it means I don't get a finished product :)

gregfenton

@gregfenton

If you build something quickly and it becomes popular - then success is your problem….and that is a good problem to have!

Alfred-Mountfield

@Alfred-Mountfield

But fully share your view on it

(That's why I'm asking about the generic TODO app rather than some million dollar app idea I have ;) )

gregfenton

@gregfenton

I’m not in production yet (a few weeks away). I have been developing and testing with the Blaze plan. To date, I have been invoiced for $0.00 on each of 4 projects, all since April.

As for the bucketing question: yes there are patterns. They typically involve uploading data to one document in Firestore and using a Cloud Function to pull info out of that document and spread the info into other documents.

Alfred-Mountfield

@Alfred-Mountfield

That's interesting, so something like a "changes document" where the Cloud function splits it up and creates the respective updates/actions to individual documents?

gregfenton

@gregfenton

That said … I don’t believe that it actually saves anything. You still pay for the reads/writes. You still are moving the data to the cloud (maybe a tad smaller for meta-data overhead….)

Alfred-Mountfield

@Alfred-Mountfield

I mean if you were going to make 50 changes to one document, I guess you could do those in one write rather than 50? But yeah it does seem like a micro-optimisation

gregfenton

@gregfenton

Yes, i use that pattern in one app for how I register new users. The admin creates a “register_user” record and the Cloud Function does a bunch of backend work to create the actual user, set up default account settings, etc.

Alfred-Mountfield

@Alfred-Mountfield

Yeah that makes sense. Cheers! :)

gregfenton

@gregfenton

Yes, the idea would be to make the update to the doc be a single .update({JSON_STRUCTURE_HERE}} rather than 50 seperate .update({fld_1: val_1})

Cheers!

snrajeev-github

@snrajeev-github

In my case, I have three levels of sub-collections, like so: /accounts/user2@email.com/bank/10003940

It is still returning a null, here is my firestoreConnect request:

export default compose(
firestoreConnect([
{
collection: 'accounts',
doc: 'user2@email.com',
subcollections: [{ collection: 'bank', doc: '10003940' }],
storeAs: 'user2@email.com-accounts-bank' // make sure to include this
}
]),
connect(mapStateToProps),
)(MyComponent);
Could someone please let me know where I am going wrong with the query? Many thanks.

gregfenton

@gregfenton

@snrajeev-github you can simply set it to:

firestoreConnect([
  {
    doc: `accounts/${userID}/bank/${bankID}`,
    storeAs: ‘currentUserBankAccount’
  }]);

snrajeev-github

@snrajeev-github

@gregfenton Thanks for the reply.
Looks like collection is mandatory here, I see the below error with the above code:
Error: Collection or Collection Group is required to build query name

But after some more research I realized that the below works:

firestoreConnect([
    {
       collection: 'accounts',
       doc: 'user2@email.com',
       subcollections: [{ 
               collection: 'bank', 
               subcollections: [{
                     doc: '10003940'
                }] 
        }],
       storeAs: 'user2@email.com-accounts-bank' 
    }
  ]),

But now the problem is I need to iterate over all the sub-collections and the sub-collections within them. For this I need the list of all sub-collections, which apparently Firebase Web SDK does not provide.

Option 1: There are alternate solutions as described in https://medium.com/firebase-tips-tricks/how-to-list-all-subcollections-of-a-cloud-firestore-document-17f2bb80a166

Option 2: The alternative is to flatten the hierarchy by having /accounts/${userID}-bank-${bankID}. But this will lead to other issues, which are solvable, but could be expensive.

So I am weighing between the above two options. Which one do you recommend? And am I heading in the right direction?

Thanks and appreciate your advise.

gregfenton

@gregfenton

I fear you are trying to make the technology do something it isn’t designed to do, rather than find a way to work within it (…or possibly…determine that this is the wrong tool for the job?)

A document store, and Firestore in particular, is not really a “tree structure”. It isn’t designed for iterating over all of the documents and subcollections.

Firestore is, actually, not really a “tree structure”. You can create the document my_top/1234/my_level2/AAAA/my_level3/ACT-123 without ever actually creating the my_top collection. The doc will be created at that path and “be there”, but you can’t navigate to it via the Firebase Console.

It would be helpful if you described what business problem you are trying to solve before we get into how it could be handled in Firestore.

gregfenton

@gregfenton

Maybe there is a better/simpler way to achieve a solution. Or maybe we’ll understand the business problem and determine that Firestore is not the right tool for the job.

snrajeev-github

@snrajeev-github

Thanks @gregfenton

I am developing a fintech web-application (using react-js, Firestore and cloud functions) that shows the users their bank details. My web-application is a middleware between the bank and the end-users. The bank's servers "push" data to my cloud functions via web-hooks. I receive the data and update it in Firestore. At this point, there is no way to "push" the data to the end-users (there is the push notification that Firebase provides, but that is not built for this purpose). After some research, I realized that the only way to do this is by registering the client web-application as a listener to Firestore, so that when new data is added to Firestore, the end-users directly receive these updates.

I also thought about setting up websockets but then I realized that it is not possible to do it via Firebase.

And the only other alternative that I can think of is polling via Rest APIs, which I was trying to avoid as it is not recommended by Firebase.

This is how I have arrived at this potential solution using Firestore.

gregfenton

@gregfenton

Firestore might be a good solution (RTDB might be worth a look too). I’m not debating the real-time notification nature of the tech. It is about the document storage approach you are trying to do.

Maybe there’s a better approach where you are storing & retrieving data in a way that is more inline with how Firestore works?

like, maybe have a banks{ } object (or array) on the /accounts/user2@email.com document rather than having a subcollection with separate documents?

or maybe have the “banks” subcollection, but at least list the IDs of the documents as an array within the /accounts/user2@email.com document ?

The way I go about thinking on this element of FS data design is NOT to think about the data, but to think about the APP.

gregfenton

@gregfenton

Think about each screen you will have. Consider the idea of just fetching a SINGLE document to fill the entire screen.

That way, you should never need to “list all the docs in the subcollection XXX”.

snrajeev-github

@snrajeev-github

Thanks @gregfenton . Yes, I thought about that and seems to be the best way forward. If I flatten the "tree" and remove this hierarchy then that will solve this problem.

But it is surprising that the cloud functions SDK apparently provides this ability to list all docs in a sub-collection but not the client side web SDK. Anyway, I don't think it is a good design to make multiple round-trip calls to the cloud functions just to get the list of docs.

You are right, I think this is the solution to this problem:
like, maybe have a banks{ } object (or array) on the /accounts/user2@email.com document rather than having a subcollection with separate documents?

I need to restructure the way I store the data so that it fits the model you suggested above.

Thank you @gregfenton , appreciate your help! This was a great exercise for me where I learnt so many new things about Firestore!

gregfenton

@gregfenton

I recommend thinking through the 2nd last sentence I wrote. That is a lesson I have picked up after speaking with many a React & Firestore developers:

Think about each screen you will have. Consider the idea of just fetching a SINGLE document to fill the entire screen.

so maybe you still have a BANKS subcollection with each document having info of a single bank. However, in the ACCOUNTS document (user2@email.com), you would have an array called banks that contains information about each bank that you would show on the ACCOUNTS screen

e.g.:

banks = [
  {
    id: doc_id_of_bank_1,
    name: ‘ABC Bank Inc.’,
    logoUrl: …
  },
  {
    id: doc_id_of_bank_2,
    name: “DEF Securities Co.”,
    logoUrl: …
  }
];

gregfenton

@gregfenton

that way, you can display each of the banks in a list on the ACCOUNTS screen, and if the user wants to drill into a specific bank there would be a link to the ID of that bank. You’d navigate to the BANK screen and you’d fetch the full details of that BANK document (doc_id_of_bank_1).

snrajeev-github

@snrajeev-github

Thank you @gregfenton , that is the perfect solution to this problem, I tried it out and I am able to fetch just the banks array on the accounts screen and when the user drills into a specific bank, I would then read the sub-collection and the document that the user is trying to view.
I appreciate your help very much!

gregfenton

@gregfenton

With pleasure!

solveretur

@solveretur

Do you know whether isLoaded method with firestore works correctly ? I have an issue that it's false only for the first load, after that even if I change the document it loads - the isLoaded is always true - more details here https://stackoverflow.com/questions/64096209/react-redux-firebase-isloaded-only-false-for-the-first-document-when-using-fir - is it a known issue and does someone know how to solve it ?

Jenna Kim

@JennaDJK_twitter

This message was deleted

3 replies

benomatis

@benomatis

@gregfenton I’m guessing it doesn’t make much sense to post my question I already posted in redux-firestore here again…? :)

Let me ask the question differently: in the Redux Persist section of the doc (https://react-redux-firebase.com/docs/integrations/redux-persist.html) if I just added import ‘firebase/firestore’ below import firebase from 'firebase/app’ would I be able to use firestore as the storage engine for redux-persist that way?

16 replies

MikeLundahl

@MikeLundahl

Hi all, I'm new to firebase with redux. Wondering if anyone knows if there's a good way to wait for redux-firestore to get the documents after firing onAuthStateChanged(user => if(user){do stuff}) when signing in?

10 replies

Dawson Botsford

@dawsbot

Hi folks, I've just drained a day with a react-native error I'm getting in redux-firestore. I'd appreciate any help on this, and if we cannot fix it in a day or so, we're reverting all the redux-firebase integration I just worked so hard on.

The error we're seeing in both iOS and Android builds on Circle Fastlane is (view the full build here:

> Task :app:bundleReleaseJsAndAssets
error Unable to resolve module `babel-runtime/helpers/extends` from `node_modules/redux-firestore/lib/enhancer.js`: babel-runtime/helpers/extends could not be found within the project.
Error: Unable to resolve module `babel-runtime/helpers/extends` from `node_modules/redux-firestore/lib/enhancer.js`: babel-runtime/helpers/extends could not be found within the project.


If you are sure the module exists, try these steps:
If you are sure the module exists, try these steps:
 1. Clear watchman watches: watchman watch-del-all
 1. Clear watchman watches: watchman watch-del-all
 2. Delete node_modules: rm -rf node_modules and run yarn install
 2. Delete node_modules: rm -rf node_modules and run yarn install
 3. Reset Metro's cache: yarn start --reset-cache
 3. Reset Metro's cache: yarn start --reset-cache
 4. Remove the cache: rm -rf /tmp/metro-*. Run CLI with --verbose flag for more details.
 4. Remove the cache: rm -rf /tmp/metro-*
    at ModuleResolver.resolveDependency (/home/circleci/mobile/node_modules/metro/src/node-haste/DependencyGraph/ModuleResolution.js:186:15)
    at ResolutionRequest.resolveDependency (/home/circleci/mobile/node_modules/metro/src/node-haste/DependencyGraph/ResolutionRequest.js:52:18)
    at DependencyGraph.resolveDependency (/home/circleci/mobile/node_modules/metro/src/node-haste/DependencyGraph.js:287:16)
    at Object.resolve (/home/circleci/mobile/node_modules/metro/src/lib/transformHelpers.js:267:42)
    at dependencies.map.result (/home/circleci/mobile/node_modules/metro/src/DeltaBundler/traverseDependencies.js:434:31)
    at Array.map (<anonymous>)
    at resolveDependencies (/home/circleci/mobile/node_modules/metro/src/DeltaBundler/traverseDependencies.js:431:18)
    at /home/circleci/mobile/node_modules/metro/src/DeltaBundler/traverseDependencies.js:275:33
    at Generator.next (<anonymous>)
    at asyncGeneratorStep (/home/circleci/mobile/node_modules/metro/src/DeltaBundler/traverseDependencies.js:87:24)

> Task :app:bundleReleaseJsAndAssets FAILED

FAILURE: Build failed with an exception.

I followed the instructions with watchman del, rm -rf node_modules, etc. with no changes in this error. Here are the versions we're using:

npm ls --depth 0

├── @babel/core@7.11.6
├── @babel/runtime@7.11.2
├── @react-native-community/async-storage@1.12.1
├── @react-native-community/datetimepicker@3.0.3
├── @react-native-community/eslint-config@2.0.0
├── @react-native-community/masked-view@0.1.10
├── @react-native-community/picker@1.7.0
├── @react-native-community/slider@3.0.3
├── @react-native-community/viewpager@4.1.6
├── @react-native-firebase/analytics@7.6.7
├── @react-native-firebase/app@8.4.5
├── @react-native-firebase/auth@9.3.0
├── @react-native-firebase/dynamic-links@7.5.9
├── @react-native-firebase/firestore@7.8.6
├── @react-native-firebase/functions@7.4.8
├── @react-native-firebase/messaging@7.9.0
├── @react-native-firebase/storage@7.4.9
├── @react-navigation/core@5.12.5
├── @react-navigation/material-top-tabs@5.2.19
├── @react-navigation/native@5.7.6
├── @react-navigation/stack@5.9.3
├── @segment/analytics-react-native@1.3.1
├── @types/jest@26.0.14
├── @types/lodash@4.14.162
├── @types/react@16.9.52
├── @types/react-instantsearch-native@6.3.0
├── @types/react-native@0.63.25
├── @types/react-native-vector-icons@6.4.6
├── @types/react-native-video@5.0.3
├── @types/react-redux@7.1.9
├── @types/react-test-renderer@16.9.3
├── @types/uuid@3.4.0
├── algoliasearch@4.5.1
├── babel-jest@26.5.2
├── eslint@7.11.0
├── eslint-config-airbnb@18.2.0
├── eslint-config-prettier@6.12.0
├── eslint-config-standard@14.1.1
├── eslint-plugin-import@2.22.1
├── eslint-plugin-jsx-a11y@6.3.1
├── eslint-plugin-node@11.1.0
├── eslint-plugin-prettier@3.1.4
├── eslint-plugin-promise@4.2.1
├── eslint-plugin-react@7.21.4
├── eslint-plugin-react-hooks@4.1.2
├── eslint-plugin-react-native@3.10.0
├── UNMET PEER DEPENDENCY eslint-plugin-standard@>=4.0.0
├── husky@4.3.0
├── jest@26.5.3
├── jetifier@1.6.6
├── lint-staged@10.4.0
├── lodash@4.17.20
├── metro-react-native-babel-preset@0.63.0
├── moment@2.29.1
├── prettier@2.1.2
├── prop-types@15.7.2
├── react@16.13.1
├── UNMET PEER DEPENDENCY react-dom@*
├── react-firestore@1.0.1
├── react-instantsearch-native@6.7.0
├── UNMET PEER DEPENDENCY react-native@0.63.3
├── react-native-actionsheet@2.4.2
├── react-native-appearance@0.3.4
├── react-native-autocomplete-input@4.2.0
├── react-native-awesome-alerts@1.4.1
├── react-native-background-timer@2.4.1
├── react-native-camera@3.40.0
├── react-native-contacts@6.0.1
├── react-native-country-picker-modal@2.0.0
├── react-native-create-thumbnail@1.2.1
├── react-native-device-info@6.2.0
├── react-native-dropdown-picker@3.7.0
├── react-native-fast-image@8.3.2
├── react-native-fs@2.16.6
├── react-native-gesture-handler@1.8.0
├── react-native-haptic-feedback@1.11.0
├── react-native-image-crop-picker@0.34.1
├── react-native-image-picker@2.3.4
├── react-native-in-app-message@1.0.32
├── react-native-iphone-x-helper@1.2.1
├── react-native-linear-gradient@2.5.6
├── react-native-mixpanel@1.2.3
├── react-native-modal@11.5.6
├── react-native-modal-datetime-picker@9.0.0
├── react-native-mov-to-mp4@0.2.2
├── react-native-permissions@2.2.2
├── react-native-popup-menu@0.15.9
├── react-native-pose@0.9.1
├── react-native-progress@4.1.2
├── react-native-reanimated@1.13.1
├── react-native-safe-area-context@3.1.8
├── react-native-screens@2.11.0
├── react-native-sms@1.11.0
├── react-native-snap-carousel@3.9.1
├── react-native-swiper@1.6.0
├── react-native-tab-view@2.15.2
├── react-native-track-player@2.0.0-rc13
├── react-native-vector-icons@7.1.0
├── react-native-video@5.1.0-alpha8
├── UNMET PEER DEPENDENCY react-native-web@*
├── UNMET PEER DEPENDENCY react-native-windows@>=0.62
├── react-redux@7.2.1
├── react-redux-firebase@3.7.0
├── react-test-renderer@16.13.1
├── redux@4.0.5
├── redux-firestore@1.0.0-alpha.2
├── redux-persist@6.0.0
├── redux-promise-middleware@6.1.2
├── redux-thunk@2.3.0
├── rn-fetch-blob@0.12.0
├── typescript@4.0.3
└── uuid@3.4.0

Trevor Hartman

@devth

has anyone played with optimistic updates? i'm building a chat feature and it's just too slow with useFirestoreConnect and a click handler that calls .add on a firestore collection

Where communities thrive

People

Repo info

Activity