useSignal, useComputed like Preact

[rodydavis]

Just a thought I had, but it could be possible to define a watch and signal in the build method:

import 'package:flutter/material.dart';

import '../../signals_flutter.dart';

final _signals = <WeakReference<Element>, List<Signal>>{};

Signal<T> useSignal<T>(
  BuildContext context,
  T value, {
  String? debugLabel,
  SignalEquality<T>? equality,
}) {
  assert(context is Element);
  final current = _signals.entries.firstWhere(
    (e) => e.key.target == context,
    orElse: () => MapEntry(WeakReference(context as Element), []),
  );
  final result = current.value.firstWhere(
    (e) => e is Signal<T>,
    orElse: () {
      final s = signal<T>(
        value,
        debugLabel: debugLabel,
        equality: equality,
      );
      s.subscribe((value) {
        if (current.key.target != null && current.key.target!.mounted) {
          current.key.target!.markNeedsBuild();
        }
      });
      s.onDispose(() {
        current.value.remove(s);
      });
      current.value.add(s);
      return s;
    },
  ) as Signal<T>;
  _signals[current.key] = current.value;
  return result;
}

Same for computed:

import 'package:flutter/material.dart';

import '../../signals_flutter.dart';

final _signals = <WeakReference<Element>, List<Computed>>{};

Computed<T> useComputed<T>(
  BuildContext context,
  T Function() value, {
  String? debugLabel,
  SignalEquality<T>? equality,
}) {
  assert(context is Element);
  final current = _signals.entries.firstWhere(
    (e) => e.key.target == context,
    orElse: () => MapEntry(WeakReference(context as Element), []),
  );
  final result = current.value.firstWhere(
    (e) => e is Computed<T>,
    orElse: () {
      final s = computed<T>(
        value,
        debugLabel: debugLabel,
        equality: equality,
      );
      s.subscribe((value) {
        if (current.key.target != null && current.key.target!.mounted) {
          current.key.target!.markNeedsBuild();
        }
      });
      s.onDispose(() {
        current.value.remove(s);
      });
      current.value.add(s);
      return s;
    },
  ) as Computed<T>;
  _signals[current.key] = current.value;
  return result;
}

Usage could be the following:

class MyWidget extends ... {
   ...
   Widget build(BuildContext context) {
       final count = useSignal(context, 0);
       final isEven = useComputed(context, () => count().isEven);
       ...
       return Row(
         children: [
             Button(child: Text('+'), onPressed: () => count.value++),
             Text('$count even=$isEven'),
             Button(child: Text('-'), onPressed: () => count.value--),
         ],
       );
   }
}

What is nice about this is there is no watch widget and the signals are directly tied to the Element.

The only disadvantage is only 1 type of signal can be in the build method without conflicts. This could be fixed with a label possibly.

Widget build(BuildContext context) {
   final a = signal<String>('a');
   final b = signal<String>('b'); // gets ignored since it already exists and returns the a signal
   ...
}

[jinyus]

What's the difference?

class MyWidget extends ... {
   final count = signal(0);
   final isEven = computed(() => count().isEven);

   ...
   Widget build(BuildContext context) {
       return Row(
         children: [
             Button(child: Text('+'), onPressed: () => count.value++),
             Text('$count even=$isEven'),
             Button(child: Text('-'), onPressed: () => count.value--),
         ],
       );
   }
}

The gc should clean up all local fields when the widget gets garbage collected.

[jinyus]

Right, I forgot to add count.watch(context).

[rodydavis]

What are your thoughts on this API?

[jinyus]

I personally don't like having too many ways of doing the same thing, and the 1 signal per type flaw will necessitate supplying an id, which makes it less ergonomic. I would stick with local signal + .watch or Watch.

[rodydavis]

Yeah that is what I am leaning towards too. Might include it as an extra import but not in default import

[drantunes]

Maybe, an idea would be to create an automatic ID based on the object's hash (but I don't see such a simple way to do this.). I've tried this implementation a few times and, almost always, I find a solution where the signal should be "global" and useSignal should only be used to subscribe / listen and enable rebuilding. But in this case, signal.watch would already meet this need.

[JoDeveloper]

would it autoDispose the signal ?

[rodydavis]

Not really, but it attaches the signals to the garbage collector to the element.

Looking into the finalizer api but not always consistent on garbage collection