ObservedCollection() breaks when collection is shared between multiple clients

[wihrl]

First of all, thank you for this library, it's great!

Unfortunately, I've ran into a pretty big issue with it. When using ObservedCollection(collection), where the collection is a part of a singleton service and is thus shared between multiple clients (tabs/browsers), it only seems to update once and and further changes result in what seems to be a deadlock. It becomes impossible to update the collection any further. It's mostly likely caused by some threading issues.

[wihrl]

It seems that this happens when you subscribe to multiple different collections in a single reactive component. Subscribing to the same collection multiple times (for example to run a linq filter on it) works fine.

[wihrl]

I've put together a small demo project. Open 2 browser tabs and go to fetch data on both of them. Then click add several times on one of the tabs. The other tab only updates once and will not update until add is clicked on it.

This is a simple case, but in my real-world application, multiple users updating it not only does not update, it completely locks all functionality that uses those collections.
PhorkTest.zip

[phorks]

Thank you @wihrl for your support and feedback. I was able to reproduce the bug using your test project. I'm going to work on it.

[phorks]

@wihrl v1.1.2 is supposed to fix this issue. Just update the package reference version to "1.1.2" and you will most probably see the results you expect.

Details: This problem had nothing directly to do with observed collections. The problem was with the way the library detected an observed value/binding getting out of the render tree and therefore getting rid of its related subscriptions. The library relied on the OnAfterRender method of the ComponentBase class to update the subscriptions, assuming it will only get called after each time Blazor creates the render tree of a component, which was a wrong assumption as proved by your test project. Blazor apparently calls OnAfterRender for reasons other than the render tree being recreated. In the current version, the library uses reflection to make the reactivity manager update its subscriptions after each time the BuildRenderTree of the component is called. Using reflection to change a private readonly field of ComponentBase is not something I'm satisfied with, but until dotnet/roslyn#57239 gets fixed, I can't think of a better way of doing it.

[wihrl]

Thanks, I can confirm that the issue is fixed.

Just yesterday I was actually thinking about eventually using source generators to optimize parts of the library, I guess that will have to wait.

EDIT: It looks like it might make it into .NET 7, we'll see. dotnet/roslyn#61210

[phorks]

Yeah, the library can benefit a lot from source generators if the issue gets resolved. Regarding the pull request you linked, I don't think it's going to be merged as it does not solve the main problem.