jeffbski / redux-logic

Redux middleware for organizing all your business logic. Intercept actions and perform async processing.
MIT License
1.81k stars 107 forks source link

Improve bundle size by dropping RxJS and improving build process? #172

Open markerikson opened 4 years ago

markerikson commented 4 years ago

I hadn't looked at Redux-Logic in a while, but was pointed back to it in a Twitter discussion ( https://twitter.com/matbrowndotdev/status/1290612927536467968 ).

Glancing at the lib again, one of my biggest concerns is the bundle size. Comparing things in Bundlephobia, redux-logic is 20K min+gz, while redux-saga is 5K and redux-observable is 1.5K:

https://bundlephobia.com/result?p=redux-logic@3.0.2

I see that the bulk of that size is from RxJS itself, as well as the core-js lib.

For comparison, Redux Toolkit itself is only 10K min+gz, and that already includes the Redux core and Immer. I can't encourage folks to use a Redux addon lib that's twice as big as RTK, much less even consider whether it might be something that's worth building in by default (per the "declarative side effects" discussion in https://github.com/reduxjs/redux-toolkit/issues/349 ).

I know that there's a bunch of other observable-based libs out there. How feasible would it be to switch to another observable implementation that's smaller, in an effort to shrink the bundle size? How much would switching away from RxJS affect the TS typings? I'm sure it would break things and require a major version, but are different observable libs compatible enough that you could still bring your own RxJS operators if you wanted to and hook in to whichever observable lib gets used here?

Also, could the build process be improved to shrink that core-js output?

Looking at the build output in https://unpkg.com/browse/redux-logic@3.0.2/dist/redux-logic.js , it looks like you're using Webpack for bundling. Have you considered switching to Rollup, and perhaps even rewriting the source in TS and using the tsdx tool like we do with Redux Toolkit?