From Redux Sagas to React Query
The problem
League historically has been a single web app which relies on Redux and Redux Sagas for data fetching logic. As League moves from software-as-a-service (SaaS) to platform-as-a-service (PaaS), we have been focused on splitting the functionality and logic of the app into different packages and SDK’s which can be reused by other applications — we’ve called this effort “modularization”. This process has given us a chance to step back, analyze and not only rethink our architecture, but also our technical choices.
As a member of the web platform team here at League, we saw this as a very positive opportunity to simplify data fetching logic and make modularization easier. We were also mindful that the decisions we were making would affect everyone’s day-to-day life at work. The technical choices were not just about optimization, but could also improve or decrease developer experience.
Historically, requests were handled with Sagas and all responses were stored in Redux. This led to a very large and complex client state that in turn created performance issues, brittle patterns and a frustrating codebase for engineers to work with.
This complexity helped outline our main goals: simplifying data fetching, reducing the client state dependency and ultimately making our code more modular. This would not only benefit current Leaguers but also make onboarding easier for new team members by using more widely-used patterns for data fetching.
Comparing technologies
We did some research to try to identify all of the potential tools that would satisfy our constraints, and meet our internal guidelines when introducing a new library.
We brought the problem to the greater web team in one of our team-wide bi-weekly syncs, discussed the problem and got input on which solutions we should do a further deep dive. We ended up choosing three options: SWR, RTK Query and React Query. While all three offered great solutions, we ultimately ended up picking React Query based on its API, documentation, support and public adoption.
Exploring the change
With goals identified and technology chosen, we could now explore ways to modularize our codebase. Leveraging the many helpful methods of React Query made the change quite smooth.
Our next step was to communicate how teams could modularize our components and features. Something we learned when making such a large, platform-wide change is that knowledge sharing and empathy are paramount.
Not everyone will be familiar with this new technology.
Not everyone will understand this new technology. What feels “easy” for you may be difficult for others.
Not everyone will have the capacity to learn these new patterns while balancing tickets.
Not everyone will want to change, and they may not want to voice that.
To help reduce these feelings, we have tried to speak to the changes we are making as much as we could. We provided pull requests outlining different refactor approaches, and had great conversations surrounding the change. We also provided guides on refactoring, support by jumping on teams to help with refactoring their code, video demos, 1:1 syncs, group syncs and Slack channels dedicated to answering questions.
Providing proofs of concept helped alleviate concerns for team members who were unsure about the change. These steps moved the hypothetical benefits to something tangible. We were happy to see the adoption met with excitement, even if it meant teams would be refactoring a lot of existing code.
Final Thoughts
Working with teams outside our own has given us a greater understanding of how these changes affect an engineering team. When you are close to a project you have the full scope, understand the intricacies and things may feel fluid. On the flip side, when you’re looking at new code patterns for the first time it can feel daunting when your workload is already large.
Before becoming a developer, I played music professionally. In that time, I also spent many years as a teacher and clinician. An important perspective that straddles both, if not all industries, is to remember what it was like when you first started. Started in that industry, started that project, started reading those docs. Remind your colleagues that they will grow into the change. Tech is important, but more so are the people using it.
