I want to know how to manage BLoC pattern for Firebase.
I couldn't find any example of BLoC for Firebase so it might be broad but forgive me.
I saw some basic BLoC implementation but those were basically fetch data or updating view in a active way not passive way also not through database(almost API JSON stuff).
So, I want to see how to handle some BLoC pattern for Firestore like get followed(passive way), when user update own profile info something like that.
Does anyone lead me to the correct way?
Any help is highly appreciated!
What BLoC pattern gives you is nothing more than a data stream that can be updated adding new data through the stream.sink.
Using Firestore you already have a data stream, so you might not need BLoC.
If your application requires a more complex logic you might update you BLoC data adding a listener to a firestore ref in the root widget to have db and bloc always in sync (maybe with multiple blocs for multiple db refs).
Related
I am building a firebase web application. Here is a simplified Firestore structure:
...
- ...
ITEMS
- item1
PHOTOS
- photo1
uid
VIDEOS
- item2
USERS
- uid1
displayName
...
- uid2
- ...
When someone accesses a photo or video I want to display the appropriate displayName and profilePhoto for that item.
I see two possible solutions:
Store only user UID in items. On every load, get user data from USERS collection or Then loop in user's UIDs and connect them with item UIDs. This would be done on every call. When users update displayName or profilePhoto, there wouldn't be any problem.
Store user UID, displayName, and profilePhoto path on the item. When users update data I would need to run a cloud function which would then update all items with new data.
How should I approach this and is there any other approach that I should consider? I lean towards the second solution.
What you have are the two most common approaches. The first is commonly referred to as performing a client-side join, while the second is duplicating/denormalizing the necessary data.
Neither is pertinently better than the other, but folks who are new to NoSQL databases are typically hesitant to duplicate data so tend to gravitate to performing client-side joins.
As you gain experience in NoSQL data models, you'll learn the right questions to ask yourself. For example: how often do a display name and profile photo change in my app? If that happens infrequently, duplicating those values in each item will make my reading code a lost simpler, faster, and more scalable.
For more good reading/watching on this:
How to write denormalized data in Firebase
NoSQL data modeling
Todd's excellent video series: Getting to know Cloud Firestore
I have a simple question. I am building a Instagram clone app and I want to show each user to their friends. Also they can see the friends list. I am using cloud firestore approach. However I'm a little bit confused about how to store user's friends data? . Should I create a new collection as friendsList
or should I hold the data in users collection as a friends array ?
In the first approach I will create the user data again when some user adds a new friend. Am a new for both firestore and NoSql I would be thankful If anyone can explain.
I'm not going to "answer" as such, but explain the philosophy of NoSQL a bit. The best approach is to design your queries first (i.e. what do you want to get from the database), then design your database schema to make getting the results of those queries efficient and affordable. There are many ways to organize data; you want to take advantage of NoSQL "schema-less" to make your schema match your needs, not the other way around.
Other things to keep in mind: DRY is less critical to NoSQL. Static data (i.e. never or rarely changes) can be stored in multiple places (i.e. a friend's name might be in their profile and in a friends-list) if that saves reads & writes (which are the biggest factor in costs).
So how to organize your database? I don't know; what do you want your database to do?
I should read to this tutorial.This tutorial about is MySql but not important for me if you understand this tutorial you can apply firebase.
I leave a tip below.
I'm trying to create a list of cards, those cards take information from Firestore a query (need .where) it all worked out until I passed my quota, a bit later I found out about this: https://www.youtube.com/watch?v=Lb-Pnytoi-8. I need to read specific documents with .where and post them in a streambuilder, I've thought of multiple options (mostly around Future, JSON) which non of them worked. I've theoretically thought of somehow pausing a streambuilder and reenabling it every pull-to-refresh or making a quota through a futurebuilder but I had no luck.
Here's my code:
Code
I couldn't find an efficient way to do this, any luck anyone?
Apologies for this question. For community members who seek the same answer: using methods such as initState, async or anything alike will cause the widget to rebuild - ergo send once more an API-request.
I'm really interested in the synchronized database paradigm championed by Firebase and others (Couchbase Sync Gateway for example). It really does a great job in replacing 80% of what an API does, which is storing and retrieving data. But usually, that's not all an API does. While we are storing and retrieving data, we are also doing non-data related stuff like sending emails or push notifications. To do those things, I should be able to intercept data changes and do something when a new record is created, when an existing record is changed in a certain way, or when a record is deleted. Parse has a great mechanism for that in its Cloud Code (https://parse.com/docs/cloud_code_guide#functions-aftersave) but I couldn't find something similar in Firebase. Did I miss something or am I thinking of it the wrong way?
firebaseRef.on('child_changed', function(childSnapshot, prevChildKey) {
// code to handle child data changes.
});
This is the article : https://www.firebase.com/docs/web/api/query/on.html
child_change event
For a while I was using the deprecated .removeOnDisconnect() function to manage client presence, so some documents now permanently show that there are multiple viewers even if there is only one looking at their document. To fix this, I want to delete all children of "clients" for each scratchpad. I read through the docs, but couldn't find a good way to do this. Any suggestions?
My data tree looks like this:
scratchpad.firebaseio.com/:scratchpad_id/clients/:client_id
Firebase doesn't have an operation like you describe (yet).
I'd recommend attaching a "child_added" callback at the root of your Firebase, and then for each child, deleting the "clients" location. This would require you to sync the entire Firebase, but for a server running Node.js that may not be a big deal.