You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have some general thoughts around this library, but didn't want to start creating issues as the ideas haven't materialized in my mind yet.
Containers
In order to make the library easier to get started with, it's worth considering having sane defaults as "containers", depending on the environment. For example, there can be a "UnityContainer", which provides sane defaults and dependencies for Unity projects.
Async Flow
The current approach recommended by the library for asynchronous flows is using Timers and Callbacks on general .Net projects, and coroutines for Unity projects. This is a very old and clunky solution, and not very approachable either for new users.
People seem to like using UniTask project for async / await. UniRx is another possibility that would provide a nice Reactive API that fits our networking solution quite nicely. It would be worth exploring and seeing how to provide users with better options while still not deciding for them what approach is best.
Benchmarking
It's very elusive trying to decide whether to use a struct or class, penalty of immutability, enum.ToString() vs nameof ... etc. Instead of trying to decide based on opinions, it's better to measure!
Benchmarking JSON parsing, memory allocations, and various aspects of the library should prove valuable for such a library that is built to integrate with a high-performance web framework.
Feature Flags
Instead of having users adding/removing files based on their needs, it's worth exploring fencing various optional features behind feature flag macros, such as PHOENIX_SHARP_DISABLE_XYZ. This is similar to how BestHTTP library manages its optional features.
Publishing a Package
We can probably make releases with pre-built unitypackage releases. Also worth looking into publishing on Open UPM.
Unity CI / CD
Might be worth looking into Game CI to test the library on various Unity versions. The main concern is API compatibility, rather than trying to write extensive tests.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
I have some general thoughts around this library, but didn't want to start creating issues as the ideas haven't materialized in my mind yet.
Containers
In order to make the library easier to get started with, it's worth considering having sane defaults as "containers", depending on the environment. For example, there can be a "UnityContainer", which provides sane defaults and dependencies for Unity projects.
Async Flow
The current approach recommended by the library for asynchronous flows is using Timers and Callbacks on general .Net projects, and coroutines for Unity projects. This is a very old and clunky solution, and not very approachable either for new users.
People seem to like using UniTask project for async / await. UniRx is another possibility that would provide a nice Reactive API that fits our networking solution quite nicely. It would be worth exploring and seeing how to provide users with better options while still not deciding for them what approach is best.
Benchmarking
It's very elusive trying to decide whether to use a
struct
orclass
, penalty of immutability,enum.ToString()
vsnameof
... etc. Instead of trying to decide based on opinions, it's better to measure!Benchmarking JSON parsing, memory allocations, and various aspects of the library should prove valuable for such a library that is built to integrate with a high-performance web framework.
Feature Flags
Instead of having users adding/removing files based on their needs, it's worth exploring fencing various optional features behind feature flag macros, such as
PHOENIX_SHARP_DISABLE_XYZ
. This is similar to how BestHTTP library manages its optional features.Publishing a Package
We can probably make releases with pre-built
unitypackage
releases. Also worth looking into publishing on Open UPM.Unity CI / CD
Might be worth looking into Game CI to test the library on various Unity versions. The main concern is API compatibility, rather than trying to write extensive tests.
Beta Was this translation helpful? Give feedback.
All reactions