Si subes un archivo CSV con etiquetas, la consola mostrará un error después de una carga exitosa.
Aquí hay una investigación.
El problema subyacente es esencialmente que el modal se cierra demasiado rápido con la lógica actual.
El error ocurre en uppy-upload.js.uppy-upload) ya se había destruido.
¿Cómo es posible? this._uppyInstance?.cancelAll();
Como referencia, _reset se llama desde _allUploadsComplete.
_reset() {
this._uppyInstance?.cancelAll();
this.setProperties({
uploading: false,
processing: false,
cancellable: false,
uploadProgress: 0,
filesAwaitingUpload: false,
});
En una carga exitosa, este es el orden de las funciones:uploadDone → _allUploadsComplete → [ _reset ]
this._uppyInstance.on("upload-success", (file, response) => {
if (this.usingS3Uploads) {
this.setProperties({ uploading: false, processing: true });
this._completeExternalUpload(file)
.then((completeResponse) => {
this._removeInProgressUpload(file.id);
this.appEvents.trigger(
`upload-mixin:${this.id}:upload-success`,
file.name,
completeResponse
);
this.uploadDone(
deepMerge(completeResponse, { file_name: file.name })
);
this._triggerInProgressUploadsEvent();
if (this.inProgressUploads.length === 0) {
this._allUploadsComplete();
Cuando se llama a uploadDone, el modal se cierra de inmediato.uppy-upload se destruirá al final del frame.https://github.com/discourse/discourse/blob/main/app/assets/javascripts/admin/addon/components/tags-uploader.js#L22-L26
Volviendo a this._uppyInstance?.cancelAll();. Esto activará el evento a continuación.run(), las propiedades se establecerán después de que el elemento sea destruido.
this._uppyInstance.on("file-removed", (file, reason) => {
run(() => {
// we handle the cancel-all event specifically, so no need
// to do anything here. this event is also fired when some files
// are handled by an upload handler
if (reason === "cancel-all") {
return;
}
this.appEvents.trigger(
`upload-mixin:${this.id}:upload-cancelled`,
file.id
);
});
});
Esta es una regresión menor. Introducida aquí:
uppy-upload.js
main ← dev/uppy-upload-mixin-improvements
opened 11:24PM - 05 Apr 22 UTC
This PR brings the `UppyUploadMixin` more into line with the `ComposerUppyUpload… ` mixin, by extending the `ExtendableUploader` . This also adds better tracking of and events for in progress uploads in the `UppyUploadMixin` for better UI interactions, and also opens up the use of `_useUploadPlugin` for the mixin, so anything implementing `UppyUploadMixin` can add extra uppy preprocessor plugins as needed.
This has been done as part of work on extracting uploads out of the chat composer. In future, we might be able to do the same for `ComposerUppyUpload`, getting rid of that mixin to standardise on `UppyUploadMixin` and have a separate `composer-uploads` component that lives alongside `composer-editor` like what we are doing in https://github.com/discourse/discourse-chat/pull/764
main ← issue/improve-starting-new-uploads-progress
opened 06:48AM - 28 Sep 22 UTC
This commit addresses issues around starting new uploads in a composer etc. when… one or more uploads are already processing or uploading. There were a couple of issues:
1. When all preprocessors were complete, we were not resetting `completeProcessing` to 0, which meant that `needProcessing` would never match `completeProcessing` if a new upload was started.
2. We were relying on the uppy "complete" event which is supposed to fire when all uploads are complete, but this doesn't seem to take into account new uploads that are added. Instead now we can rely on our own `inProgressUploads` tracker, and consider all uploads complete when there are no `inProgressUploads` in flight
This is difficult to test for in JS since it involves the upload lifecycle and AJAX calls, so tests are omitted.
tags-upload.js
main ← a11y-refactor-bootbox-alerts
opened 04:30PM - 20 Sep 22 UTC
Posibles soluciones funcionales:
Cerrar el modal un poco más tarde
uploadDone() {
this.refresh();
this.dialog
.alert(I18n.t("tagging.upload_successful"))
.finally(() => this.closeModal());
}
Mover la verificación fuera del bucle run().
this._uppyInstance.on("file-removed", (file, reason) => {
// manejamos el evento cancel-all específicamente, así que no hay necesidad
// de hacer nada aquí. este evento también se dispara cuando algunos archivos
// son manejados por un manejador de carga
if (reason === "cancel-all") {
return;
}
run(() => {
No estoy seguro de si hay una solución mejor. Así que, lo publico aquí.
