Closed pawsaw closed 7 years ago
Do you mean that when you define the callbacks the Dropzone way? Or are you referring to the output events?
@sconix I'm referring to the output events.
We have somehow a chain like this: ngx-dropzone-wrapper --> success/error event (EventEmiter) --> Injectible/ Service --> next on Observable subscribtion --> binding in another component
In this case the binding doesn't work.
Ok, I just wonder how common this case is. I mean that would it make sense to execute those event emits in angular zone versus just using the already existing runInsideAngular option. Maybe I need to study this bit more to know what is the best way, but until that you can always use the runInsideAngular when everything in this wrapper is run inside angular zone.
Oh, I haven't seen this option... my bad.
That's exactly what I would expect to default to true
because Angular or web development in general is somehow UI driven. So by choosing Angular I would expect each callback to be executed in the angular zone by default (likewise the ui thread in vanilla JS development).
It's very common to update the UI (In Angular: bounded properties) from the callbacks.
Thank you @sconix ... great component btw.
I understand, but its also often that people use onPush and you need to anyway call markForCheck / detectChanges when something changes in asyncronous calls.
Anyway I will think this through once I have more time and maybe change it so that the outputs are always emitted withing the angular zone. Thanks for bringing this to my attention since we are using onPush in our product and never saw this problem.
The code in the callbacks (success, error, ...) has to be wrapped inside
this.ngZone.run(() => { // my code })
in order to work properly with bindings (in any case). It would be nice to has this inside this wrapper implementation, cause this is what the user expects.