You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Thank you for creating this amazing library! I'm working on a use case that I think fits perfectly with this plugin's capabilities.
Use Case
Multiple Layouts:
I have multiple layouts, such as a.layout, b.layout, and c.layout. Each layout has associated pages (e.g., a1.page and b1.page). Avoiding Redundant API Calls:
When a user navigates from a1.page to b1.page, I make similar API calls for a.layout. Using this plugin's query caching, I can avoid deduping these API calls, which is fantastic!
Token Validation on Layout Changes:
On every layout refresh or change, I need to validate the user token by making an API call. This validation returns vital user information such as email, firstname, lastname, etc.
Challenges and Questions
Synchronizing the User Store with the Query Cache:
I need to store the fetched user info (email, firstname, lastname, etc.) in a centralized userStore.
How can I ensure that the query cache and the store remain synchronized? For example, If I update the user name I need call the same api to update the user info across the app?
How to access QueryCache in the store for preparing the computed data. Like creating user full name, by joining firstName and lastName etc.
Dependent API Calls:
After the initial token validation API call, I get a userId.
Using this userId, I need to make 10 parallel API calls, each fetching specific user-related data (e.g., preferences, settings, etc.). Each API has its own query and caching logic.
What is the best way to organize these dependent API calls and ensure the results are efficiently stored in their respective queries or the userStore?
Ideal Solution
I'm looking for best practices or examples on:
Keeping the query cache and the userStore synchronized.
Managing dependent API calls where one query's result is required for multiple subsequent parallel queries.
Structuring the Pinia store and queries for scalability and maintainability in such a setup.
This discussion was converted from issue #121 on December 01, 2024 04:06.
Heading
Bold
Italic
Quote
Code
Link
Numbered list
Unordered list
Task list
Attach files
Mention
Reference
Menu
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Hi,
Thank you for creating this amazing library! I'm working on a use case that I think fits perfectly with this plugin's capabilities.
Use Case
Multiple Layouts:
I have multiple layouts, such as a.layout, b.layout, and c.layout. Each layout has associated pages (e.g., a1.page and b1.page).
Avoiding Redundant API Calls:
When a user navigates from a1.page to b1.page, I make similar API calls for a.layout. Using this plugin's query caching, I can avoid deduping these API calls, which is fantastic!
Token Validation on Layout Changes:
On every layout refresh or change, I need to validate the user token by making an API call. This validation returns vital user information such as email, firstname, lastname, etc.
Challenges and Questions
Synchronizing the User Store with the Query Cache:
Dependent API Calls:
Ideal Solution
I'm looking for best practices or examples on:
Thank you in advance for your help!
Beta Was this translation helpful? Give feedback.
All reactions