During my last React project, I needed to process some data that I had fetched from my API. Since I was testing wpm, I wanted to have a stats page, showing information about the results from all the tests taken. In order to show this info, I needed to make a decision. Do I put all the logic into the API, so the front-end can simply take the exact data and display it? Or do I fetch raw data from the server, and then process that data within React, and then display it?
Well, if you read the title of this post, I guess it’s pretty obvious which I decided. There was no huge reason I chose to do it that way – I just figured since I was focused on developing in React, I might as well let it handle some of the logic – and I wanted to keep requests to the server simple. It’s also nice to offload calculations to be done client-side I guess, if it’s non-essential for the server to do it. I don’t think that matters much in this case though.
Anyway, having decided to process the data in React, I still had to decide when and where it made sense to do that. When someone visits the stats route, a few possibilities come to mind for where I can include the data processing logic. I can put it into the componentDidMount() function. This is where asynchronous requests often go – it allows for the page to load – while it does its thing in the background. It’s common to put a fetch there – that way the screen doesn’t hang while it waits for a server response. This isn’t a bad place for it, but something seems off. I’d have to either set up a local state that I update with the information I fetched, or I’d need to set up a new action/reducer to update my redux store with the stats I want to receive into the component as props.
Since I know I want to end up with the stats in either my local state, or better yet, my global redux state, passed down as props, it makes more sense to process my data within my mapStateToProps() function. Since I already have the infrastructure in place for fetching the test results and passing them down as props in that function, all I have to do is add some logic there that will handle the calculations and sorting of that data. Then I can just define new props there, and pass them into the component – keeping it as dumb as possible! That means I get to have a component that has all the info it needs handed to it as simple props, and all it has to do is make it pretty and display it on the page.
After talking with a few other developers about this, and showing them my code, I’m pretty confident I made the right choices on this. Something that was interesting to me was that in a few cases, it didn’t matterย that much what choice I made – it was more a matter of convenience, or preference. However, I think it’s still important to be thoughtful about these sorts of things, in order to make my code intuitive, and to adhere to common practices wherever I can. I think this will make it easier to jump into existing projects I’m not familiar with, and set up my own projects in ways that other people will be able to collaborate on if they want.