Animations in ReactJS

ReactJS, on its own, does not have a way to track component state over the life of an entire site visit. Every time the cube rendered, React would behave as if the site visitor had just arrived to the site, even when this was not the case. For example, if a user lands on the home page then they would see the glory of the Logo Cube being rendered. But if they navigated to a different page on the site and then later returned to the home page then they’d see the entire rendering of the cube once again, and again and again and again. This looked amateurish.

Solution: Enter Redux. I solved the amnesia problem by using Redux to keep track of whether or not the cube had been rendered. The basic pattern is to set a boolean variable, “isSet”, to true when the logo component is about to unmount, and then to use this boolean variable to decide whether to include the intermediate animation class when rendering the cube. Redux is easy is implement, once you get used to it.

See: Managing your React state with Redux, by Onsen UI & Monaca Team

React mounts/unmounts components multiple times, often for reasons that are external to your component. React also potentially calls render() more than once during normal component initialization. Both of these are problematic for CSS animations because invoking render() will kill and restart any animations that were in-progress at the moment of invocation, causing screen flicker which looks terrible.

solution: It turned out that in the case of the logo cube, ReactJS was mounting / un-mounting the logo cube component around 12 times. Most of these rendering cycles were caused by the way that I initialize Redux for various REST apis; none of which are related to the logo cube. I made creative use of the component lifecycle method shouldComponentUpdate() in the module where my Redux initializations where located to eliminate nearly all of the superfluous mount cycles. After this fine tuning ReactJS now mounts the logo cube component exactly two times in the span of a few milliseconds, which however is still enough to cause some noticeable screen flicker. I eliminated this remaining flicker by launching the component’s painter() method on a timer delay of around 100ms. The painter() methods is responsible for setting the background image URLs on the sides of the cube. Noting that ReactJS invokes render() each time painter() changes a background-image setting, this delay timer defers rendering of the cube until React has had enough time to finish fully mounting the logo cube component.

Launching the painter() method with a timer delay introduces some new complications however. The timer itself is actually an entirely new thread which runs asynchronously and therefore is not governed by the lifecycle methods of the components from which it was invoked. In my case this led to the logo cube component creating one such thread each time the component mounted, and recall that during much of development the component was mounting around 12 times. That in turn meant that at run time there were around a dozen asynchronous processes making random updates to the cube side background-image properties, which was complete anarchy!

solution: I fixed the threading issue by keeping track of, and explicitly killing all background threads that I create.

    componentDidMount() {
        //  create a time delay to launch repaint()
        const self = this;
        const myTimeout = setTimeout(function() {
            self.repaint();
        }, 100);    
        this.setState({
            repaintDelay: myTimeout
        });

    }

    componentWillUnmount() {
        // kill any pending background threads that were
        // invoked in componentDidMount().
        clearTimeout(this.state.repaintDelay);
    }