ListSignal read accessors (length, [], elementAt, iterator) skip tracking — inconsistent with SetSignal / MapSignal

[tlvenn]

Summary

ListSignal's read accessors (length, operator[], elementAt, iterator, etc.) read the underlying _value field directly without going through the tracked value getter. This means reading them inside a reactive scope (e.g. SignalBuilder.builder, Effect) does not register a subscription — so the reactive scope never re-runs when the list mutates.

SetSignal and MapSignal do not have this bug — every read accessor calls value; first to trigger tracking. The asymmetry is the smoking gun.

Affected version

solidart 2.8.3 (still present on main at the time of writing).

Reproduction

import 'package:solidart/solidart.dart';

void main() {
  final list = ListSignal<int>([1, 2, 3]);

  Effect((_) {
    // Reading via `.length` is meant to subscribe. It does not.
    print('list.length = ${list.length}');
  });

  list.add(4); // expected: effect re-runs and prints 4. actual: nothing.
}

Same applies to list[0], list.elementAt(0), for (final x in list) …, list.isEmpty (via ListMixin, which calls the un-tracked length getter), list.map(...).reduce(...), etc.

Workaround: read list.value.length / list.value[i] instead.

Root cause

From packages/solidart/lib/src/core/collections/list.dart:

@override
int get length {
  return _value.length;                  // bypasses tracking
}

@override
E elementAt(int index) {
  return _value.elementAt(index);        // bypasses tracking
}

@override
E operator [](int index) {
  return _value[index];                  // bypasses tracking
}

@override
Iterator<E> get iterator {
  return _value.iterator;                // bypasses tracking
}

Compare with SetSignal (set.dart):

@override
int get length {
  value;                                  // ← triggers tracking
  return _value.length;
}

@override
E elementAt(int index) {
  value;                                  // ← triggers tracking
  return _value.elementAt(index);
}

And MapSignal (map.dart):

@override
int get length {
  value;                                  // ← triggers tracking
  return _value.length;
}

@override
bool get isEmpty {
  value;
  return _value.isEmpty;
}

Impact

Beyond the obvious "loop over a ListSignal" case, this silently defeats reactivity in any code that goes through Dart's ListMixin defaults — .isEmpty, .isNotEmpty, .first, .last, .contains, .fold, .map(...).reduce(...) all funnel through length / elementAt and therefore also skip tracking. Code that looks reactive (and matches the patterns in the README/examples) silently doesn't re-run.

Suggested fix

Add a value; read at the top of every read-side accessor in ListSignal, matching SetSignal/MapSignal. Same for any other read methods that currently go straight to _value (+, sublist, cast, …).

Happy to send a PR if it'd help.

[coderabbitai]

🔗 Related PRs

#139 - fix signal builder inherited widget [merged]
#143 - refactor signal builder [merged]
#160 - fix: resource resolution [merged]
#171 - fix: prevent LateInitializationError when accessing untracked val [merged]
#172 - Computed.untrackedValue is not up to date [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[tlvenn]

Correction — issue is invalid, closing

I was wrong. Re-reading read_signal.dart:133-151:

T get _value {
  if (_disposed) {
    return untracked(...);
  }
  _reportObserved();                                                         // ← subscribes
  final value = reactiveSystem.getSignalValue(_internalSignal).unwrap();
  ...
  return value;
}

_value is not a field — it's a tracked getter that calls _reportObserved(). So ListSignal.length (which does return _value.length;) DOES subscribe — the read goes through the tracking path. Same for [], elementAt, iterator, first, last, sublist, toList, etc.

The "asymmetry" I cited between ListSignal (no value;) and SetSignal/MapSignal (with value;) isn't a bug — value itself returns _value, so calling value; first is just a redundant explicit subscribe; both forms produce the same subscription via _reportObserved.

Confirmed empirically by writing the regression test the issue describes and running it against unpatched ListSignal:

test('length read subscribes', () {
  final list = ListSignal([1, 2]);
  final cb = MockCallbackFunction();
  Effect(() { list.length; cb(); });
  list.add(3);
  verify(cb()).called(2);   // passes — effect did re-run
});

The test passes on main as-is. Apologies for the noise. Closing.

(I'm happy to send a separate PR with the new regression tests if you'd find that valuable as future safety net against accidental regressions — they cover the full surface of length/[]/elementAt/iterator/isEmpty/first/last/fold/map.reduce/firstWhere etc. for List, Set, and Map. Let me know.)