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);
    }

Like most animations, this one depends on a set of static assets that have to be delivered to the browser from multiple sources. The automation code — React/Javascript in this case — then assembles the static assets into a delightful on-screen presentation. Unless that is, some of these assets are missing in action, in which case, your automation looks broken or poorly designed. The logo cube suffered from this problem, and I spent an enormous amount of time meticulously story-boarding and choreographing the arrival of the static assets so that the animation rendered smoothly for “normal” Internet connectivity.

The cube sides are rendered by CSS, which renders quickly and smoothly on all browsers. But, the nature of the problem is that the cube side background-image properties depend on a collection of around 75 logo images; the URLs of which are provided by a REST API. I have to request this, then wait indefinitely, then parse the URLs, and then only afterward can I begin to download and paint the cube sides with these images.  On a slow internet connection you would initially see a bare-naked cube for several seconds, and then afterwards you could see each new logo downloading on the cube side, which looked terrible.

What I describe here as the “slow-loading logo problem” really gets to the heart of the challenge of creating sophisticated animations in React. Slow-loading logos are a big problem that requires a multi-prong solution. Note that the long list of logos is a design requirement: I want to show site visitors a huge list of technologies. Furthermore, the logos need to be high quality, and, they need transparent backgrounds. Following is how I solved this for the logo cube.

Solution:

1. I store the first six logos locally so that these are included in the React bundles and are delivered to the browser immediately, before the logo cube begins to render.
2. I created an image pre-fetcher inside of Redux that downloads each logo as soon as the REST api returns with the image URLs.
3. I employ some sleight of hand: the 1-second animation of the cube being rendered resolves itself to an in-motion cube (covered with the six preloaded logos) that is visually satisfying for around three or four seconds. This buys time for React to do the remainder of its work to query the URL list from the REST api and preload the other logo images.
4. I web-optimized all logo files to decrease data transfer. In my case I only needed to reduce the file size to match that of the logo cube sides.
5. I make AWS Cloudfront gzip all of the images, further reducing data transfer by an additional 30% or so.

I had trouble visually tracking the motion of the original version of the cube’s spinning animations.
The cube would sometimes appear to be spinning left-to-right, and other times right-to-left. In
the latter cases the cube appeared mal-constructed and disfigured. Here’s a technical explanation
of the nature of this problem: wikipedia.org/Wagon-wheel_effect

solution:
First, i tinkered with the opacity of the cube sides so that the side that is supposed to be in front is brighter,
and the reverse side is darker. Secondly, adding the cube rendering helped a lot because the cube begins
as a 2-dimensional spinning square, which afterwards grows to become a cube. The 2D spinning image is easier for your
visual cortex to process, and the growth animation provides a way for your mind to bootstrap and retain what’s
happening on-screen.

The logo cube is supposed to be a creative way of showcasing my most important technology skills to site visitors. However, most visitors will only see the cube for a couple of seconds and then move on to some other page. Thus, a random selection of logos works at cross purposes to this design objective since most of the logos pertain to lesser-known supporting technologies.

solution: I select six “featured” logos with maximum impact to use when initializing the cube. Their placement on cube sides remains randomized so that, to the casual eye at least, the cube seems to be different each time the page reloads.

It bothered me that sometimes all six cube sides would display only the logos of unimpressive technologies for an extended period of time. I found myself staring at the cube anxiously waiting for a “good” logo to appear.

Solution: I reserve one of the six cube sides to use exclusively for presenting the six featured logos, in random order. This ensure that an impactful technology is being presented at all times.

It bothered me that the same logo would sometimes appears on two (or more) sides.

Solution: I added some “no collision” logic to prevent the random logo selector from choosing any logos that are currently being displayed.

Logos change at random intervals. However, it looks bad if a logo is replaced too quickly. That is, a certain amount of randomness in the presentation of the logos keeps the animation fresh and interesting. But too much randomness creates visual tension and unease. We want to maximize the former while minimizing the latter.

Solution: I added 6 timers to track the elapsed lifetime of each logo, and then I only replace a logo if its been visible for a minimum length of time.