Marvelous Thorough React Tutorial/Workshop — part 7
This series of articles is written as notes used during the workshop hosted in Gdańsk, Poland by OKE Software Poland. It does not pose as comprehensive and complete tutorial serie for anyone, yet it will be used for workshop aimed for developers that have none experience building SPA using React. I am posting it here as I think some people might find it useful. Please do not hesitate to correct me, if you find some nonsense. Also please bear in mind that english isn’t my native language, so forgive me any grammar and linguistic mistakes. Enjoy!
BTW here’s previous part:

Plan
Part 7— Lifecycle of a component, Connecting to the API.
All web apps have to fetch data from somewhere otherwise they’d be pretty empty. Today I will show you how to do data fetching and posting using React. We we’ll be using battle tested library called axios.
All thanks to Wojciech Nadurski 😍 we have now an API available. It’s under:
https://github.com/wojciech-bilicki/MarvelApp/tree/step7-with-server-added in server folder. Please checkout this branch or simply download the server. There’s readme file in it to tell you how to run it. Additionally when you run a server you can find full documentation of the available endpoints under: http://localhost:8001/docs.
Lifecycle
Some of you have been in jobs interviews. Many of us have the rough idea of how they go. Talking to the HR, talking to the developers, you may be given an additional assignment or be asked to write some code in the office of the company. And after all that struggle you hear those for magical words:
We will call you
As annoying as they may be this is the standard in our industry. It would be crazy to call every hour to the company that you’re trying to get and ask:

