Description
When editing forms with large submission attachments form rendering is blocked until the attachments are downloaded. It would be better to lazily load the attachments so users can begin filling in the form while the attachments load.
The code has some todos which calls out the need for this addition
|
/** |
|
* @todo Everything about this is incredibly naive! We should almost certainly |
|
* do _at least_ the following: |
|
* |
|
* - Limit how many attachments we attempt to resolve concurrently |
|
* - Lazy resolution of large attachments (i.e. probably streaming, maybe range |
|
* requests, ?) |
|
* |
|
* @todo Once lazy resolution is a thing, we will **also** need a clear path |
|
* from there to eager resolution (i.e. for offline caching: it doesn't make |
|
* sense to cache a stream in progress, as it won't load the resource once the |
|
* user actually is offline/lacks network access). This may be something we can |
|
* evolve gradually! |
|
*/ |
Prior art: Form attachments already lazily load and have an animation style that should be reused for submission attachments.
Description
When editing forms with large submission attachments form rendering is blocked until the attachments are downloaded. It would be better to lazily load the attachments so users can begin filling in the form while the attachments load.
The code has some todos which calls out the need for this addition
web-forms/packages/xforms-engine/src/instance/input/InstanceAttachmentMap.ts
Lines 47 to 60 in e18c44b
Prior art: Form attachments already lazily load and have an animation style that should be reused for submission attachments.