Render Material-UI Modal in the center of the Screen

The Material-UI Modal component is a very powerful and commonly used component in the ReactJS community. Unfortunately it is badly documented. One of the most common questions is how to center the modal to the center of the screen. Well the solution is actually quite simple, just add a style prop as follows:

          style={{ alignItems: "center", justifyContent: "center" }}

Hot Reloading Node and React on Docker Windows

Ever since I moved my development environment to Windows, it has been a constant struggle to emulate the previous environment that I had built on OSX.

Probably one of the most critical components in my projects is the fact that all of my projects run on a Docker microservice architecture. In addition to the usual isolation and scalability advantages, development becomes a joy especially when you use filesystem watchers on NodeJS (nodemon) and ReactJS (react-scripts) that enable hot-reloading.

The problem is that, out of the box, these file watchers do not work on Windows 10. The reason is that to run Linux container on Windows 10, you need to have Hypervisor, which acts as a virtualization layer - hence all virtualization rules apply to hot-reloading!

In other words, in order for hot reloading to work on Docker Windows, you need to enable Chokidar polling.

How do fix Hot Reloading with Chokidar?

For NodeJS, just modify the package.json file to use the legacy mode when starting nodemon. This can be easily done using the -L flag.

  "scripts": {
    "server": "nodemon -L index.js"

For ReactJS, it is equally simple. Just add a .env file inside the project parent directory (/usr/src/app) with the following line:


Trigger TeamCity job when specific branch is merged to Master

Any DevOps who has been involved in some serious CI/CD pipeline architectures have met these particular requirements at least once in his life:

  1. Detect hotfix* branches that are merged to Master
  2. Detect feature* branches that are merged to Master
  3. Automatically trigger a job if (1) is true
Although most build systems support this feature (I know for a fact that this is the case for Bamboo and Jenkins) and the methodologies are similar, this blogpost will focus on Teamcity, probably because I saw a lack of documentation on the matter.

Teamcity is notorious for being tricky! The only way to trigger merges is by listening to the commit messages. With this in mind, we will bake our commit messages to reflect our needs.


We will assume that the commit message looks something like:
git commit -m "hotfix-*"

Trigger when HotFix branch merged to Master:

Trigger when Feature branch merged to Master:

In both cases, the VCS should be only monitoring the Master branch:

Calling setState() behind an async call in ReactJS

I have blogged about how dangerous it is to use setState() during component lifecycle methods or render() functions. This is because the component can end up in an endless nested deep render. Dan Abromovic and the creators of ReactJS have also talked a lot about this subject. This is why we associate setState() with an event, like a button click.

A similar design pattern exists in ReactJS when we try to use setState() after calling an async function. In Redux we would not have this problem of course. However let's say you are rendering a location pin inside Google Map without the complexities of Redux state management. So all we want is:

  1. Geocode an address by calling Google Maps API
  2. Wait for the API response
  3. Set the map marker state so you get the pin at the right location

If step (3), the setState() function, is called before we get the API response, ReactJS is most definitely going to throw an error? Why? Because calling setState() before the component has fully mounted, or is still rendering, or is re-rendering, is a cardinal sin in ReactJS. 

So to make sure that step (3) is always called at the very end, we can easily make use of the async functions. Note that in setState(), the common pattern to call it synchronously, is to bind it to a function. Checkout this working code below to understand what I am saying:

Chaining API requests with Redux Thunk

Recently I wanted to be able to gather an array of objects on the first API request, and then for each object, fire off another API request that will get the object data using each object id. As you can imagine, the challenge is chaining multiple API requests using Redux Thunk and Axios in an asynchronous fashion.

Although the problem seemed simple, I realised that the solution is not equally trivial. I also figured out why this kind of design pattern is not documented:

Scenario 1:
Most users don't approach this kind of problem in this manner. In fact, most users just stop at the first API request to render a list of objects. Then they wait for the user to click on one of the objects to render the subsequent object details.

Scenario 2:
Users use other technologies other than Redux Thunk... technologies such as Redux Saga, to chain multiple API requests. In fact, this is one particular use case for which Redux Saga was designed.

Nonetheless, I was convinced that Redux Thunk can be still used. Apart from that, I was in a tight timeline to deliver a project so learning a new technology was out of question. The use case was for a  new aggregator system (from Reddit) that first fires an API to get latest Reddit posts, and then fires another API request for each Reddit postID to get the comments on each post:

I was able to solve this in redux-thunk by making two actions; one to fetch all, and one to fetch each individually. And, to chain them together, we treat each action as a promise (they return axios promises), then let Redux Thunk do its magic.

Let me show you the code snippet:

Notice that I made use of the getState() method to get the array of objects from the first API request promise. The getState() method provides us with a very easy way to pass state values (in this case, the array of objects) to action creators. It is important to understand that we are dealing with promises here, so the getState() method is exactly what we need - once the promise is fulfilled, the second action creator (and therefore, API request) is kicked off.

This design pattern is extremely important and will give you more mileage in your React Redux projects. For posterity, this is how you can then render the data inside your component:

Fire Action Creator after React State changes

I have recently come across a situation where I needed to wait for an axios async request to complete, get the final status from the response (either a success or an error message) and then, depending on the outcome, fire off an action creator. Additionally, I needed to complete the UX journey by redirecting the user to his dashboard through React Router.

In other words, what if we want to trigger an action creator in ReactJS after the Redux application state has finished all its mutations?

Since ReactJS is based on component re-rendering, this should be an easy task right? Well...not really...Usually this is the best task for UI rendering only...but conditional action triggering is something more advanced. Most experienced developers would suggest to use an aptly lifecycle Component method, such as ComponentDidUpdate(). This works in most cases, and in general, is the most recommend method:

The problem is that these lifecycle methods, and any other methods outside the render() function, such as generic helper methods, do not work well with React Router 4, specifically <Redirect /> *. So for example, in my case, I wanted a customer to pay for a subscription, then when my backend server sends a specially crafted response, this will be updated in my Redux state, and hopefully, trigger this action creator. After that, I want the customer to be redirected to a Dashboard component.

*Although we could not use the <Redirect /> method, we can use another React Router 4 redirect technique which works well with helper methods outside render() functions. This technique will be described in a future post. As a sneak peek, this entails using the this.props.history() technique.


So if I cannot listen to state changes inside a lifecycle/helper method, what is the alternative? We can always listen to state changes inside the rendered component itself. One trick I like to use is putting a ternary operation or a classic old if condition that triggers when on a state change. Remember, when the state is updated, the component is always re-rendered through React Redux until the condition is matched, and triggering the next action creator. This is the flow I am using:

Note that in my particular case,  the success or error object is only made available inside the state tree once the axios operation is complete, hence why I am using the !! notation.

Remember that once the action creator is fired, remember to reset the state tree, otherwise you will end up an infinite loop and keep triggering the same action creator :)

Updated and Better Solution

There is actually a better way of doing the redirect and still using the recommended React component lifecycle methods. Since the <Redirect /> technique does not work well with these methods, I suggest to instead use this.props.history.push() inside the ComponentDidUpdate() to perform a redirect. Just remember to wrap your component with the withRouter() HOC. The code will therefore look similar to this: