Dependency on react/redux is whether or not you use react/redux . If you don’t want to use it, then use something else. If you do use it, the dependency is there. Single-spa doesn’t change that. It adds an additional dependency that attempts to help coordinate individual components of a page. If you’re using a single framework, that framework will already provide that coordination.
Where single-spa might be helpful looking forward is providing a means for a staggered migration path where you would be able to more easily swap out old components with the new migrated versions with minimal impact. This would then let you run the application with both frameworks at once, react for the old stuff, and future-framework-x for the new stuff. While we’ve done this before - at a more granular level, and without single-spa - generally its not ideal because of the extra overhead of having both frameworks served to the user rather than just the one. It depends on how massive your SPA is though, and what your migration plan is.
We’re in the middle of a migration now (from backbone to react) and we’re not doing any kind of transitional release where both frameworks are running together - at least not for this particular component. The react version is being developed internally until complete, then will be released as a full replacement of the original.
As far as modules go, it’s up to you. You can deploy a single bundle with all of your modules combined into one file, or you can have that split up into smaller files which get loaded as needed. It takes a little more coordination to have split files, but if you’re experience issues with startup time because your all-in-one bundle is too big, then that’s something you’ll want to do. Webpack docs have info on this: https://webpack.js.org/guides/code-splitting/