💡Why I Use Apollo Client as a Replacement for Redux and React Context [thread]
As you may know, I've been writing about software design and architecture for the better part of a year now, and starting at Apollo last year, I realized that there was something special about Apollo Client but couldn't quite put my finger on it.
Today, I can tell you that one of the best things about Apollo tooling is the architectural advantage that it creates for front-end developers.
Data-fetching, data marshaling, optimistic UI and more has been made a responsibility of the tooling.
Data-fetching, data marshaling, optimistic UI and more has been made a responsibility of the tooling.
Every state management library has the same three goals in the end:
1 - Storage (hold state somehow)
2 - Updating state (change that state)
3 - Reactivity (notify pieces of the UI that rely on state, that it has changed)
1 - Storage (hold state somehow)
2 - Updating state (change that state)
3 - Reactivity (notify pieces of the UI that rely on state, that it has changed)
Traditionally, you'd have to build your own state management architecture from scratch. Redux and React Context give you the building blocks, but you still have to use those tools to build, test, and maintain the entire architecture yourself.
Those of you who've done this know just how much work that can end up being- especially on larger projects.
**sometimes, it's half the work of the project**
**sometimes, it's half the work of the project**
With Apollo Client, I've noticed that we write about 50% less code because all of that complex "data layer & state management" code has been abstracted away.
We just focus on the application-specific stuff that makes our app special (components, UI & interaction logic).
We just focus on the application-specific stuff that makes our app special (components, UI & interaction logic).
Of course, as engineers, we've learned that there is no silver bullet. Nothing is as perfect as it seems. Comparing Apollo Client vs. Redux or React Context, the options for how to handle state management are as follows:
- [AC] Start with the entire state management architecture built, tested, and maintained for you. Just learn how to use the APIs.
OR
- [Redux, React Context] Build, test, and maintain your own state management architecture, then implement your application-specific code on top.
OR
- [Redux, React Context] Build, test, and maintain your own state management architecture, then implement your application-specific code on top.
Choosing Apollo Client, the three categories of tasks we need to do are:
1 - Configuring the cache
2 - Asking for data
3 - Updating data
All those complex data fetching logic and features are available and opt-in using the tooling.
Man, the `useQuery` API does a LOT of stuff.
1 - Configuring the cache
2 - Asking for data
3 - Updating data
All those complex data fetching logic and features are available and opt-in using the tooling.
Man, the `useQuery` API does a LOT of stuff.
If you're interested in seeing some of the real-life examples of Apollo Client 3 being used side-by-side as a replacement for the other popular state management approaches, check out this repo:
github.com/apollographql/…
github.com/apollographql/…
And if you haven't seen the talk or blog I made on this topic, definitely check it out here as well.
apollographql.com/blog/dispatch-…
🤟
apollographql.com/blog/dispatch-…
🤟
