33

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?

cRAN
  • 195
  • 1
  • 2
  • 16
Jose Ospina
  • 2,097
  • 3
  • 26
  • 40
  • 1
    I have just spent a few hours trying to go with A. I ended up with an empty component and all the logic in the store module. Seemed like a lot of overhead, so I am going back to having logic and API calls within my component. – Jose Ospina Apr 23 '17 at 19:16

1 Answers1

29

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:

  1. Dispatch Vuex Action 1 from component
  2. Commit Vuex Mutation from Action that updates state - this is an optimistic update as you're assuming it'll go through
  3. 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
  4. Action 2 sends data to server
  5. Upon promise return, Action 2 commits mutation to update Vuex state
  6. 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.

For the Name
  • 2,459
  • 18
  • 17
  • 1
    I don't understand 5. If step 4 is successful, I don't need step 5 as I already updated the state in step 2. And if step 4 fails, then it seems that's what step 6 is referring to (ie, show an error message, revert the change, etc.) So I'm confused what step 5 means. – Yehosef Mar 05 '18 at 00:01
  • @Yehosef step 2 is an optimistic update. You need some step to verify that the server returned data is the same as what you have. For example, if the data failed to update on the server or if the data was modified by another source (which may or may not apply to your case). You are right that in Step 5 you may not need a mutation and it may just be a check on the returned results. – For the Name Mar 06 '18 at 02:11
  • 5
    when in doubt.. use vuex – pscheit Aug 11 '18 at 20:01
  • 1
    A good UX will show the optimistic update in de UI and, if something fails with the backend, revert the change and show a warning to the user. – echefede Dec 10 '18 at 14:08
  • 2
    @echefede This really depends on the importance of the data. On business applications where data is important, it is often better to make the user wait to KNOW it was properly saved. They may look at the optimistic UI update and think it was loaded and navigate away before getting an error. Again, it depends how important it is that the user needs to be assured it saved. – For the Name Dec 13 '18 at 16:55
  • @FortheName agree. One must carefully chose what data can be optimistically updated. – echefede Dec 14 '18 at 09:06
  • 7
    It's also worth pointing out that Option A is also pretty much necessary if you want to support an offline workflow. Store everything locally, sync when the network is available. – Paul Jan 03 '19 at 12:41