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
We're using webext-redux in the Chrome extension for mabl. It's been very helpful. We just upgraded to the latest version. The serializers and deep diff do a lot to mitigate performance issues due to a large redux store.
First off, I was planning to make some contributions. Is a PR from a fork the recommended path? We'll probably build off our fork until and if our changes are accepted. How do you feel about adding other modules as long as the licenses are compatible?
Also, I wanted to get your opinion on some enhancements we would propose, in order of importance for us:
Enhance deep diff to handle arrays. This would probably be done in two stages, one to handle them based on === and another to go deeper.
Add includes and/or excludes options to wrapStore to provide easy filtering of reducers for performance. I've done this with custom serializers so far since we need a lot less redux state in our content pages than in our UI. I also double wrapped the store with different port names so I can differentiate content from UI traffic.
debug flags to emit payload and diff state for diagnosis. I've written (de)serialization and diff wrappers to help with this so far, which could also be a way to satisfy the need without flags and in a "pay for what you use" approach. Would you have an implementation preference?
Enhance the documentation around serializers and differs and their respective payloads, outputs, and expectations. Part of the debug stuff I did was to help reverse-engineer these contracts.
Anyway, I wanted to reach out to make sure I take an approach that you're comfortable with.
The text was updated successfully, but these errors were encountered:
Hey @srvance ! Thrilled to hear that this package has been helpful for you over at Mabl. I'd be happy to throw your logo and link on the package Readme if you'd like.
Regarding contributions:
Fork with PR is great.
Adding additional modules is acceptable although we definitely try to keep them to a minimum. If the module is small enough, we may consider just moving the desired function directly in to reduce potential of vulnerabilities.
Regarding your enhancements:
Sounds excellent. I see you added a PR for this already so I'll take this specific conversation there. Thank you!
We're using webext-redux in the Chrome extension for mabl. It's been very helpful. We just upgraded to the latest version. The serializers and deep diff do a lot to mitigate performance issues due to a large redux store.
First off, I was planning to make some contributions. Is a PR from a fork the recommended path? We'll probably build off our fork until and if our changes are accepted. How do you feel about adding other modules as long as the licenses are compatible?
Also, I wanted to get your opinion on some enhancements we would propose, in order of importance for us:
===
and another to go deeper.includes
and/orexcludes
options towrapStore
to provide easy filtering of reducers for performance. I've done this with custom serializers so far since we need a lot less redux state in our content pages than in our UI. I also double wrapped the store with different port names so I can differentiate content from UI traffic.debug
flags to emit payload and diff state for diagnosis. I've written (de)serialization and diff wrappers to help with this so far, which could also be a way to satisfy the need without flags and in a "pay for what you use" approach. Would you have an implementation preference?Anyway, I wanted to reach out to make sure I take an approach that you're comfortable with.
The text was updated successfully, but these errors were encountered: