Seamless data interaction - Overview

Non-inductive data interaction means that when users interact with the application, relevant content can be displayed immediately without waiting, or the operation result can be displayed without waiting when submitting information, just like interacting with local data, thereby greatly improving the smoothness of the application It allows users to not feel the lag caused by data transmission.

This is not new. The concept of optimistic update existed before 2015. It refers to displaying the submission results to the interface before the server responds. It is based on the assumption that most submissions are successful. The opposite is a conservative update, that is, the server will display a wait state before responding until the request is completed. In terms of handling failures, the current optimistic update solution is usually handled through fallback, such as the following sample code:

const list = [];
const data = {};
addTodo(data).catch(() => {
  list = list.filter(item => item !== data);
});
list.push(data);

This can cause the following problems:

1. Rollback will increase the user's understanding and operation costs;
2. Request timing issues;
3. If subsequent requests depend on this submission, this failure will make subsequent requests meaningless;
4. Possible lost requests;

After several months of program design and continuous iteration, alova has taken a big step in this area. In our program, the above problems have been solved, which can ensure the success of the request more stably. Although there are still technical limitations, But it has been applied in many scenarios. In our technical solution, the problems caused by network fluctuations can be reduced to a higher extent. Your application is still available in high-latency networks or even disconnected, and the latest data can still be maintained after refreshing the page.

Application scenarios

Although non-inductive data interaction cannot be used on a large scale, it is very suitable in certain scenarios. During the exploration, we found at least including but not limited to the following scenarios for your reference.

Editor application

Note-taking applications such as Evernote and canvas editing applications such as MasterGO need to meet the following requirements:

1. When entering the note or drawing list, the list data will be pulled in full, and the local cache data will be used next time;
2. Real-time synchronization to the server during the editing process, and the synchronization process occurs in the background, which will not affect the normal use of users;
3. You can continue to use it even when the network is poor or disconnected;

Setup module

The setting module composed of commonly used switches and selectors needs to realize the requirement that the user operation is synchronized to the server in real time, and the submission status is no longer displayed, but the latest status after the operation is directly displayed.

Simple list management

The data we fill in when creating a list item is enough for the display of the list page, which is called a simple list. For example, a student list page displays the three data of the student's name, gender, and grade. These three data are required when creating a student fill in. In a simple list the following requirements will be fulfilled:

1. Immediately display the latest status on the list page when adding, editing and deleting list items, no need to display it after the submission is completed, and it is not limited by network fluctuations;
2. When the page is refreshed, the list page is always kept up to date;

Complex list management

A complex list means that the data filled in when creating a list item is not enough for display on the list page, and additional data needs to be generated according to the calculation of the server. For example, a Todo list page needs to list specific executions in addition to displaying basic information. date, but only the execution date range and related rules are specified on the creation page, so the execution date is calculated and generated by the server based on the date range and rules.

The following requirements will be fulfilled in a complex list:

1. Immediately display the latest status on the list page when adding, editing and deleting list items, and update the data calculated by the server to this list item after the server responds;
2. When the page is refreshed, the list page is always kept up to date;

example

Stay tuned for complex list examples...

Free Mode

In the above scenarios, you may want to judge whether to use the non-inductive interaction strategy or the most common conservative request strategy based on a condition. The requirements are as follows:

1. When the network status is good, or paying users will use the non-sensing interaction strategy, but when the network fluctuates greatly, or free users cannot enjoy the non-sensing interaction strategy;
2. Strategies can be switched freely;

example

In the above examples, you can experience the free switching strategy

Not recommended application scenarios

Information sharing class

The submitted information needs to be synchronized to others, such as order information. This type of information has high real-time requirements, and we should ensure that the submission is successful.

Complex data interaction class

Complex data interaction refers to the mixed editing and filtering of data, such as adding, editing, deleting and filtering a certain list. In this case, Alova cannot currently support it well. In subsequent versions Will try to solve this puzzle too.

Technical solutions

In the technical solution of non-inductive data interaction, alova has implemented data pre-fetching and silent submission respectively. Next, let's understand these two technical solutions.

info

Please make sure you have mastered the following chapters before reading

• Basic Learning

Data pre-fetching

In html, you may have seen such a tag <link rel="prefetch" href="index.css" as="style">, which tells the browser to preload the style file when it is idle, and put it in the cache In , when you really need to use it, you can take it out of the cache. Alova also uses a similar scheme to pre-fetch the required data through useFetcher, and it will be stored locally. in cache. You can predict the content that the user needs to read under any circumstances, and then pre-fetch the corresponding content. For example, the content of the next page can be pre-loaded in the process page, or the user stays on a button 200ms, we can pre-fetch the data needed for the next interface, which is similar to Next.js page preloading.

Silent submit

Silent submission is a mechanism of submitting and responding. In the scheme, the completion of submission will be guaranteed, so it can be regarded as a safer optimistic update scheme. Silent submission mainly uses Silent Queue to persist request information and ensure request timing issues. Virtual data is used as a placeholder for server response data, which is replaced with actual response data when the request is completed. , through these two technologies, localized data creation is realized, and operations such as editing and deleting of newly created data are realized, even if the created data has not yet been submitted successfully on the server side. In order to keep development costs to a minimum, this is done automatically in alova.

Quiet Queue

Silent queues are used to ensure the timing of requests. We can create queues arbitrarily, and all requests entering the queue will be stored in the queue in the form of SilentMethod instances. Each SilentMethod not only contains request information, but also Contains related configurations for silent submission, such as unique id, error retry parameters, etc. The requests in the queue will only initiate the next request after the previous response, thus ensuring the timing of the requests in the queue. You can put dependent requests in the same queue, which also ensures data consistency.

In the scheme, three behavior modes of queue, silent, and static are provided respectively, which are used to distinguish what kind of behavior a request needs to perform.

• queue: The request will enter the silent queue, but it will not be persisted. It will wait for the previous request to complete before sending the request. The response callback will be triggered after the response. It is generally used for data acquisition that depends on the previous request;
• silent: The request will enter the silent queue and be persisted, and then trigger the response callback immediately. In this behavior mode, onSuccess will receive virtual data, and onError will never be triggered. Use this pattern;
• static: the request will not enter the silent queue, nor will it be persisted, it will issue the request immediately, and this mode can be used when silent submission is disabled;

virtual data

In the submit-to-response mechanism, virtual data plays an important role. It means that before the server actually responds, it is used as a placeholder for the response data, and through the tracing mechanism, even if the virtual data is distributed in various locations of the application, Can be automatically replaced with the actual response data after the response. At the same time, it also plays an important role in the silent queue. It can identify the dependencies of requests in the queue, and replace the dependent data with actual data after the dependencies respond. For example, when creating a piece of data, it will return the id of this data. When the service When the terminal has not responded, the user performs a delete operation, and the id needs to be used as the delete identifier. At this time, the delete request will depend on the creation request. Before creating a request response, the virtual data will be used as an id placeholder as a parameter for deletion, and the virtual data id will be replaced after creating a request response, so that the deletion request can be completed.

Next, we will learn more about the characteristics of virtual data.