The so-called frozen UI, I think the questioner means to prohibit any operation before the data is loaded. If it is offline, the data is loaded locally. If it is loaded in pages, the data loading speed should be very fast, but it must be done asynchronously. Loading is better. For the entire interface, if there are elements that need to be loaded before the data can be operated, then they are disabled. Other available element controls do not need to be disabled. Of course, as the questioner said, in fact, most of them are after the data is loaded. Only allowed. First of all, this can avoid having to confirm one by one which operations can only be performed after the data is loaded and which ones are not, which will be more cumbersome. Unified banning will save a lot of work, and loading will be faster without affecting the experience.
Of course, if the data is loading slowly, the first thing to do is not to freeze the UI. If the data cannot be loaded within 10 seconds (offline), the actual consideration should be whether there is a problem with the design, whether the data is loaded too much, or There is too much data saved locally, etc. The local database applications I have made here basically lock the interface, because the data that needs to be displayed can be loaded in one screen in less than 1 second, and there is no need to control each element.
What do you mean by frozen ui? When I use NetEase News to download offline news, it does not affect my use of other functions! Offline downloading must be performed asynchronously in the background, and threads must be started to achieve it without interfering with other activities.
Nowadays, software puts user experience first. You must not freeze the UI. If you want to download data, you can download it asynchronously in the background. There should be no impact on user operations. Are the queuing of reading and writing data that you are talking about not done well in concurrency, leading to congestion?
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
The so-called frozen UI, I think the questioner means to prohibit any operation before the data is loaded. If it is offline, the data is loaded locally. If it is loaded in pages, the data loading speed should be very fast, but it must be done asynchronously. Loading is better. For the entire interface, if there are elements that need to be loaded before the data can be operated, then they are disabled. Other available element controls do not need to be disabled. Of course, as the questioner said, in fact, most of them are after the data is loaded. Only allowed. First of all, this can avoid having to confirm one by one which operations can only be performed after the data is loaded and which ones are not, which will be more cumbersome. Unified banning will save a lot of work, and loading will be faster without affecting the experience.
Of course, if the data is loading slowly, the first thing to do is not to freeze the UI. If the data cannot be loaded within 10 seconds (offline), the actual consideration should be whether there is a problem with the design, whether the data is loaded too much, or There is too much data saved locally, etc. The local database applications I have made here basically lock the interface, because the data that needs to be displayed can be loaded in one screen in less than 1 second, and there is no need to control each element.
What do you mean by frozen ui? When I use NetEase News to download offline news, it does not affect my use of other functions! Offline downloading must be performed asynchronously in the background, and threads must be started to achieve it without interfering with other activities.
Nowadays, software puts user experience first. You must not freeze the UI. If you want to download data, you can download it asynchronously in the background. There should be no impact on user operations. Are the queuing of reading and writing data that you are talking about not done well in concurrency, leading to congestion?
If concurrency feels slow, modify the priority of the thread.