How to parameterise a container?

[opsb]

Or put another way, how to pass existing state into the container. Consider the following:

int countCapsule(CapsuleHandle _) => 0;

main() {
    int startingCount = 3;
    final container = CapsuleContainer();
    final count = container.read(countCapsule);
}

How could you configure the countCapsule to use the startingCount?

Context: I'm using Drift and for tests I want to configure it to use an in memory database whereas for production I want to use a file based database.

[busslina]

My solution would be this:

extension _ConvenienceExtension on SideEffectRegistrar {
  SideEffectRegistrar get use => this;
}

extension SideEffectExtension on SideEffectRegistrar {
  CountController myCounter([int? initialValue]) {
    final counter = use.data(initialValue ?? 0);

    return CountController(
      count: counter.value,
      increment: () => counter.value++,
      reset: () => counter.value = initialValue ?? 0,
    );
  }
}

class CountController {
  CountController({
    required this.count,
    required this.increment,
    required this.reset,
  });

  final int count;
  final void Function() increment;
  final void Function() reset;
}

final counterController = use.myCounter(3);

I use a class instead of a Record for the controller because VSCode doesn't work very well with Records, but the outcome would be the same with a Record.

[busslina]

It is supposed that initialValue would be always the same, but you can also cache just in case, like this:

CountController myCounter([int? initialValue]) {
    final cachedInitialValue = use.value(initialValue);
    final counter = use.data(cachedInitialValue ?? 0);

    return CountController(
      count: counter.value,
      increment: () => counter.value++,
      reset: () => counter.value = cachedInitialValue ?? 0,
    );
  }

[opsb]

Right, so you can parameterise at the capsule level, but doesn't this mean you need to pass that configuration to every site which uses the capsule? This means you still need a mechanism for sharing the configuration. Ideally you'd be able to specify the configuration once for the container.

[busslina]

I only use a single container. You can have a capsule that read env variables to see if you are in debug, production, testing, ... And then, you can read this capsule wherever you need to know that.

enum ExecutionMode {
  prod,
  debug,
  test1,
  test2,
}

ExecutionMode executionModeCapsule(CapsuleHandle use) {
  [...read from env...]
}

String databaseBackenConnectionUrlCapsule(CapsuleHandle use) {
  return switch(use(executionModeCapsule)) {
     [...]
  }
}

I think you can do everything with just one container

[busslina]

but doesn't this mean you need to pass that configuration to every site which uses the capsule?

Don't think so. You store/load that configuration in a capsule and you don't pass it to nowhere. You just read/use where you need it.

[opsb]

It means the capsule is dependent on global state (env vars) but it's true that is sufficient for my use case.

[opsb]

I see there's an experimental MockableContainer. I wonder if there's a more general solution though, something along the lines of:

typedef Config = (startingCount: int);

CapsuleContainer<Config>(config: (startingCount: 3));

int countCapsule(CapsuleHandler use) {
  final config = use.containerConfig<Config>();
  return config.startingCount;
};

final count = use(countCapsule);

Riverpod also has the concept of overrides which achieves the same but feels a bit off because it requires you to have a "default" implementation which you may never even use.

[busslina]

I see ReArch as much more declarative than Riverpod. And setting imperatively values on a container doesn't fit well with its philosphy.

[opsb]

It seems quite natural in the functional context, it's similar to having an initial value for a reducer.

[busslina]

In my POV if you put all your data logic on the capsules it is more secure because you will have always a trace back to see where you did it wrong. But if you set imperatively some data on a container,having multiple containers, I think it breaks the magic/purpose of ReArch.

[GregoryConrad]

@opsb for your particular case that sparked this question, you could do:

ValueWrapper<int> startingCountCapsule(CapsuleHandle use) => use.data(0);
(int, void Function()) countCapsule(CapsuleHandle use) {
  final count = use.data(use(startingCountCapsule).value);
  return (count.value, () => count.value++);
}

// test_utils.dart
CapsuleContainer useContainerWithStartingCount(int startingCount) {
  final container = CapsuleContainer();
  container.read(startingCountCapsule).value = startingCount;
  addTearDown(container.dispose);
  return container;
}

NOTE: I haven't tested the above, but I see no reason it shouldn't work.

The environment variables idea posted previously can also help for switching between dev/prod.

I see there's an experimental MockableContainer

Yup, the reason that isn't stabilized is because I'm not satisfied with its API. Dart screws up the type inference of the .mock function, so if you mess up the types (even slightly), you get no warnings at compile time but instead a really cryptic error message at runtime. That being said, you can probably use it, you might just need to make a backwards-compatibility wrapper once/if I change the existing MockableContainer API.

Riverpod also has the concept of overrides which achieves the same but feels a bit off because it requires you to have a "default" implementation which you may never even use.

Yea, those are designed only for scoping providers in the widget tree IIRC. They weren't originally designed for value mocking IIRC, but seems that a lot of people use them for that.

Btw, if I do change the MockCapsuleContainer API, I may do something like:

MockCapsuleContainerBuilder()
  .mock(someCapsule).with(123)
  .mock(anotherCapsule).with(321)
  .build();

I think that would make Dart's type inference happy, but that API isn't as clean and small.