Original subtitles

So Redux is a state management system

for cross-component or app-wide state as we learned.

And of course we can then ask ourselves,

but don't we have React Context for that already?

React Context is a concept and a feature

we already alerted about

and which we already used a lot in this course

because it also allows us to avoid prop chains

or prop drilling, and instead we can have a central place

our Context and the Context Provider component

which we use for managing state.

So why do we need Redux?

React Context has a couple of potential disadvantages.

And I say potential because they might not matter

in the app you're building.

And if they don't matter, you don't need Redux.

It is as simple as that.

And just as a side note, because it's all is important,

it's also not an either or decision.

You can also use both Contexts and Redux

in the same application.

Typically for application wide-state,

you will only use one of the two,

but then you could be using Redux

for the general application wide-state

and still use Context for selected multi-component states

which are important in parts of your application.

So mixing and matching like that would also be possible

but let's not dive into that right now,

let's instead focus on the disadvantages

you could be facing with React Context.

But what are these disadvantages then?

One potential disadvantage is that with React Context,

you can have a very complex setup

and managing state with React Context

can become quite complex.

And that definitely depends

on the kind of application you're building.

For a lot of small or medium-sized applications

that will very likely not be a problem.

But if you're building a large application

an enterprise level application with a lot of components

and a lot of things going on,

then when using React Context,

you can end up with code like this.

Where you have a lot of different pieces of Context,

a lot of different States that affect multiple components

or the entire app, and therefore

a lot of different Context Provider components

which you built for managing these states.

And you can end up with deeply nested JSX code

like this as a result.

Of course you don't need to build

a lot of different Context Providers though,

you could just use one big Context

and one Context Provider component

for a managing the entire state

and all the different kinds of state of your application.

But that could lead in a large Context Provider component

which manages a lot of different things,

and therefore itself becomes quite difficult

to maintain and manage because it's doing a lot of things.

You might end up with a large Context

that cares about authentication, theming, user input,

if a modal should be displayed or not,

and maybe a lot of other things as well.

So, that could be a downside.

And if you split it into multiple Contexts

you might be back to this picture.

So that can be a problem.

And we haven't faced it thus far in the course

because we definitely didn't build a large enterprise

level application in this course at this point.

But you can absolutely face this problem

in real react projects you might be working on,

and therefore this is one potential disadvantage.

Another potential disadvantage could be performance.

We have an official quote by a member of their React team,

who basically says that the new Context,

which is the Context you learn about in this course,

the post is from 2018, end of 2018,

but still that is exactly the Context we are using here

that this Context which was introduced back then

which is why to post is from that date,

that this Context is great for low-frequency updates

like changing a theme, or maybe also authentication,

but it's not that great if your data changes a lot.

For a high frequency changes,

though it's not clear what exactly high-frequency means,

but for changes that happen more frequently or often general

that it's not that good for that.

And this team member says that,

therefore this new context is not ready

as a replacement for flux like state propagation.

Now this might not tell you much

but Redux is a flux like state management library.

So he says that React Context

is not really a great replacement

for Redux in all scenarios, in all cases.

So therefore that's our second disadvantage,

performance can be bad if you're managing

the wrong kinds of state with React Context.

Now, therefore to sum it up,

we have the complex setup and management disadvantage

because we may end up with deeply nested JSX code

and a lot of different Context Providers

or with one huge Context Provider which is not maintainable.

On the other hand we have potential performance issues

because we should not use React Context

for high-frequency state changes.

Now I will, again, emphasize that for small

or medium-sized apps and even certainty a lot of big apps,

this might all not matter,

but of course my goal with the course here,

is to teach you realistic React

which you can apply to any kind of project.

And therefore it is important

to be aware of these limitations of React Context

which could matter in the projects you are working on.

And that's exactly why in this module

we are learning about an alternative to React Context.

We are learning about Redux

which does not suffer from these disadvantages.