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
Perhaps this use case is too niche to make it into the lib, but I wanted to raise the issue for discussion either way.
Using Reactor({ debug: true }); is great, but i've found that constantly evaluating state to JS can cause perf issues if state gets too big. For instance, if I have a Map with size roughly equal to 10K in state then the console debugging starts causing noticeable perf slowdown (on my system). However the debug feature is excellent, and turning it off means losing some valuable information.
Would it be reasonable to implement a second debug mode for the reactor where it would simply print actions as they are dispatched but not evaluate state to JS?
The text was updated successfully, but these errors were encountered:
Perhaps this use case is too niche to make it into the lib, but I wanted to raise the issue for discussion either way.
Using
Reactor({ debug: true });
is great, but i've found that constantly evaluating state to JS can cause perf issues if state gets too big. For instance, if I have a Map with size roughly equal to 10K in state then the console debugging starts causing noticeable perf slowdown (on my system). However the debug feature is excellent, and turning it off means losing some valuable information.Would it be reasonable to implement a second debug mode for the reactor where it would simply print actions as they are dispatched but not evaluate state to JS?
The text was updated successfully, but these errors were encountered: