Check out a free preview of the full State Management with Redux & MobX course

The "Reselect Performance" Lesson is part of the full, State Management with Redux & MobX course featured in this preview video. Here's what you'd learn in this lesson:

Steve gives a real world example of a performance issue that could occur when using the Reselect library.


Transcript from the "Reselect Performance" Lesson

>> Steve Kinney: Is another place that we can use reselect. Any time a new list gets created, we don't need to fetch all the users again, they haven't changed. So we can implement pretty much the same pattern, which is, hey, if the state.users hasn't changed, cuz anything that happens in the list.Reducer and the card.Reducer isn't even touching the user.Reducer.

We can use reselect to like, hey, get me all those user.ids. If that hasn't changed, give me back that same array, which will not actually call any of this, which is super cool. There are some testing notes that you need to remember. This comes from real world experience, we got very happy to use reselect all over the place.

But, it's kind of like a running theme, which is, if in any of these functions you are creating a new array, so if we did object.values inside of one of the checks to see, well, that's gonna be a new array, and you will always opt out of the caching.

So we actually, occasionally we do six sprints in a row, and then we have, innovation sprint, or whatever. And one of our engineers two weeks ago, basically audited the application and found out all the places where we just, a lot of times it was like no individual person's fault.

I have this thing, I'll move this code over here, I'll use the selector, and we had a few where we were generating new arrays in the ones that would use these kinda checks. And so, we were always regenerating, so basically the selector was a no opt. And, one thing about a lot of these performance improvements is that, if you do them wrong, a lot of times they're worse.

If you throw should component update in every single react component, well, calling should phone update costs you stuff, right? And so, a create selector and a selector check that isn't working is worse than not having a create selector. One of the ones that we'll kind of look at is, what happens if you have to pass something in?

Well, the act of passing something in would basically go ahead and make sure that you would have a new result every time. If we had to pass in the cardId, well, that's gonna be different for every single card. And so, you're not gonna actually, your selector will work great, it will just never be called twice.

And so, this is really good for seeing if the result of a function is the same, but you kinda have to combine some strategies. So, selectors are effectively using memoization, lodash also has a memoize function, which is, hey, if it's the same cardId, Give us back the same selector.

So this now gives you a memoization on the given cardId to give an argument, and then a selector for all of the list. So now, both would effectively have to change before you. So if it's the same cardId and the same list, you'll actually get back the same selector that you had the first time.

Same cardId, you'll get back the same selector, that same selector will check to see if there's multiple lists, any changes to the list, you'll basically have multiple checks in here. But I do wanna give a word of advice, like I said, poorly implemented performance improvements can sometimes be worse for performance.

So I would always argue, open up your Chrome DevTools, this application isn't big enough to get to the point where we have truly horrendous performance anywhere. It is death by 1000 cuts, but also trying to put band aids when you don't have a wound is also problematic as well.

So just try to make sure that you're being very careful, that you're measuring and seeing what the problems are first, or at least you're measuring before and after, like in science, right? Take the control, do the experiment, look at the result, and see that you've actually improved anything.

We have courses on performance, you can definitely check those out, and there's more about that, but this is a tool for stopping needlessly doing more expensive tasks, but it should be used incredibly wisely. All right, so next what we're gonna end up talking about is, how do we deal with async?

All of this has happened internally. So we're gonna need to think about that a little bit.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now