Support non-app wrappings

I tried using this to build a site with two major parts; the public site and a user-facing app (and soon an admin-facing app). While developing, it soon became apparent that I can’t wrap all pages with this library, since the default state for all reducers in the app, is simply too large to comfortably sent on every response (pages go from 70 KiB -> 500 KiB), when it’s not even being used on a majority of the pages.

In fact, some pages are heavy redux users, in which case it’s being used to orchestrate interactions rather than data fetching; i.e. the type of interactions that makes Redux really shine. This, however, leads to the large state.

So I started looking around, and found the with-redux-code-splitting example; it’s a perfect fit, since fast-redux attaches reducers as you navigate to pages using them, and I have previously (the last two days) been experimenting with client-side only redux.

However, it uses v1 of this library, and v3 enforces being attached to the App instance. I can’t help but think that the on-App enforcement goes against the layout-per-page pattern that NextJS establishes. Besides that, the enforcement makes code-splitting per-page less effective and rules out the use of libs like fast-redux.

What are your thoughts? Is there any point in bringing back the modularity to this library and not forcing on-App wrappings?

[haf]

App-based approach makes ALL pages wrapped.

Which is precisely what causes output sizes to balloon.

Please read once again and more carefully.

OK: here.

The main purpose of this library is to make sure actions are consistently dispatched on all pages on client and on server from getInitialProps function, […]

I’d prefer a library that does “[…] consistently dispatched on all pages using redux on client and on server”

which makes all pages incompatible with Automatic Partial Static Export feature.

This doesn’t concern my setup since I also use i18n on each page, causing the static export feature not to work anyway.

Previous version of the lib was working on page level, […]

…but it doesn’t export the right TypeScript types.

[…] so theoretically you can wrap only some pages, but on the other hand you would then need to make sure that no redux-connected components will appear on pages that were not wrapped.

This is a fine trade-off for me.

So rule of thumb always was to wrap all pages. Which is exactly what the new version does.

Sure, but I don’t want that.

Which brings us to conclusion: If you need a static website […]

Not my use-case.

[…] you don’t need this lib at all because you can always dispatch at client side on componentDidMount just like you normally would with bare React Redux, and let server only serve initial/static markup.

I’ve considered client-side rendering only, but it creates more complexity for me since I want to render server-side redux default state. This means I have to use the v1.x version to wrap specific pages anyway, and then we’re back to the problem I told you about in my initial post; that this library has gotten worse or has stopped supporting a major use-case, without anyway out of it.

[kirill-konshin]

1.x is still supported, in case you find any bugs there.