Add another component to load the GMaps JS.

[miracle2k]

This is my approach to solve #281 - letting the library load the Google Maps JavaScript file for me when I need it but still being able to access the google namespace. This is inspired by how react-motion uses a single-function child.

It's also nice to use this with the decorator, from my project:

 @loadGoogleMaps({
     hostname: "maps.googleapis.com",
     pathname: "/maps/api/js",
     query: { key: "", libraries: "places" },
     passIsLoadingProp: true
 })
 class PositionSelector extends Component {
 }

[tomchentw]

I like the HOC idea, but since the decoratedComponent will only be created/rendered after google is loaded, why not just access google object then?

[miracle2k]

Maybe I misunderstand the question; the problem I wanted to solve was that the existing ScriptJsLoader requires the whole google maps component tree to be specified inside a single invokation of render() This means it's not possible to access constants from Google like say google.maps.ControlPosition.TOP_CENTER as part of the map definition.

So the idea here is to provide some utility to have the google maps script tag be loaded for us while delaying the component construction until it is loaded.

[tomchentw]

@miracle2k yes, and I imagine an HOC can help us avoid this issue. Sample code:

function ScriptjsHOC(WrappedComponent) {
  return class extends React.Component {
    // some load logic
    render() {
      if (this.state.isLoaded) { return <WrappedComponent {...props } /> } else { return null; }
    }
  }
}

and use it like:

const MyMap = (props) => {
  return (
    <GoogleMapLoader………
  );
}

export default ScriptjsHOC(MyMap)

So the user will use the decorated component, and render null first because it's not isLoaded, then when we have google in global, render the actual <MyMap />

[miracle2k]

You mean that when used as a decorator, the child-as-function thing is not necessary? Yes, you're right. The child-as-function is only necessary if you want to have the and the components created in the same parent's render(). If you don't intend to support that, we can avoid this part, and maybe only go with a decorator.

[tomchentw]

@miracle2k I believe decorators/HOCs are the right way to go.

[tomchentw]

@miracle2k Are you willing to update your PR to use decorators? :)

[tomchentw]

We'll provide a HOC approach in 6.0.0. Follows up #318 !