Provide bidirectional navigation between explorations and base tables

[seancolsen]

Current behavior

• Each exploration has one and only one base table
• From various pages associated with the exploration, there is no way to navigate directly to the table page for the base table. Instead I need to use the top navigation bar to manually find the table.
• There is no way to see all the explorations which have a given table as their base table.
• Navigating from a table page to a related exploration requires some knowledge of the way in which specific explorations have been constructed. Then I need to find the exploration by name in order to navigate to it.

Desired behavior

• The various exploration pages should provide a means to navigate directly to the table page for the base table.
• The table page should provide a means to navigate to all the explorations which have that table as their base table

Design work

• Find a place within the table page to displays links to the explorations for that table.
• Find a place within the exploration pages to link to the table page for the base table.

[ghislaineguerin]

Here's a representation of how the exploration menu should be positioned and what its contents should be.

For unsaved explorations. Once a base table is selected the table name becomes a link:

When saved, the base table information is available next to the Exploration's name:

[seancolsen]

Thanks for those mockups, @ghislaineguerin.

I'll add some additional text to specify behavior to the person who ends up implementing this.

Let me know if you have any concerns with the following behavior, @ghislaineguerin

• The "Explorations" dropdown (on the Table Page) should behave as follows:

  • It should follow the same behavior as "Filter", "Sort", and "Group" when the viewport gets narrow. At a certain breakpoint, the text within the button should disappear, leaving only the icon.

    Whoever implements this should play around with the responsive behavior to see if we might want to adjust this breakpoint. Make sure to test when this "All Changes Saved" status messages is included in that top bar too:

    

  • Filtering should work the same way as in the navigation header breadcrumb selectors — the number of matches should be displayed and the matching results should highlight the matching substrings.

    

    We ought to be able to re-use code for this. Some refactoring may be necessary to make that happen in a clean way.

  • The dropdown content should be positioned with respect to the dropdown trigger just as breadcrumb selectors are. Content should be below it if possible, but aside it if necessary.

    2023-11-17_08-14-35.mp4

  • When there are too many explorations for the dropdown menu to fit entirely within the viewport, the list of explorations should scroll vertically. The list should not be paginated. When scrolling vertically, the "Create New Exploration" button should remain fixed at the bottom of the dropdown content so that it is always visible.

  • The dropdown content should have a sensible max width and any explorations with very long names should be truncated using the Truncate component.

• The "Explorations" dropdown should only be present on the Table Page. It should not be present in the "table widget" that is embedded in the Record Page. (I mention this because that table widget also contains a similar Filter/Sort/Group UI).

• On the exploration pages, then links to the table page should be hyperlinks without any "target" attribute.

[ghislaineguerin]

Thanks @seancolsen just one more note: The save status should not displace the explorations dropdown; it should be displayed to its right.