有關單頁應用程式的體驗問題

---恢復內容開始---

##What is a single-page application
The so-called single-page application refers to the integration of multiple functions on one page, or even the entire system has only one page (one html), and all business functions are its Submodules are connected to the main interface in a specific way.

##Why there are single-page applications
We know that part of the reason for the emergence of ajax technology is to allow users who visit the web page to view data changes on the page without refreshing the page. We can say that ajax improves the experience.

With the development of the Internet, the services carried by the browser have become more and more complex. The web front-end is no longer a simple page, a gadget that can be partially refreshed with Ajax. Applications with dozens of sub-pages can be found everywhere on the market. These subpages share many shared resources (static and dynamic), and it takes a lot of time to load them. If you want to avoid loading these resources repeatedly, there is an obvious way - put them into one HTML.

So it is a further sublimation of ajax technology, taking the refresh-free mechanism of ajax to the extreme, so it can create a smooth user experience comparable to desktop programs.

##Troubles caused by single-page applications
We know that putting a dozen or twenty sub-page programs in an HTML cannot be done by cut+paste. The result of putting together originally unrelated programs is the mass-energy equation of the program world. Errors = (More Code)^2

##The experience of single-page applications
Getting back to the subject, how to enhance the single-page application as much as possible What is the operating experience of page application?

Then let’s first take a look at what affects the experience for users

1. The initial loading speed of the page
2. The interactive response
3. The correctness of page data (especially under abnormal network conditions)

--
In fact, many articles have talked about the first two points more. Here I will try my best to briefly mention them and focus on the third point.


#Initial page loading speed
-On-demand loading of static resources (under the premise of good modularization, use module bundler tools such as webpack and systemjs)
-On-demand loading of dynamic resources Need to obtain (needs a good architecture of the front-end data layer)
- Server-side rendering (during the page loading process, the front-end "obtains" data and "generates" the page, completes it on the server side. Not applicable to the first screen Overly complex applications)


#Interactive response
- Speed: data returned from the backend request, front-end cache, and subsequent synchronization. Avoid repeated requests for the same data.
- Exception handling: Nowadays, mobile office is popular. How to give users a good wait or prompt on the UI when the network condition is not good, we should not underestimate the correctness of the page data



This is what I want to talk about. We have encountered many problems in practice and have tried some solutions.

I personally feel that if you want to do this well, just these words are needed: **"Good cache management"**, the cache here refers to the front-end cache model.

Don’t look at just these few words, it’s quite difficult to do. Why?


# Let’s talk about the sources of memory first, there are the following types:

- Browser cache (indexDB, localStorage and the like)
- http request
- webSocket push

Different sources affect the same data, which requires good abstraction to allow the business layer to shield the perception of the data source. Existing widely used libraries to solve this problem include RxJs, CycleJS, etc., and there were also some earlier People came up with the concept of MVI because of this.


#Let’s talk about memory changes

There is no need to go into details about changes in normal states. Here we only talk about a few types of abnormal states.


##http request failed

There is a word that needs to be mentioned here, called **"operation compensation"**

What is operation compensation?

Logically speaking, when we operate on the interface and create a task, the new task should not be displayed immediately, but should wait until the server confirms success before adding it to the interface. . But it is very likely that our network is not good and users will have to wait a long time for this step. From the perspective of user experience, this is not good, so we can put the interface up first, and then backfill some unique identifiers and other things into the memory data after the message of successful creation comes back. ######Single-step operation compensation is not too difficult. If there are multiple steps, it will be very troublesome. For example, in an extreme case, the user adds a new task and the server has not returned yet. , he immediately creates a subtask under this task, but the subtask does not have the ID of the parent task at this time. If you want to compensate for this step, it will be more troublesome. It is even said that after performing several consecutive operations, it is found that the previous operation failed, and the subsequent processing will be very complicated. ######Our products also encounter this problem. Our approach is - **"compromise"**, for important data, make single-step compensation or two-step compensation. If the dependency relationship of the front-end model is complex and the write operation of the superior model fails, or there are too many steps of compensation, the user will be notified in advance and the user's interaction entrance will be locked on the UI to avoid subsequent write operations. ######If you continue to do it here, you can still do it. The idea is similar to the offline application. The results of the operation are recorded locally on the client. Wait until the network is normal, and then synchronize the data with the background.



##Disconnection and reconnection

Network jitter, network switching, computer hibernation and restarting, etc., lead to us needing to face more complex network conditions, then When the user connects to the Internet again, the application needs to reconnect.

At this time, an ideal single-page application will synchronize back the final results of all previous events, that is, the latest status, when reconnecting.

Our application has collaborative business. Users in the same enterprise share the same model and synchronize it through webSocket to ensure the immediacy and correctness of the model. So this is also a big challenge for us. Our solution is to resend webSocket.


##Hot update

As mentioned earlier, users may have our application open for a long time and then not refresh it in the middle. Under normal circumstances, all business changes should be pushed over, and the status fed back by the interface is always the latest and in line with the current situation. But we need to consider another issue, what about system upgrades?

Of course we can push a notification: This system has been upgraded, please click refresh. But can it be done better? This is possible. To achieve this goal, we must use hot update to maximize the modularization and change management of the code. Each updated code module is also pushed over and applied as a patch to the current on the system. This mechanism requires high standards of the development team.


##Finally
I once heard a saying, how to judge the technical level of a single-page product?
It can be used continuously for several days without being closed, and there is no need to refresh the page. The application can still be used normally, correctly and smoothly.

I believe students who have done single-page applications will understand the meaning of this.

##Summary

I have said a lot, let me summarize. We have mentioned some problems and ways to improve the single-page application experience. If implemented, users will definitely be very happy, but the gap between ideal and reality needs to be weighed calmly. What we do is software engineering, so we must give up aesthetics appropriately and invest our limited human energy into the key points. ######---End of recovery content---###

以上是有關單頁應用程式的體驗問題的詳細內容。更多資訊請關注PHP中文網其他相關文章！