Closed drzraf closed 2 years ago
Anyway, approved to merge 👍
Similar logic for using the asyncAddFiles should be applied in assignDrop/onDrop also - otherwise the files selected with different methods might end up being processed in different ways.
Thank you for noticing. Added a new commit regarding this aspect but I'm not sure adding some readonly protection logic to the <div>
/dropzone would be worth it.
From my experience, an async init file function would typically take less than a second (and unless its used for remote interaction like fetching a remote public key according to file type?) I don't quite see the need for it. (Such a user would easily redefine his dropzone anyway)
Follow-up of c8dee19bc56 (#329)
When calling
*addFile()
,FlowChunk
are created which, among other things, imply testing the File size in order to compute theendByte
(and the number of chunks)If an "initFileFn" is declared AND this function's prototype shows asynchronicity, then it's sane to assume we need to use
asyncAddFile()
(which will bootstrap slightly differently).Awaiting for such an
initFileFn
can, for example, allow the chunk size to be computed differently regarding the stream initialization. An example is a stream-crypto layer that could add an overhead affectingFlowFile.size
.