DEV Community

Zia Ul Rehman
Zia Ul Rehman

Posted on • Originally published at ziatechblog.wordpress.com on

Working around un-maintained redux-token-auth for redux and react 17 upgrade

A small case study from our recent efforts to upgrade our legacy react app, which included upgrading and replacing a number of libraries. This one focuses on one of them, that is redux-token-auth.

Tl;DR:

redux-token-auth had been a go to choice for many rails devs who started working with standalone frontends in react. But it has been majorly un-maintained, while on the journey of upgrading our front-end stack, this was becoming a blocker as it was locking to older version of redux and react etc, also had security issues. We ended up with a custom clone where we managed to fix as much as we needed.

Why are we sharing this?

This is a small case study of how we upgraded this package, and what issues we faced, what route we took and where we landed, we share with you what issues faced AFTER the upgrade. And how we resolved them. The purpose of sharing this small story is that before we attempted this upgrade, we tried searching on the internet for this, and didn’t found much, so we had to do our own R&D and it took us ~2-3 days of effort to finalize this upgrade. So if anyone is upgrading their stack(which we should do often) this should save them some time.

Full Story

Intro

redux-token-auth is a great library. What it mainly does is it provides a plug and play auth implementation functionality for ruby on rails based APIs which implement popular devise_token_auth for auth handling.

Problem?

Problem is, redux-token-auth is un-maintained for a long time , says so on readme, has number of open issues, with little to no activity. I don’t work in typescript, otherwise I would LOVE to take it over. (PS: A great opportunity if you want to actively work on an open source project, which is already used a lot, this is looking for maintainers.)

It works fine, for the most part, only when we tried upgrading redux and react, there were strange issues, which when we investigated when upgrading, pointed to multiple major versions of redux and react being in our package-lock, and being used by different components. Which is obviously a problem. There were already open issues for this, with no solution, so we had to dig.

Also there was old version of axios with vulnerabilities , which we had to get rid of.

Fix:

We tried with exploring the existing clones , there were number of clones, as its been years for this package being un-maintained. We looked into many of the clones, mainly looking into change-logs and commit changes from core. Many clones were also fixing 1 or two issues. It seemed like we will have to learn typescript and than do the fixes, which i was not willing as much to do.

After hours of search and try, we found a relatively healthy clone with a LOT of changes from original one, it felt a bit dangerous but we went through the changes_(I don’t do typescript, but i can understand its code, like someone who doesn’t speak a language but can understand it somewhat when spoken to him )_. (it had all changes in develop and not in master/main, which did caused some confusion and overlooking in start.)

This clone had already done the major parts of our work react and redux dependencies were pinned to latest , we just had to upgrade axios, luckily it didn’t cause any breakage in functionality. Then there were some patches we were using, you can see the commit history on github for our final clone as well, but i will put in a summary here as well, to save you some time.

Changes we got from our base clone:

  1. Minimum required Node version from 8 to 10
  2. React from 15 to 16
  3. Redux from 3 to 4
  4. All other dependencies also upgraded including jest/typescipt etc (detail here)
  5. Also a lot of code refactor, majorly because of upgrades of packages

Further changes we made:

  1. Axios upgrade (to fix security issue errors)
  2. General package upgrade (in a bid to make it last a bit longer)
  3. Fixes to remove a patch we were using prior to upgrades, as we use rotating tokens

All good?

Not quiet, we did this and used "redux-token-auth": "git+https://github.com/ziaulrehman40/redux-token-auth.git#9812f831a84968dba593b22b3f48b50b322e2351" in our package.json , but we bumped into this issue, for which we had to take this route.

All good now? Neh, Yet another issue (and a small hack to fix it)

redux-token-auth sets some data in redux under reduxTokenAuth.currentUser key to help us identify if auth attempt is in progress, or has been completed and failed/succeeded. But default data points ( isLoading and isSignedIn ) were not working as expected for some edge cases, after a lot of debugging(and nearly giving up on the whole custom clone thing), i found an un-documented data point, which helped us with everything, it is hasVerificationBeenAttempted, using this and incorporating it in our checks fixed the issue. This is the only part which seemed a bit hacky, but it was to be used in only 1-2 places, so didn’t seem like a big issue.

Next?

Next we moved to upgrading journey for other pieces of our app. And at the time of writing this, we have a final build ready of upgrades ready to go out in a couple of days. We will try to share more of our journey with you guys soon.

If you have any feedback, comments or questions, don’t hesitate at all. Until next time, take care!

Top comments (0)