React-big-calendar: Work in Strict Mode to avoid hitting a wall in upcoming React versions

[tdd]

Do you want to request a _feature_ or report a _bug_?

It's a feature of sorts, more like making sure we can still use this by the end of 2019…

What's the current behavior?

Rendering a calendar inside React’s <StrictMode> wrappers yields a ton of deprecation / unsafe pattern warnings in the console:

• Deprecated findDOMNode() usage (the modern Refs API should be used instead)
• Unsafe lifecyle methods (typically componentWillMount() and componentWillUpdate())

What's the expected behavior?

The codebase should try and move to the newer, cleaner, safer accepted ways to achieve the same results, in order not to find itself stonewalled when some upcoming React 16.x version finally strips these, some of which have long been deprecated.

My OSS/PR queue is already quite full for the next few weeks but I might try and give it a go around late Feb / March if the regular maintainers can't.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[justingrant]

Shouldn't be closed. This should be fixed before findDOMNode is removed from React.

[lgdelacruz92]

Yea, is it possible to update? Otherwise it will only be usable for people with some version of react and below.

[niccai]

Yes, please reopen this issue.

[jquense]

Happy to take a PR!

[avindra]

Please re-open this issue.

This will become a major blocker with a new React release. Probably 17.

https://reactjs.org/docs/concurrent-mode-adoption.html#feature-comparison

[justingrant]

FWIW, I've moved away from using react-big-calendar, partially for this reason.

[avindra]

@justingrant is there another open source project that you've moved towards? For those of us who also want to be proactive instead of waiting indefinitely for removal of findDOMNode and other hacks that were clearly documented as things to avoid.

[justingrant]

Hi @avindra - Nope, I ended up rolling my own plain-JSX solution. My own implementation is limited and lacks most RBC features, but my app has pretty limited needs so it's good enough for now. I may consider switching back to RBC later but for now I've moved on.