When will the dispose method of a Provider get called

[JohnCido]

Considering this example:

import 'dart:developer';

import 'package:disco/disco.dart';
import 'package:flutter/material.dart';
import 'package:flutter_solidart/flutter_solidart.dart';

@immutable
class ViewModel {
  ViewModel();

  static final provider = Provider((_) => ViewModel());

  final counter = Signal<int>(0);
}

void main() {
  runApp(
    MaterialApp(
      localizationsDelegates: [DefaultMaterialLocalizations.delegate],
      home: ProviderScope(
        providers: [ViewModel.provider],
        child: Scaffold(
          body: Center(
            child: Builder(
              builder: (context) {
                return FilledButton(
                  onPressed: () => showBottomSheet(
                    context: context,
                    builder: (_) => Modal(mainContext: context),
                  ),
                  child: Text('Test'),
                );
              },
            ),
          ),
        ),
      ),
    ),
  );
}

class Modal extends StatelessWidget {
  const Modal({super.key, required BuildContext mainContext})
    : _mainContext = mainContext;

  final BuildContext _mainContext;

  @override
  Widget build(BuildContext context) {
    return ProviderScopePortal(
      mainContext: _mainContext,
      child: SignalBuilder(
        builder: (innerContext, _) {
          final vm = ViewModel.provider.of(innerContext);

          return Column(children: [Text(vm.counter().toString()), Counter()]);
        },
      ),
    );
  }
}

@immutable
class CounterViewModel {
  CounterViewModel({required this.count});

  static final provider = Provider.withArgument(
    (_, int count) => CounterViewModel(count: count),
    dispose: (viewModel) => viewModel.dispose(),
  );

  final int count;

  final counter = Signal<int>(0);

  void dispose() {
    log('CounterViewModel disposed');
  }
}

class Counter extends StatelessWidget {
  const Counter({super.key});

  @override
  Widget build(BuildContext context) {
    return ProviderScope(
      providers: [CounterViewModel.provider(5)],
      child: SignalBuilder(
        builder: (innerContext, _) {
          final vm = CounterViewModel.provider.of(innerContext);

          return Column(
            children: [
              Text(vm.counter().toString()),
              FilledButton(
                onPressed: () => vm.counter.updateValue((value) => value + 1),
                child: const Text('Increment'),
              ),
            ],
          );
        },
      ),
    );
  }
}

The 'CounterViewModel disposed' is never printed to the console when the modal close.

[JohnCido]

I have similar use cases where a route injects a view model provider. When user pop the page, the dispose was never called too.

[nank1ro]

The providers should dispose when the ProviderScope (who provided them) is removed from the widget tree, so it could be another bug.
I'll take a look in the next days and I'll let you know.
Or maybe @manuel-plavsic can take a look before me

[nank1ro]

I confirm it's a bug

void dispose() {
    createdProviderValues.forEach((key, value) {
      allProvidersInScope[key]?._safeDisposeValue(value);
    });
    ..

the key is not valid for an arg provider, so arg providers are not disposed at all

[manuel-plavsic]

I guess that a line such as allArgProvidersInScope[key]?._safeDisposeValue(value); is missing there. I don't have my computer with me right now, but I can create a new PR with the fix and some tests tomorrow. Or since this should be a simple fix you can also do it now @nank1ro

[nank1ro]

I'm outside too, it's not so easy because the key is of type Provider but that map needs an ArgProvider, so it needs a bit of reasoning

[manuel-plavsic]

By the way, @JohnCido thanks so much for reporting this and the other two bugs. Please, keep reporting if you find more (in theory this package is not so vast, so there should not be many more, but you never know...). Also, let us know if you notice something important that is lacking in this package :)

[JohnCido]

By the way, @JohnCido thanks so much for reporting this and the other two bugs. Please, keep reporting if you find more (in theory this package is not so vast, so there should not be many more, but you never know...). Also, let us know if you notice something important that is lacking in this package :)

Sure thing! And thank you guys so much for very fast response. I'm trying to use disco and solidart in a new production project of my employer. The overall experience is new, but since I'm very familiar with SolidJS, these two packages really works well for me!

[manuel-plavsic]

@JohnCido That is great to hear. I used Flutter in my previous job and it was awesome. Right now I am doing something different professionally, and I am also studying at the same time. So, I haven't had enough time to explore more with disco, sadly. However, I am currently using SolidJS at University, and I really like it. @nank1ro is employing SolidDart and Disco in production ;)

I was unsatisfied with the state management solutions in the Flutter ecosystem, that is why I started contributing to @nank1ro's Solidart. We are trying our best to keep SolidDart and Disco simple, yet powerful. No bloat, no code gen, offering only one way (arguably good) to do something, yet still thinking of all user needs. Also, Disco's set of trade-offs is very well thought out. And we will try to respond quickly to users' questions and reports.

[nank1ro]

You can continue to track the progress here #25