Anyone who has worked on any sort of complex front-end where either race conditions or lifecycle issues temp us to use setTimeout() to wrestle with async problems. In Angular 2 and React apps, there are lifecycles to components and the logic of these lifecycles can be confusing and sometimes, counter-productive to the specific task you are trying to achieve.

I’ll give an Angular 2 example. This is one I have seen a lot… Let’s assume you have chosen to mutate a component’s private variable and perform some task on it, and although you are sure you’re logic should achieve the desired result, and you can never be wrong ¯\_(ツ)_/¯ , Angular goes and throws a pesky error to the effect of "an object has been changed after it was checked".

Well, no duh? You just changed it? Well, if you’re using a library like Redux or a variety of other similar state management libraries (which you should be), and maybe you’ve gone outside of the Redux philosophy on your component app, then these sorts of errors tend to pop up.

A little history of my experience with either Angular 2/Redux or React/Redux teams is that 90% of them violate Redux. Simple fact. Programmers are not fully understanding of pure functions, what reducers do, and why they are important. I’ll leave that to another post, but basically, it’s used to avoid state mutation, and much like React, or Angular, return to the browser a pre-configured “Single Source of Truth” DOM, Redux delivers your app a “Single Source of Truth” state object.

However, many programmers just want to change one tiny variable and don’t want to go through all the fuss of an action, and passing a payload to a reducer, and then handling the changes in the lifecycle of the library’s methods, and they just start mutating state, which is the first step down a dark and painful road.

Later down the road, when Redux is already violated, these damn “an object has been changed after it was checked” errors pop up. So many programmers just say, let’s put it up one tick in the lifecycle by using

setTimeout(function(){ this.foo = 'bar' },1)

Bad idea!

1) This is very difficult to test. I’ve even seen people go into the test suite, and perform a test that also uses the same setTimout technique. Another bad idea. So lazy.

2) This is a race condition, and while you’re on your zippy dev environment, things work as planned, but out in the wild, who knows? That’s why it’s called a race condition.

3) This is lazy.

What should you do?

Figure out the problem at its source. Use Redux or whatever state management you use to set state properly. If you do not violate any of the rules of the component lifecycle or the state management process, those bugs won’t exist. Even if it means refactoring. It simply has to be done. Using setTimeout() to wrestle async activity is a fumbling beginner’s mistake, and a sure sign that you don’t understand the lifecycle of your component, and could use more training on the library your firm is using.

Share on FacebookEmail this to someoneTweet about this on TwitterShare on Google+Share on LinkedInShare on Reddit