Remove unsafe lifecycle methods (WIP)

[tstirrat15]

Fixes #848

Motivation

The UNSAFE methods are going to be deprecated, and can't be used if you want to use fancy prerelease React features. This refactors away from those methods.

Changes

• Migrate UNSAFE_componentWillReceiveProps to componentDidUpdate
• Migrate UNSAFE_componentWillMount to componentDidMount

Discussion

On the methods

willMount and didMount should be directly interchangeable for the purposes of this library. All of the behavior in these methods is around setting up event handlers and interacting with the map, and given that there is minimal rendered state in the components, it shouldn't be a problem to render once, run didMount, and set up the handlers post-mount.

willReceiveProps doesn't have a direct analogue in the non-deprecated lifecycles. If you're setting state in willReceiveProps, it's typically getDerivedStateFromProps that's used, but that doesn't happen often in this library.

This library uses willReceiveProps most often to do side-effecty logic, which under the new paradigm is done in didUpdate. The big difference between didUpdate and willReceiveProps is that didUpdate runs on mount, and there isn't a way to tell it not to run on mount.

This is why I rewrote the tests as extensively as I did - they were implicitly depending on willReceiveProps not being called after mount. I'm not particularly happy with injecting mapInstance, but I didn't have any other ways of doing it off the top of my head. I'm happy for feedback there.

The skipped tests

One is for scale-control, and I can't figure out what's wrong with it. It complains about clientWidth being undefined, despite that if you console.log out map._canvas it shows an object with a key of clientWidth. Not really sure what's going on here.

The other is for center being calculated when fitBounds is provided without center, which is an onMount behavior that only makes sense if Map is undefined.

I suppose it might be possible to keep adding things to the old mockMap until test pass. If the mapInstance approach isn't desired I'll explore that.

On my methods

I've never used typescript before. I'm sure I mangled at least a few things - please point them out.

TODO

• Rewrite remaining skipped tests to work
• Verify that end behavior is correct by messing around with the demo

[curran]

👋 Just wanted to say I support this work and thank you for doing it.

I encountered this error just today and was considering abandoning use of this library in favor of direct Mapbox, and this PR made me stay.

Looking forward to seeing this merged. Any assistance required?

[tstirrat15]

Mostly getting attention from the maintainers so that we can figure out a path towards merge.

If you're interested in writing some code, I couldn't figure out why the scale-control tests were failing. I'd love some help making sense of it.

[landworth]

I'm not too familiar with the codebase, but will try to take a look and see if I can figure anything out..
@alex3165 any chance of a little PR love here?

[tstirrat15]

@mklopets too

[alex3165]

Hello, i should have some time to look into react-mapbox-gl in the coming months, i will look into this as a priority. Thanks

[alex3165]

Merged as part of #899, will add a few more and do a react-mapbox-gl release great work @tstirrat15

[curran]

Hooray!