The same goes for the lifecycle of our component. It has to be mounted into the virtual DOM, it has to be rendered, it has to react when the state or props are changed. We don’t ask React:
Dude, have you mounted this component already? Have you? Have you? Have you?
It’s called Inversion Of Control. We let react inform us about the events that are taking place in an interior of its mechanism. And it is working great!
React provides few hooks that are available to any component that is built using the class syntax, which are:
- constructor, getInitialState -> Well, pretty obvious called first when the component is constructed. Called once.
- getDefaultProps -> the default set of properties for given component. Maybe we’d like our number input to always default to zero? Called once.
- componentWillMount -> called just before the component is being sent to mount to virtual DOM. Called once.
- componentDidMount -> called just after the component was mounted into the virtual DOM. This is the place where you want to call your API for the data to feed into this and children components. We’ll be using that a lot.
- componentWillRecieveProps -> called just before the new props from the parent are fed to the component. If you have some state that is basing on the props here is the time to recalculate and/or set it. For example you have an input that maintains its own value but resets everytime new props are coming from parent. Here’s the place to call
setStatewith the value that you get from parent. Called every time when parent passes new props. - shouldComponentUpdate -> very interesting callback. We can use it for the performance tweaks. It should return boolean value. If you have component that never updates (like idk logo of your company or static icon) you can return false to let React know that this component shouldn’t be updated on any circumstance or you can implement more sophisticated logic to check the changes in state transition and decide whether this component should be rerendered. Called every time when parent passes new props;
- componentWillUnmount -> this callback can used to clean up any resources or letting go of any external event handlers. Called once.
- render -> called every time component should render.
Ok we will probably introduce some breaking changes as we go, but we’re fine with that.
We’ll start by making our Master component calling for the heroes data. To do that we unfortunately have to change it from functional stateless component to stateful using class syntax:
OK that wasn’t so bad. You can check in your console that the hooks are firing in order. The componentWillRecieveNewProps hook wasn’t fired, because all the props were available to the component from the very start and this hook isn’t called on initial render. So let’s discuss the changes that we had to introduce:
- We use
extends React.Componentto create our component - The
<Props>is coming from the FlowType meaning that we don’t concern ourselves with the typing of state and props should be typed asPropstype. This is the new FlowType syntax for React components. - We added the hooks discussed just to show how they work.
- We had to provide render function that return the jsx markup for our component which is pretty much the same as the functional one except we had to add
thisbefore using the props. We could also do the props deconstruction to get rid ofthis. Pun intended.
Ok let’s add axios to our project and actually use our hook to do something helpful.
yarn add axiosOk let’s first change our App.js to get rid of the data being loaded from .json file:
Great. Now we get some errors in console since the heroes are no longer being provided as a prop, but will fix it soon. Ok so let’s get rid of all the hooks except for componentDidMount and change it to:
Ok so what we’ve done here is we added type State definition in line 14 as well as used axios to make HTTP GET call to our api under the heroes url. After this is resolved successfully in then part of it we add the result to the state. Wasn’t so hard, was it?
Yeah, let’s also fix our HeroCard to display the images once again:
Ok we’re back on track. This part was a lot shorter than the others.
Now let’s try adding the MyHeroes section to the mix.
Let’s update our Master.jsx to:
We will fix some ugly code that we see right know later. For example I really dislike how our componentDidMount looks right now.Ok as for the MyHeroes component it’s rather repetitive to what we’ve done already:
The points that are worth highlighting here is that we’re using flexbox to create two column grid (for the heroes list and for MyHeroes component) and that we are using conditional rendering in render method for MyHerores component to show the empty state of it. We simply render the information that there are no heroes added. React makes it very easy to implement this kind of pattern. Looks like we’re prepared for adding heroes to favourites. Let’s do just that.
First we must implement the callback in parent (Master) component to pass it to children (HeroCards):
and naturally use it as a callback in our children component:
This is another common pattern in React you pass a callback from parent to children. Children calls it upon an event and parent acts on it doing smarter/more complex stuff.
Ok so far so good but I really dislike the code in our Master.jsx. Let’s create another file and call it api.js.api.jsx. We we’ll use Promises and Promise chaining to provide the data for our Master component. Axios also has this fantastic feature of setting default configuration which we’ll use to keep our code clean:
Ok now let’s add some fine looks to our favourite hero component and create FavouriteHero.jsx file:
and of course we need to update our Master and MyHeroes to pass the onDelete callback two levels down to the FavouriteHero component to be able to delete heroes.
Ok so there are two more component that I’d like to add before we call it a day and move to Redux. Let’s add routes for the HeroDetails and Comics:
We’ll handle the ids passed to Detail and Comics component differently than in Master in just a second.
Ok let’s do the Details component first:
There’s one thing that I’d like to point out to you. We decide to use css grid to build simple two column layout. It’s great technique for building fluid layouts in modern browsers. You should definitely check it out.
Ok to make it work we need two additional endpoints in our api.js :
and of course the ComicsThumb.jsx:
And as for the comic details here’s Comics.jsx. I leave styling up to you to enhance as it’s not the core concern of that workshop:
What’s left now is to connect the pieces. We’d like that when we click on our hero portrait to be taken to hero details. Same for comics. Ok let’s fix our HeroCard.jsx first:
And than of course ComicsThumb.jsx:
You’re more than welcome to go to the TabBar.jsx and add Link to logo for returning to the main page. What’s left here to do? We could tweak the styling of course. We could add component with the list of all comics. We could write more tests and improve our FlowType coverage across the project, but it would be all rather repetetive to what we’ve done already. I’d rather move to Redux, which YOU MIGHT NOT NEED. We pretty much finished the App without even knowing what Redux is, so don’t just hop on the hype traing and really think whether your project will benefit from Redux or will it just add to the complexity?
As you saw React is not that hard. It doesn’t have very rich or complex API (Hello, Angular 1.x). It utilizies stuff that you already know and doesn’t add confusing syntax (ng-*) on top of that. It’s declerative, it’s simple. You can think of your app like a pieces of Logo that you’re just tying together. It’s easy to add stuff like empty states or loaders. You should definitevely give it a chance. There’s still many other things regarding React that you should learn about, but Medium and YouTube are fantastic source of knowledge and you should definitely reach out for more! See you in a next one!
