RxCommandStream inputObservable not closed on dispose

[kuhnroyal]

The input observable for RxCommandStream here is not closed when the command is disposed.

I am wondering if this should be handled by the RxCommand itself or if I should manually add some takeUntil logic, which seems like lots of boilerplate.

[escamoteur]

Good catch, I really wished we had destructors.
Have to think about it.
Do you create and dispose Commands a lot while your App is running?

[kuhnroyal]

Well, we create commands for every manager/BLoC and as you move through the app from screen to screen some managers get disposed and rebuild.

[escamoteur]

Could you live with a dispose method on commands?
In RxVMS most Managers stay alive as long as the app runs.
BTW if you are using get_it, it now supports disposal of registered objects.

[kuhnroyal]

The commands have a dispose method which I am already using.
The RxCommandStream probably needs to override/extend and close the input first.
Additionally the _commandResultSubject here should be closed before the other subjects here.
I am getting errors while disposing:

I/flutter ( 6077): ┌───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
I/flutter ( 6077): │ Bad state: Cannot add new events after calling close
I/flutter ( 6077): ├┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄
I/flutter ( 6077): │ #0   _BroadcastStreamController.add (dart:async/broadcast_stream_controller.dart:249:24)
I/flutter ( 6077): │ #1   Subject._add (package:rxdart/src/subjects/subject.dart:135:16)
I/flutter ( 6077): │ #2   Subject.add (package:rxdart/src/subjects/subject.dart:129:5)
I/flutter ( 6077): │ #3   new RxCommand.() (package:rx_command/rx_command.dart:98:62)
I/flutter ( 6077): │ #4   _rootRunUnary (dart:async/zone.dart:1132:38)
I/flutter ( 6077): │ #5   _CustomZone.runUnary (dart:async/zone.dart:1029:19)
I/flutter ( 6077): │ #6   _CustomZone.runUnaryGuarded (dart:async/zone.dart:931:7)
I/flutter ( 6077): │ #7   _BufferingStreamSubscription._sendData (dart:async/stream_impl.dart:336:11)
I/flutter ( 6077): ├┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄
I/flutter ( 6077): │ ⛔ Uncaught error
I/flutter ( 6077): └───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

Regarding manager lifecycle, I can see some managers being global but how would you go about using commands for some list view where each child needs some load command and display its individual isExecuting state.

[escamoteur]

Sorry that I didn't have time yet.
For the Listview I would only use one command in a manager that takes the item I'd as parameter

[escamoteur]

We don't need Viewmodels behind our widgets

[kuhnroyal]

But then they would have to fetch their data sequentially as one command can only track executing state for one ID parameter.

[escamoteur]

Hi,
I m back at home Thursday. I m in Bonn Germany, so perhaps its the easiest thing to have a short Skype?

[escamoteur]

@kuhnroyal Interested in a short chat on this topic?

[escamoteur]

I had now a closer look, sorry for the delay.

    var inputObservable = Observable(_observableProvider(param))
        .handleError((error) {
          thrownException = error;
        })
        .doOnData((result) => _resultsSubject.add(result))
        .map((result) {
          lastResult = result;
          return CommandResult(result, null, true);
        });

    _commandResultsSubject.addStream(inputObservable).then((_) {
      if (thrownException != null) {
        if (throwExceptions) {
          _resultsSubject.addError(thrownException);

You cannot close an observable, you only can close a StreamController or cancel a subscription.
inputObservable get's listened to inside addStream without storing the subscription anywhere so I can't cancel it from there but I don't think this is a problem.
Otherwise the Dart team would have dealt with this differently.

I also changed the sequence of the dispose method.

[escamoteur]

Fixed in V4.3.3