📄️ QueryBowl Scope
The first thing needed for storing any form of data is a store. QueryBowlScope is basically a InheritedWidget which wraps around the actual store QueryBowl. It is similar to ProviderScope in riverpod & MultiProvider provider. It just inject the instance of QueryBowl to the BuildContext
📄️ Query Job
Query Jobs are what you use to define the logic how or from where the data is fetched/queried. It is where the task function is defined. QueryJob is reusable throughout application
📄️ Queries
QueryBuilder and useQuery
📄️ Mutation Job
MutationJob is just like QueryJob but for Mutations.
📄️ Mutations
Unlike queries, mutations are typically used to create/update/delete data or perform server side-effects. For this purpose, Fl-Query exports a MutationBuilder builder Widget.
📄️ Lazy Query
If you ever want to disable a query from automatically running, you can use the enabled = false option in QueryJob
📄️ Dynamic Queries
All this time we've using queries by defining a Query Key in the QueryJob. But what if your widget needs to fetch data from of a dynamic id that is only known at runtime? This is where QueryJob.withVariableKey comes to play. It allows you to define query-key at runtime. It makes a query dynamic
📄️ Dynamic Mutations
Just like Dynamic Queries, MutationJob.withVariableKey makes the mutation dynamic. Both of them are completely same
📄️ Optimistic Updates
What is Optimistic UI Update?
📄️ Paginated/Lagged Query
Rendering paginated data is a very common UI pattern and in Fl-Query, it "just works" by including the page information in the query key:
📄️ Infinite Queries
Rendering lists that can additively "load more" data onto an existing set of data or "infinite scroll" is also a very common UI pattern. Fl Query supports a useful version of Query called InfiniteQuery for querying these types of lists.