Named Entity Map Mode

[paltman]

What's in this PR?

Refactor reader mode composition

• Refactor Readers using ApolloQuery component
• Each reader component handles its own query

Map component changes

• Add SelectableEntityMap (disabled until we fix a bug with sync between map and named entities widget)
• Refactor Mapbox components for reuse with NamedEntitiesModeReader

Other improvements

• Retrieve the current urn value from the store (leverages vuex-router-sync)
• Refactor map config using $scaife.config pattern Previous description

[paltman]

Render all visible places within a passage on a map

[jacobwegner]

@paltman when you're able, could you please resolve merge conflicts again? I just did a few merges to develop this morning

[paltman]

Backport folio mode improvements to map mode

[paltman]

Synchronize named entity selection with the map

[paltman]

Restore error handlers

[jacobwegner]

@paltman Looking at how you've introduced ApolloQuery here, I'm wondering about an alternate approach to build up the "display mode" components.

Thinking from a Django perspective, I might have a BaseReaderView and override something in get_queryset to return data, and then a base_reader.html template that handles things like pagination controls, error messages, etc with a {% block reader_content %} for customizing the actual content displayed in a given mode.

In the current implementation, ApolloQuery that does serve sort of like a base_reader.html template, but then we have to read through else-if conditionals to know which content is to be loaded:

• folioMode
• alignmentsMode
• namedEntitiesMode
• default

And then we jump into ImageModeReader to view the template.

If we want to tweak a particular query, we've got to hop over to queries.jsto tweak.

Instead, what if we were to:

• Move the passage metadata (to drive the paginator) out to its own query (which could live in ReaderWidget)
• Used a dynamic component based on display mode
  • Each mode's component could use ApolloQuery to handle loading / empty / shown data states
  • The query could live inline with the component

e.g.

<Paginator :urn="data && data.previous" direction="left" />

<component :is="displayModeWidget" />

<Paginator :urn="data && data.next" direction="right" />

...

computed: {
  displayModeWidget(){ 
    if (this.imageMode) {
      return ImageDisplayModeReader
    }
    ...
  }
  ...
}

ReaderWidget is used to dispatch that displayModeWidget component, but the query and rendering are all the responsibility of the "child".

What do you think?

[jacobwegner]

(and to be clear, I’m discussing an alternate approach, not requesting we have to change the implementation on this branch)

[jacobwegner]

(and to be clear, I’m discussing an alternate approach, not requesting we have to change the implementation on this branch)