4.4.0

[rodydavis]

What's Changed

• FIX: Reading a computed signal's value triggers SignalsObserver.onComputedUpdated #156 by @rydmike in FIX: https://github.com/rodydavis/signals.dart/issues/156 #157
• Example crud with dio by @hifiaz in Example crud with dio #172
• Fix issue with AsyncSignal reset method by @jinyus in Fix issue with AsyncSignal reset method #178
• VS- Code Extension for Signal-Flutter by @deepraj02 in VS- Code Extension for Signal-Flutter #170

New Contributors

• @hifiaz made their first contribution in Example crud with dio #172
• @deepraj02 made their first contribution in VS- Code Extension for Signal-Flutter #170

Full Changelog: v4.1.0...v4.4.0

---

This discussion was created from the release 4.4.0.

[rodydavis]

Code coverage is for signals_core is now at: 60.2%
Code coverage is for signals_flutter is now at: 41.7%

Will be working on adding more tests to cover as much of the API as possible.

[rydmike]

Thanks Rody!

Nice release and nice progress.

Also super thanks for this fix in 4.4.0:

• "fix equality not being passed in for some signals"

Not sure if that was what was causing the issue I was seeing, but it sounds like the potential cause for it.

I was suddenly after a "newer" Signals releases in my debug logs seeing a crazy amount of rebuilds of pretty much "everything". Well, especially things that used computed signals that should not have been changing. For example, things like simple computed "prop" filters from a common data class Signal. The computed Signals accessed one prop each. Say the class MyFlags had 3 bools a, b, c. Changing a changes overall MyFlags data class Signal, as it should, and computed signal from a, but not computed signals from b and c.

I tested and found it was all fine up and until 2.1.10. I did not see the issue with it or before. However, after 3.0.0 release suddenly b and c in above use case example where triggered as changes as well, when only a had been changed. Causing rebuild of widgets that used b or c in Watch or .watch(context), something I was explicitly trying to avoid with the described computed "filter" setup.

Happy to say, that as far as I can see in version 4.4.0, it is back to working as it did until 2.1.10 🥳

I had planned to report the issue and write a test for it, but it looks like I don't have to anymore! Awesome, thx!

Also awesome and yes please, more tests to hopefully catch and avoid regressions like this will be needed and much appreciated! BTW, Copilot is getting pretty good at writing tests, especially if you describe what you want 😉