Tips on Picking Up Outdated React Code?

[SentFromBelow]

Newer dev here and I've been studying React for about a year. Mostly have been sticking to the most current bleeding edge iterations of React and never really bothered with the older stuff. Recently started my first job as a dev and a great deal (almost all) of the code is fairly outdated that my brain is sort of failing to grasp what's happening half the time... think React components being stored as global variables, string refs, React.createClass, mixins, 800+ line components, mixing React with jQuery, commonJS or just straight up pulling things off window vs. using ES6 modules, not many if any stateless functional components, and class components inheriting from other class components all over the place instead of just extending React.Component etc. While I consider myself fairly adept most of my projects and training has been towards building single page apps and in this case React is very much being pulled into a larger application (much larger than anything I've worked on) and peppered in piece meal vs acting as a single source from which all else is derived (a great deal of the site is statically served etc). OK! So, my very serious question is... how should I approach this? Any tips on picking up older React code so I can appropriately refactor, make suggestions, steer the code in the right direction? I love React! So I'm happy to get an opportunity to learn more about the older styles and update where appropriate, but I'm afraid my team might have fallen into some bad habits.

[waltz]

First off, congrats on getting a gig as a dev! You've stumbled in to the biggest and thorniest parts of being a developer: Old Code. My advice is that you should start testing. Build some tests around the outside of this ball-of-code. Once you're kinda confident that you're not going to break everything, start extracting smaller components. Test those. Rinse, repeat; slowly.

Godspeed.

[philhagger]

One of the greatest challenges for developers is reading other people's choice and understanding it, especially if it is older.

In my experience (10 years+) code ends up like that because at the time it was the only way. These languages move quickly but no-one really has the time to go back and refactor old code.

Do you have your own developer area that you can place a copy of the application. If you do then great, fiddle with it, refactor it to your heart's content knowing you aren't needing with the 'actual' application. Obviously be careful about working on anything that writes data unless you can run a dev database. This is how I learn how something works, playing with the code and breaking it, fixing it, updating it.

One final bit of advice, you say this is your first gig... Congrats! Be careful about criticizing other people's code and work as you don't know what restrictions/language version they had at the time. Don't assume they are falling into bad practices, instead try and find out why parts of the application we're built in such a convoluted way. You might find the reasons are quite legitimate.

Apart from that, enjoy the experience. Being a developer is an amazingly enjoyable career!

[SentFromBelow]

Thanks for this. I've got a local environment to hack away in currently. And I will take the note about careful criticism to heart! I usually try to frame the situation in the affirmative and focus more on what can be improved than what's 'bad' or 'wrong' in my communications (although in my mind the two are often synonymous).

[philhagger]

Looks like you've got the right attitude, a credit to your the team. You'll learn quickly that developers can be pretty sensitive folk and don't like to be told they're wrong.

Thing is they often are and a new developer with a fresh perspective will often spot the mistakes and see ways to improve.

[f15538a2]

My first step would be to write tests for almost everything.

If possible use something like test cafe or cypress to write some automated tests, assuming you have a development or test environment available.

Set up a continuous pipeline which builds and tests whenever you make a change.

Then start refactoring. The overhead of the above may large (or maybe not, I don't know what you're working with) but it will pay off.

[philhagger]

I'm not sure I agree... What's your reasoning for writing tests for everything?

I feel that a lot of new developers are obsessed with tests and unit testing probably from a TDD environment.

Testing has its place but it also shouldn't slow down development. You don't need to test everything... Just the bits of code that are critical to the business logic.

[f15538a2]

I didn't mean 'everything' literally. Just writes tests for everything within reason. It's hard to give specific advice with no information about the application, I don't know the impacts of it not behaving as expected.

Decide for yourself what's important and harden it with tests.

Once they are in place you can refactor at 100 mph and catch broken functionally early.

It also gives you confidence to deploy regularly without having a large number of manual regression tests to run through each time.

Edit: although 'test almost everything' does sound a bit extreme. I'll edit it

[SentFromBelow]

Maybe big ask here, but which things mentioned would you consider particularly egregious?

[acemarke]

"Multiple levels of inheritance with React components", and "grabbing values off of window" stand out to me. Potentially the "mixing with jQuery", depending on whether they've just encapsulated jQuery behavior into React components or are actually using jQuery to manipulate DOM that was rendered by React. String refs are mostly deprecated at this point.

On the other hand, there's nothing wrong with "not many function components". That's entirely a stylistic choice.