How big is too big for a redux store?

Question

So, I am considering putting our entire translation object into the redux store before hydrating onto the client. This translation object is approx 50kb gzipped, and 115kb uncompressed.

Our entire site is translated, so this translation object basically represents all non-dynamic copy across the website. If it's hydrated onto the client on the initial http request, it should provide for an instantaneous browsing experience, at least for in-house copy.

However, I'm wondering if this is way, way too big for a redux store?

Majors

Answer 1

You should load the translations separately. Webpack allows for code splitting which can help. Or you can just use a script tag.

The reason for loading it separately is so the browser can cache it. This allows it to be loaded only once per user. Since the HTML page generated by React is dynamic and the store you pass down is also dynamic, they cannot be cached.

With such a large lump of data, loading it on each page load is just a bad idea.

Also, the store is for state. It's to handle stuff that changes. Putting static data in there is not what it is meant to handle. This doesn't mean it can't be done, but it's just not a good match.

Shortstop

This is probably still a valid answer but looking to the future with HTTP/3 QUIC protocol, I don't think code splitting will change the load speed. – Hideous

Answer 2

I don't think there's a 'too big' size for a Redux store. However it should contain only application state. The translation objects should be in the code and you should access them through a i18n library. The state should as much have a field which says what language you must show to the user.

Scleroderma

Vague and subjective... Inside the store is "in the code". Moreover there seem to be many solutions which incorporate translation data directly into the store. Do you have anything more concrete, or is it just your opinion? To be clear, I would not be accessing keys directly inside the state, but merely loading them there and pointing i18n at it. – Majors

@JohnDoe of course it's just my opinion, you can save whatever you want in the store, but as the first line of the Redux documentation says, it's a "state container". Why would you save all the static data that does not represent the global state of the application? – Scleroderma

I mean, it is "state" in a sense that users can freely change the UI language. The localised content is in fact a "state" of the application. – Majors

@JohnDoe but if you have all the texts of all the languages that's not state. Anyway, there would not be any problem with having all the texts in the store, I just don't think it's OK. If you want to go for it, do it. I don't think it will give you any problem, though I don't see the benefit. If you don't want to load all the data you could do some kind of lazy loading to load only the data you need. – Scleroderma

@Majors just a few years later, one consideration on the topic: one could argue that the chosen language is actually part of the state, as the user can change that. As a result of that change, components update themselves. E.g. the language dropdown could hide the current language, and page could show translated contents. But translated contents do not seem "state" to me. – Gallican