One common optimization is to strategically use shouldComponentUpdate to limit the number of components that render each time the state changes. In this case you could create a Month component which renders a single <tr> element. This component would then implement shouldComponentUpdate to check if the state used to render that month has changed. If not, shouldComponentUpdate returns false and the month does not re-render. This means that clicking on a Day should re-render two Months at most.

The same shouldComponentUpdate optimization could be added to both Calendar and Day, but in this case clicking a Day would always require the Calendar to re-render, and running through 365 shouldComponentUpdate functions (returning false from at least 363 of them) without first limiting by Month would not be ideal.

If the state is managed with ImmutableJS or a similar library, shouldComponentUpdate would only have to do a single reference equality check. Either way you should see a big improvement from any implementation that allows the individual Month components to skip rendering:

http://facebook.github.io/react/docs/advanced-performance.ht...

Cacheing? You're doing a lot of work in render that could be computed once. Try saving a few years +/- into state on componentDidMount. And for day clicks, pull rows that arn't touched from the cache.

Things would also be significantly sped up if you compiled in production mode. From looking at your source, all the dev mode checks are still being performed. See:

https://facebook.github.io/react/downloads.html (the note under npm section)

https://github.com/facebook/react/issues/1772

http://stackoverflow.com/questions/22118915/how-to-turn-on-o...

Delay is 50ms on my MBP. Here is a profile: http://i.imgur.com/ty11Utl.png

With the main bottleneck being here: https://github.com/BelkaLab/react-yearly-calendar/blob/maste...

Implementing a good shouldComponentUpdate() should fix it.