Big thanks to all the community who help out with SystemsRx/EcsRx.
Great stuff buddy, all you need to do is add it here in a PR with a link to the plugin (with optional profile link) and a blurb about what the plugin is/does, or if you don't fancy that just raise an issue detailing the above and we can add it for you.
A SystemsRx Plugin that provides a base notion for implementing a plugin to control when a system is started and stopped with ease.
A simple web based auto battler made using SystemRx, OpenRpg and Blazor. It was mainly done as a live stream but the repo can be used to see how to run SystemsRx/EcsRx in the browser.
7.0 Splits IDependencyContainer into IDependencyRegistry and IDependencyResolver as well as removing some niche DI methods, see DI docs for more info.
Both rx.net and unirx have problems on different engines/platforms so SystemsRx core cannot depend on either, so it depends on this TINY rx implementation so it can work with either.
So in .net currently there are 2 main rx implementations:
System.Reactive (aka dotnet reactive or rx.net)
UniRx (a unity specific rx implementation)
Herein lies the problem, so this library was first created as a unity project, then it was split off into a generic .net framework agnostic of engines and frameworks, with a unity layer (and other engine specific layers) which would sit on top of this.
Unity and a lot of other engines/frameworks (Monogame, Godot, Xenko etc) support modern .net syntax and libraries, and they allow you to release to different platforms, and this is where the problem rears its head.
As certain platforms don't support JIT and require AOT compilation, which the normal System.Reactive framework doesn't support. There were however some discussions on the work needed to allow it to work in AOT scenarios, but no solid work seems to have resulted from that yet.
This then means that if you want to target iOS for example you cannot use System.Reactive out the box, so for unity its not really possible to use it due to IL2CPP and certain platform constraints.
If you are in Unity then yes, UniRx will work in all of those scenarios (with some tweaks). HOWEVER, UniRx is not really maintained that well these days as the maintainer drops in every now and again and then vanishes and no one else has been able to assist in maintaining the project.
This also means that if you are not using Unity you cannot really use UniRx. While there is a nuget package for it, it has not been updated in years and given the lack of communication on the main releases of unirx to the asset store and github I would not hold my breath for a new version of that any time soon (Believe me, I wont stop pestering the maintainer of it).
Kinda, so SystemsRx originally made use of fancy rx linq stuff and some other fancy rx bits, but we couldn't have a dependency on rx.net as then the unity layer would fail, and I couldn't have a dependency on UniRx as its nuget package is wildly outdated and the other part cannot be used outside of unity.
So because of these problems we decided to make a TINY rx implementation, which is pretty much a rip off and simplification of parts of UniRx. This allows EcsRx to internally be able to make use of basic rx paradigms like Subject and CompositeDisposable (and a few other bits) but has very little else, i.e no Linq stuff, no scheduler, no async stuffs.
This makes it a very small library and very specific in its usecase, so as EcsRx uses IObservable as its contract which is a part of .net it means the stuff inside MicroRx should be compatible with unity and/or any other framework/engine, and place nicely with other more feature rich rx implementations, so you get to decide if you want to use rx.net or unirx (or any other rx implementation) in your consuming project, while the EcsRx core is blissfully unaware of what you are using.
We don't really want to have a micro rx implementation, we would much rather depend on a better, more maintained version of rx, but until rx.net works in unity on all platforms, or UniRx starts releasing maintained nuget packages which can be consumed on any platform I am going to need to rely upon this to polyfill those needs and stay agnostic of implementation.
Really you dont need to worry about this and dont even really need to care about MicroRx's existence, although I would say DONT USE IT FOR ANYTHING MAJOR, its only really there to polyfill the internal EcsRx libs.