I'm building a very simple e-commerce screen that shows multiple row of products from different categories (shoes, coats, t-shirts).
I wondering how should I use Cubit in terms of loading that products and pull to refresh them.
I'm thinking about having one Cubit that handles the data fetching of the entire page, but something in me tells me maybe to make a Cubit for every row of products in my home, however this is feels to much boilerplate.
Related
I'm kinda new to flutter web and I wanted to know what is a good, clean way of handling this problem. So consider I have a shop app and the customer has added some products to their cart, this data is saved in my state (I use Riverpod but I reckon it doesn't mater what state management is used). When the user reloads the page, the cart will be empty as expected (since all the states will be reloaded). I wanted to know what is a good way of handling this problem? Should I use cookies, shared preferences, hive, or something else? I just wanted to know what a more experienced developer would recommend. Thank you in advance for any help you provide.
Cookies are usually created by the server, while SharedPreferences is something client specific.
From an architecture point of view, you probably want the server to know about shopping carts (e.g. when the user logs in on a different device; to indicate that product might be sold soon; ... ). This however adds one more layer of complexity and I would only recommend this if you have a good reason for the server to know about it.
The simple straightforward path I would take for a private project is to save it in SharedPreferences. You can write a toJson and a fromJson function and save/load your cart as stringified JSON.
You can later still decide to move that logic to the server over the course of your application if there turns out to be a business need for it.
I'm working on an e-commerce website using the MERN stack, I'm about to start retrieving data from the db so I came with this question:
what is the best way to deal with dbs? do I have to keep fetching data each time the user switches from a category to another or just do it once and use it everywhere ?
I tried both but I would like to know others opinions.
I would say it depends on how you implement your e-commerce application.
If you are creating multiple pages of categories then on each page you would do a request. If its a single page application then you would need to get all of your information so that you can display it all when the user goes to that page. If that single page application has a really long page with lots of documents, then you could implement something like pagination or infinite scroll where you would call for more documents as needed.
It's really about how you set up your application. You most likely will make new calls when going to new pages, or one call on a single page with few documents. CRUD - create, read, update, destroy, will all need their own routes as well, which you will obviously call when needed. Although, those don't always have to be implemented on the frontend if you plan to maintain your application from the backend then you can of course tap into MongoDB through the shell.
I was able to implement Firestore Pagination using a stateful widget but would love to re-write it using Riverpod's ChangeNotifier.
The challenge is that the fact that two functions are used, one for getting the first chunk of documents and the other for getting the rest, then adding them to the previous documents, the aspect of a scrollController to fetch more documents as the user scrolls and keeping track of the loading state when fetching more documents makes it a little challenging.
There is a package called paginate_firestore that helps with firestore pagination but it lacks caching and the ability to map firestore documents to a model class.
Thank you very much.
I currently create a prototype project which implements a lot of features like navigation management, errors management, storage management etc etc
I'm facing now a question with blocs.
I want to know which is the best practices using blocs, in fact, imagine I have a product system like list of products, product detail, select product.
Does I need to have only one bloc which can take 3 events like
Get List Products
Get Product Id
Select Product
with differents states like GetListInitial, GetProductInitial, SelectProductInitial and others for "loaded", "finished" for example
And then in my 2 pages I can use a BlocConsumer which listen, in the listProduct page GetListInitial, GetListFinished and the product Detail page GetProductInitial, GetProductFinished ?
I can also use 2 BlocConsumer in the same page which are listening differents states for example listing products and then select one.
Or
Does I need to have three differents blocs which can take 1 event and do the same process with each bloc.
We can consider that the 1st solution can group events by features but in fact does not respect what Flutter want like works with widget because in my example 3 BlocConsumer will be handle if one event occured, but only 1 will do things.
But in the 2nd solution, it means that if I got a huge application so I will have a very very lot of blocs, right ?
Which is the best solution?
Thanks
I think a good way is having a bloc for each feature, and one repository or storage.
I usually make navigation by passing object's unique id to widget's constructor and then opening modal page with its own bloc, that handles loading description etc.
For example I need to load a list of products. I wrap my main product screen with RepositoryProvider, which provides Product repository. Repository contains all logic i need (fetching, sorting, taking one item from item list with unique id, etc.)
Then, I wrap my page with bloc provider, and pass my repo by constructor, so now bloc whould have access to my repository. Bloc only manages repo to ui connection.
In my list of item i pass item's id, so if i tap on item, i can pass its id to another bloc, that does different logic (for example, opening modal page with description)
Looking for a bit of advice regarding some flutter architecture. I'm building an app that has about 10 screens all stored as named routes and using onGenerateRoute.
I'm trying to implement blocs and streams so that I can broadcast to one page when another page, say, creates a new record (all handled in an online SQL db).
So I have two pages that use one bloc, another 3 pages that need access to another bloc... etc.. Does this mean that only way to provide access is to put a bloc provider for all blocs at the top of the widget tree, making all blocs available to all pages?
I tried to provide access to one bloc individually on two pages by using a provider at the top of each of those two pages... however, I guess this means I am actually creating two separate BloC objects? rather than both pages actually using the same one. So when page B creates a new record, it is not calling page A to reload...
I'd rather not have all pages accessing all BloCs, but is the only way to do it to put the Bloc in a place where it is a single ancestor of any page that needs it?
I'm also rather confused about why we close streams... I thought the point is that they are a continuous source of data... if we close them, are they no longer available to broadcast to subscribers?
Utterly confused, and 3 hours of YouTube videos later, I'm no clearer.
Thanks in advance...
Check this out https://bloclibrary.dev/#/recipesflutterblocaccess?id=generated-route-access
When the Widgets that need the blocs are disposed, the blocs are also should be disposed. Otherwise you're consuming resources unnecessarily by keeping it alive.