Some checks appear to be failing. Can you take a look at those?

Done!
Thank you for making me realise that the failures were due my mistake. I was thinking they had been caused by some infrastructure issues, not knowing such a tiny error could affect that much.

I don't think we should add this to the framework. It's kinda confusing. The first time the widget is build, it just builds with whatever the value is completely ignoring the filter. Even if we would apply the filter to the initial value - what would we build with if the value is filtered out.

If you need this behavior, I would suggest creating a FliteringValueListenable, which takes in a ValueListenable and only notifies its own listeners if it passes the filter.

@goderbauer
The behaviour of the filter not being applied to the initial value is described in the document to be less confusing. If it is insufficient, I think just changing the parameter name from filter to rebuildFilter will remove the confusion completely and resolve the concern. What do you think about it?

If a ValueListenableBuilder has to be used with another widget like a FilteringValueListenable for filtering, it adds the new issue of discoverability where developers need a chance to learn the fact that the combination is possible, while the rebuildFilter seems more obvious.

I only have a vague image of the FilteringValueLitenable you mentioned, but assuming that it is something like below, it looks like it's very likely to add even more issues: verbosity, worse readability, deeper indentation, etc.

FilteringValueListenable(
  valueListenable: listenable,
  filter: (oldValue, newValue) { ... },
  notifier: (context, newListenable) {
    return ValueListenableBuilder(
      valueListenable: newListenable,
      builder: (context, value, _) {
        ...
      },
    );
  },
  placeholder: const SizedBox.shrink(),  // a widget used while no value is notified yet
)

Hey @goderbauer, can you just have a look at my idea above and give your opinion please? Renaming the parameter eliminates the confusion you mentioned, and so I believe there's nothing preventing the feature from being merged any more.