add <h3-worldmap-demo> <h3-worldmap-projection-select>

[rudifa]

• add <h3-worldmap-demo> <h3-worldmap-projection-select>
• display <h3-worldmap-demo> in dev/index.html

TODO

• revise the file/folder structure
• revise the responsibilities of components
• revise names of components, properties, e.t.c.
• revise communication between components
• tidy up

[olange]

• revise the file/folder structure

src/demo/h3-worldmap-demo.js ⟶ dev/h3-worldmap-demo.js
src/demo/h3-worldmap-projection-select.js ⟶ h3-worldmap-projection-select.js

• revise the responsibilities of components

H3WorldmapProjectionSelect should present the list of the D3-geo projections that we support — that is, wrap the logic of setting up the ‹select› element (this setup should not be delegated to its consumer H3WorldmapDemo).

• revise names of components, properties, e.t.c.

In H3WorldmapProjectionSelect, I believe the eventidproperty should go — see comment hereafter.

Also <label>${this.label}</label> should have a for="id-select" attribut — that is, <label for="id-select">${this.label}</label>.

• revise communication between components

In H3WorldmapDemo, the setup of the listener should be delegated to Lit, that is, use the @change=this.updateProjection directive. This change effectively removes the need for an eventid property on the H3WorldmapProjectionSelect component.

A sidenote: a listener should not be added at construction time by a custom element, it is too early; and not to the window object (but this is only a solution to this problem — it is too early). The listener should be added to the custom element itself, when it gets connected to the DOM (connectedCallback).

By the way, I realized that when I have to do this, it is often worth considering to use a ReactiveController, which exposes a hostConnected interface for such purpose.

• tidy up

I think we should revise the naming and may be setup of projectionOptions in h3-worldmap-demo.js: I found the intent of Object.fromEntries( [...someMap.entries()]).map(…somethingHappensHereButWhat…)) unclear; moreover, I had to lookup the MDN docs to understand why the Object.fromEntries( [...someMap.entries()]) pattern, only to remember that the Map object was missing a .map() method is JS (which is a separate problem). But the (entry) => { return [entry[0], entry[1].name]; } should definitively be more explicit.

[rudifa]

Preliminary notes by @rudifa:

• revise the file/folder structure:
  [] will do as suggested, makes sense

• revise the responsibilities of components
  So, we shall have the 2 components exported by the package, H3Worldmap and
  H3WorldmapProjectionSelect; the H3WorldmapDemo will show one way to hook up these 2 components

• revise names of components, properties, e.t.c.
  So, eventId should be a fixed constant inside H3WorldmapProjectionSelect , right?
  The label text could also be a fixed constant inside H3WorldmapProjectionSelect , right?

• revise communication between components
  TBD - I need to understand / try out the suggested mechanism

• tidy up
  TBD - simplify the use of AVAILABLE_PROJECTIONS, clarify naming
  For example, this might be a little clearer

/**
 * import AVAILABLE_PROJECTIONS and convert it to an object like this:
 *  {
 *    conicEqualArea: 'Conic Equal-Area',
      ...
 *    mercator: 'Mercator',
 *  }
 */
const projectionOptions = Object.fromEntries(
  [...AVAILABLE_PROJECTIONS.entries()].map(([projId, projProps]) => {
    return [projId, projProps.name];
  })
);

NOTE 02.05 OL to clarify without adding comments, I would add small functions and find names for every step, for instance:

function arrayOf( map) { return [...map.entries()]; }
function projName( projDefObj) { return projDefObj.name; }

const projectionOptions = Object.fromEntries(
  arrayOf( AVAILABLE_PROJECTIONS).map(
    [key, projDefObj] => [key, projName( projDefObj)]);

Still, the reason for the projective transform remains obscure, because one would probably expect AVAILABLE_PROJECTIONS.entries() to be sufficient to iterate over; and to simply handle the extraction on the spot, while rendering. We should state why do we transforms to get an updated object IMO — one reason might be performance, so to do the transform once for all, because the list of available projections is currently static; but we'll still need to iterate over that transformed list to render it, so what would be the expected outcome?

[olange]

The more I consider the form of our list of available D3 geo projections, the more questions pop up.

Considerations:

• why do we need an identifier in first place, to pick a projection in the projection attribute of our ‹h3-worldmap› element? There is no standard nomenclature for such identifiers in D3-geo;
• we need a human representation of the projection name for the selector;
• the only mapping we have at hand, between D3-geo projection builder functions and names, is the one @Fil defined in a cell in a @d3/projection-comparison Observable notebook
• we need to maintain both the list of available projections and their human-readable names by hand — not even to mention the issue of i18n (translations of those names).

Questions:

• why wouldn't we simply use the human readable name as our projection attribute possible value?
• or instead, could/should we use the function names themselves?
• can we/shouldn't we introspect the d3-geo library to find the list of available projection builder functions? (they miss an interface, they're plain functions as I see)

I guess this comment is a good candidate for a new conversation ⟶ UPDATE 02.05 I opened a conversion topic in #31

[rudifa]

I have now a branch, add-h3-worldmap-demo-3 that implements all (I think) of improvements discussed in the 'revise' series above.

This branch is rebased on today's main c937564 (upstream/main, origin/main, origin/HEAD, main)(2022-05-02 11:13:20 +0200)(GitHub).

The corresponding PR#29 replaces PR#25.

h3-worldmap % git lg 5                                                                                                    [add-h3-worldmap-demo-3 L|✔]
* 1ee0dae (HEAD -> add-h3-worldmap-demo-3)(2022-05-02 13:45:34 +0200)(Rudi Farkas)h3-worldmap-projection-select: rename event to update-selected, simpify event dispatch; move in the import AVAILABLE_PROJECTIONS and its use from h3-worldmap-demo
* 769c9f7(2022-05-02 13:45:34 +0200)(Rudi Farkas)move  src/demo/h3-worldmap-demo.js -> dev/h3-worldmap-demo.js, src/demo/h3-worldmap-projection-select.js -> h3-worldmap-projection-select.js, update dev/index.html
* 14c9a32(2022-05-02 13:45:34 +0200)(Rudi Farkas)add <h3-worldmap-demo> <h3-worldmap-projection-select>, display in dev/index.html
* 0ed0363(2022-05-02 13:45:34 +0200)(Rudi Farkas).gitignore: add .DS_store
*   c937564 (upstream/main, origin/main, origin/HEAD, main)(2022-05-02 11:13:20 +0200)(GitHub)Adds `firstLayout()` lifecycle method and calls `_measureSVGElement()`
|\  

---

@olange "I guess this comment is a good candidate for a new conversation." - I agree, I looked yesterday a little at the d3 code and I also saw a long series of declarations ... we could grab the file and parse it.

Here is one list, Projection Comparison by Mike Bostock.

[rudifa]

Here we go

• cherry-picked 2 commits (my work of this morning) on top of your commit 0ff599a
• merged main into branch add-h3-worldmap-demo
  @olange please review and test, and forget the PR#29, une entité de trop

Entia non sunt multiplicanda praeter necessitatem