[Feat] Add support for InfoWindow headerContent / headerDisabled options

[usefulthink]

Target Use Case

Currently in beta in the Maps JavaScript API, there will be new options for the InfoWindow, finally allowing users to disable the header including the close-button and to specify separate html for the header of the infowindow. These should be supported here as well.

Proposal

Add new props headerContent and headerDisabled for the InfoWindow component. While headerDisabled is just a boolean, headerContent can be arbitrary html, so we should support that via a render-callback, rendering the content into a portal.

[amanusovich]

Hi,

I noticed this feature is already affecting the components provided here.

This is affecting the styling of the component, specially when its content is short. Providing this functionality would really help.

Thank you!

[usefulthink]

Currently this only happens with the beta version of the maps API, so we still have a bit of time..

[amanusovich]

Actually I am working with the API in the weekly version. I changed it to monthly to get the older version.

Thanks!

[usefulthink]

This already made it to weekly?
Thanks for pointing this out, that indeed changes the priority a bit :)

[chrissygonzalez]

Hello! I'd also like to vote for a little customization. 🙏 Thanks!

[kamaladenalhomsi]

Same here!! I think this is extremely important!
Not related to the issue, I want to thank the maintainers of this awesome library! Thank you for your hard work.

[kamaladenalhomsi]

For anyone facing this, you can temporary fix the empty space at the top using css:

.gm-style-iw-chr {
  position: absolute;
  display: flex;
  top: 0;
  right: 0;
}

.gm-style-iw.gm-style-iw-c {
  padding-top: 14px !important;
}

[usefulthink]

The headerDisabled flag should actually work out of the box since it should get passed on to the google.maps.InfoWindow constructor and the infowindow.setOptions() method. When using typescript you'll have to have the latest @types/google.maps installed.

As for headerContent, which API-style would be preferrable?

Option 1: Render callback ({headerContent: React.ComponentType})

<InfoWindow headerContent={() => <h3>InfoWindow Headline</h3>}></InfoWindow>
<InfoWindow headerContent={() => <>Just some text</>}></InfoWindow>

<InfoWindow headerContent={MyInfoWindowHeader}></InfoWindow>

Option 2: JSX ({headerContent: React.ReactNode})

<InfoWindow headerContent={<h3>InfoWindow Headline</h3>}></InfoWindow>
<InfoWindow headerContent={<MyInfoWindowHeader />}></InfoWindow>

Option 3: Special Child Component

<InfoWindow>
  <InfoWindowHeader><h3>InfoWindow Headline</h3></InfoWindowHeader>
  
  <p>Infowindow Content</p>
</InfoWindow>

I think I would prefer the second or third option for this. The second option seems to be what other UI libraries are using in similar situations, any opinions here?

[chrissygonzalez]

I like option 2, given that headerDisabled will be available. (At first I though option 3 was more intuitive, but you could end up in an odd situation if you set headerDisabled={true} and then also provided some header content.)

[usefulthink]

I'm mostly sceptical about option 3 since that would involve some sort of accessing portals within (or out of?) portals, and I have no Idea if that causes problems, but It's complicated to just think about. I'd be willing to figure it out if majority says that's the better solution, but we'll see...