Map: Add filters for format, type, month, country

[iandunn]

See https://www.figma.com/file/jdMk5ssz2Av7KFfEaeK7de/Events?type=design&node-id=1213-21115&mode=dev

[iandunn]

@StevenDufresne here's a rough sketch of how I see filters working. It's a bit hacky to integrate the query-filters block, though, because that is rendered in PHP and the map block is rendered in React. query-filters is also built to use WP posts, and the map block uses arbitrary data.

I think it could work with some effort, but I'm curious if you see a better way or have any other thoughts.

[iandunn]

I'm not seeing a good way to do this. If react renders into wporg-google-map-container then it'll wipe out the filters. In order to hydrate instead of render, the server markup would have to match the react markup. Subgrid support isn't good enough yet.

I could do something hacky, like using JS to save the innerHTML content to a variable, set display:none, then use <RawHTML> (dangerouslySetInnerHTML) to render it inside the react container. It feels like there should be a better way, though

[iandunn]

I also thought about refactoring so that each React component is independent. So, the server would generate something like this:

<div id="container">
	<div id="map"></div>
	<div id="search"></div>

	<div id="filters">
		<?php echo do_blocks( <!-- wp:wporg/query-filter ... --> ); ?>
	</div>

	<div id="list"></div>
</div>

...then call createRoot() for map, search, and list seperately. The problem there is that there needs to be a Main component managing the state for those subcomponents.

Another idea might be to basically re-create the InnerBlocks / ServerSideRender concept, and grab the query-filter content via a REST API request, then render the result into the DOM. That's similar to the hacky idea about about grabbing the InnerHTML, though 🤷🏻‍♂️

[StevenDufresne]

Alright, I spent some time looking at these pieces today. I have a theory of what can work, but haven't tried it.

I think you can get the query filter state by hooking into the interactivity API store. Take a read through the doc to understand more how it works.

In the events.wordpress.org UI it doesn't appear like the search needs to update the map. It would actually be weird to update something below it and have it change up there so to speak. So can we avoid using the map component for the list of events and just do it with another component and make it behave more like WordPress and a post query? Allow it to post-back, intercept the query server-side, replace it with an events-specific query results, and reload the page?

If we want have the postback-less interactivity, I would suggest we still make our own list component that uses the interactivity API and therefore will work nicely with the QueryFilters (with some slight modifications I think).

The last approach would be to try and access the interactivity API store, like store.wporg.queryFilters (it may not be available because its declared via wp-context which is a local state) and create a wrapper component in wporg-events-2023 that reacts to changes in the property and re-renders the new list component or in this case, we could probably re-use the google map block in list-mode.

Reference from the proposal doc:

State: Defines data available to the HTML nodes of the page. It is important to differentiate between two ways to define the data:
Global state: It is defined using the store() function, and the data is available to all the HTML nodes of the page.
Context/Local State: It is defined using the data-wp-context directive in an HTML node, and the data is available to that HTML node and its children

[iandunn]

Closing in favor of WordPress/wordcamp.org#1124