If I use Vuex, is that means it's better to store every data in the vuex/state?
I have a little confused, some data I get from API (for example UserDetail), I don't need it be shared in components or I counld easily pass it as props.
Should I keep that kind of data in Vuex/State?
Why not get the data by Promise or only use Vuex/Action/Promise?
Data should be kept as local as possible. That's a general principle that helps reduce complexity. Vuex should handle data that needs to be shared among not-closely-related components.
Related
My question is, what's the point of setting up Vuex for the server when the state will be overwritten when the client side hydration takes place?
I have some data (Helm env variables) that I want to store in the vuex store for later use.
These variables is only available to me on the server, so I started trying to add them to the store in my createApp script when running on the server.
The store state however is reset when the client side hydration kicks in, so no env variables left.
Google told me I should use like window.INITIAL_DATA to set the state again on the client:
store.replaceState(window.INITIAL_DATA)
But if have to use the window object to pass store data to the client, what's the point of using Vuex on the server at all?
Isn't it better to skip Vuex overhead on the server and just use Vuex on the client and populate it with INITIAL_DATA?
I'm probably missing something..
https://ssr.vuejs.org/guide/data.html#data-store
During SSR, we are essentially rendering a "snapshot" of our app. The asynchronous data from our components needs to be available before we mount the client side app - otherwise the client app would render using different state and the hydration would fail.
To address this, the fetched data needs to live outside the view components, in a dedicated data store, or a "state container". On the server, we can pre-fetch and fill data into the store while rendering. In addition, we will serialize and inline the state in the HTML after the app has finished rendering. The client-side store can directly pick up the inlined state before we mount the app.
Also to mention:
The data you access while SSR in any Component needs to come from somewhere if you want to share information across Components, this is what Vuex is there for.
One of my Vuex store saves application configurations which get set once and never gets updated. As I've seen so far, we use computed properties to retrieve any store value. The main reason is to re-evaluate the result when the value in the store changes. But as the value of my store is not going to change, then should I directly call the store value or should I use with computed properties only?
Thank you.
If by computed you mean store Getters then no, you don't always have to use Getters to read store state.. You can read store state directly. Just don't mutate what you read. I avoid using store getters unless i specifically need to calculate and cache something.
In my Vue.js project, I have many components, in some of them, those component will all use a fetched data list, called it server_list.
I don't want to fetch it in every component who used it.
so, how can I optimize this?
only in one place to fetch it?
such as, In component_foo, I will invoke fetch_server_list(), in component_bar, I will invoke fetch_server_list() too.
How can I deal with in multi places to fetch server list data?
What's your best way to deal with this?
There are many ways to do that.
Props
Props lets you pass data to child component.
Provide/Inject
Providers lets you pass data nested, more than one level.
Vuex
Vuex stores lets you cache your data in $store object to use later, wherever you want.
I'm new to React, I think the basics have sunk in but I'm stuck on something. We're going to re-build one of our old systems and I'd like to do it in React.
Our system is an internal CRM, each set of client data is about a Mb in size, so efficiency is one of our priorities. The logic is done on a separate API, used by lots of different systems, so 99% of this front end is CRUD only.
(I hope I'm explaining this Ok!)
So onto my question. If I make a small change to a part of the client data, say I add an 'Audit' to the client... there is a chance that LOTS of other data changes. Complex enough that I don't want to replicate the logic both front end & API side.
Would I need to have the API return the full Mb of data, to have the root level app re-render all it's components? Or is there a more efficient way of doing it? Should I be setting up each component to periodically ping the API to check for changes individually?
I'm just a little bit lost where to start tackling the idea of it. Any help is much appreciated!
First things first - React Components rerender when any props or state field was changed.
If you change smth on the client-side and changes should affect server-side which important for user, then you do should updated your app view. To make it more smooth you can use shouldComponentUpdate method of Component's lifecycle to prevent unnecessary re-renders.
If server-side updates are not important for user (some meta data...), then you may not update the state of you application, by that you prevent re-renders.
Imagine this simple case. You have a Vue JS application in which users can create lists of tasks and sort them. These lists should be stored in a database by the server. Let's assume we have a ListComponent which does the bulk of the UX.
My question is, which pattern should I use to handle front-end and back-end data synchronisation?
A) Go through vuex: Store the active lists (those being shown, edited or created) in the vuex store. The ListComponent will change the store and then, the changes made to a list will be sent to the backend through an API.
B) Go directly to the server: Read and write directly from the ListComponent to the server every time a list is shown, edited or created.
If following A, what architecture should the store have? How and when should I kick a synchronisation? How can I keep track of what has changed and what has not?
Both can be correct depending on your use case. The application I'm currently building uses both.
When to use B: Go Directly to the server
Use B if the data is very important to save. In this case you may want to go directly to the server and serve up the response to verify it was committed to the DB. We use this process for Admin type changes. Note that you can also update Vuex after the server response and still use Vuex to serve up your data.
When to use A: Go Through Vuex
Use A if you require faster experience, since there's no waiting for the server. You must be okay with optimistically displaying changes before actually saving. The other benefit is you can sync Vuex to localStorage. We use this for user preferences that are used to customize views. Its a poor experience to slow down the page just to wait on fetching those.
How to use A: Go through Vuex
There's a couple ways to do this. Here's one pattern:
Dispatch Vuex Action 1 from component
Commit Vuex Mutation from Action that updates state - this is an optimistic update as you're assuming it'll go through
Dispatch another Vuex Action 2 from Action 1 - This assumes you'll reuse this Action in multiple Actions, otherwise it can all go in Action 1
Action 2 sends data to server
Upon promise return, Action 2 commits mutation to update Vuex state
Mutation needs to handle any discrepancies (or errors)
Count the cost of Vuex
Like your comment shows, its good to count the cost if you need to use Vuex at all because it does add a lot of overhead and complexity. The ideal is to write your components in such a way as to contain all interactions with one type of data (such as 'Lists') so you do not have to share state through Vuex.