[Bug] Loading libraries is not optimised

[Jme797]

Description

Libraries are loaded in the API Provider in a for loop and then on resolution of each library set into state. This causes lots of re-renders of all children of the API Provider to be updated several times when the components are first loaded.

The way the map instances are created are also fairly unpereformant, the API Contect tracks map instances in state, and the state is set from inside the Map component as it loads forcing multiple renders for that also every time, and it causes the whole tree to re render.

All of these thing also happen in isolation in different hooks used inside the API Context which means in total there is quite a few renders by the time everything is loaded and things stop getting set into state.

There is also hooks that allow a similar flow to the Map state management which allows you to render a new library in a child of the API context which then sets the new library into state in the ApiProvider also causing multiple re renders on loading of new libraries in children.

Would probably be a good idea to rethink the way the way the API Context provider is structured, possible making use of Promises.all() or simliar methods to wait on mutliple asynchronus requests to complete at the same time, Loading libraries directly at the time of creating the Context or storing them / sharing them in a different way because the performance problems means that you can't really wrap that provider around a full page and make use of multiple libraries under one provider.

Steps to Reproduce

Create a blank react app and add the package. Create a basic page Render a basic map Add a console.log('render') to the blank page in a subcomponent wrapped by the context provided. See lots of renders.

Environment

• Library version:
• Google maps version: weekly
• Browser and Version:
• OS:

Logs

No response

[usefulthink]

This is bringing up some excellent points. I will have to think about this for a bit and see what we can do to reduce the number of state-transitions during loading.

[Jme797]

This is bringing up some excellent points. I will have to think about this for a bit and see what we can do to reduce the number of state-transitions during loading.

I'd be happy to suggest some things but it would depend on what the reasons where that lead to this structure as to how to fix it.

There's some useful hooks in newer versions of react as well that are helpful in reducing state updates on a component tree if that is an option without causing new issues with compatibility with older versions.