Original link :dsx2016.com/?p=991 wechat official account: Big Brother 2016

scenario

The front end of wechat public account H5 is compressed before uploading photos

An exception occurred on ios 10.0 due to compatibility issues with Canvas to BLOb streams

The submit button has been processing the submission, neither returning an error message, nor indicating completion, stuck there and not responding

The difficulties in

If the local test is good, can be targeted debugging and compatibility

But the above problems are based on the large user base exposed online

At the same time, because it involves sensitive information and the enthusiasm of user feedback, it is difficult to troubleshoot problems, and only the model and other information can be learned

Also because of the large volume of the file stream involved, the feedback time is relatively long, affected by the network speed and so on, the user may wait until half, thinking that there is a problem

The operation did not give feedback to the timeout toast prompt of 60 seconds, and the background said that there was no error log and no screen shots of users, so key information could not be obtained

However, because the front end is the presentation layer, it is a serious phenomenon that the image cannot be uploaded. In this scenario, it is not completely certain whether the user actually initiates the HTTP request

To improve the

The bloB stream, which was originally a canvas only stream, could not submit images due to compatibility issues

After fault tolerance, if an uncompressed BLOB stream is detected when you click Submit, upload the source file of the selected photo (uncompressed but better than failed upload)

But this alone is still not a good solution to the problem, because the upload time is too long, which is itself a problem

What if it turns out that the front end has already made an HTTP request, and it gives the user enough obvious feedback before it times out?

It’s also a good time to check information for yourself, such as true network speeds and error feedback.

That is to set up the progress bar, it is best to have a numerical progress bar, so that the speed of the Internet, upload the progress of a glance.

thinking

Fault-tolerant processing

When using the plug-in of HTMLCanvas, there is no catch tolerance on the document, so I subconsciously ignored the wrong scene.

Later, when handling an exception, it listens for the existence of the file stream file or BLOB at the end of the file and submits the corresponding data if it does.

Try catch is also used, because there is no buried point to report, so we can only consider the wrong scenario as much as possible

The file progress

The intention was to see if axios provided a method that could locate HTTP requests

Then you see that Axios itself has a progress value method for file uploads and downloads. If progress has a value, it means that it is in the request

Going back to prototyping, it’s a good idea to have a current progress indication, either a numerical value or a progress bar, where files are uploaded and downloaded

onUploadProgress: function (progressEvent) {
    // Do whatever you want with the native progress event
}
​
    // `onDownloadProgress` allows handling of progress events for downloads
    // browser only
onDownloadProgress: function (progressEvent) {
    // Do whatever you want with the native progress event
}
Copy the code