grofit
commented
3 weeks ago There is a branch on SystemsRx which uses R3, and there is a branch on EcsRx which is almost finished as there are some issues which could be our side or an issue with how we are using R3, as noted here https://github.com/Cysharp/R3/issues/223
To give some background this library came about as a framework sitting on top of Unirx and Unity to allow for ECS before unity had its own ECS paradigm.
Fast-forward almost a decade and now it's become its own pure dotnet library and has moved away from Unirx but has not fully adopted Rx due to some platform issues (I.e AOT and Unity).
The creator of Unirx has now superceded it with R3, and fixed one of the major problems we originally had with Unirx, being that we could only use it within Unity, not in a pure dotnet environment.
With R3 gaining traction and being more game dev focused than Rx, it brings an opportunity to retire our Rx agnostic layer (MicroRx) and migrate fully to R3.
Originally we were going to migrate to Rx at some point, but I wanted to get people's opinions as Unity is moving to adopt newer dotnet versions potentially removing the barriers with rx.
The only concern from me is the long term support of R3 from its creator, as Unirx had lots of issues and was not really open to community collaboration in it's twilight period.
If anyone has any thoughts on which was we should go let us know.
The main 3 options are:
This means we have a tiny micro rx implementation based on Unirx, but it's not really feature rich and is only for internal usage really.
This means we maintain less code, we potentially get more robust and feature rich rx features internally and externally. Although rx is still not entirely geared for gaming as can make large allocations in some situations.
Same as Rx but we get far more efficient performance for gaming scenarios, but it's a risk as to the longevity, docs and general support of R3.