Create the default editor content area

[antw]

The play page layout (#28) adds support for displaying the header, scenario nav, sidebar, and loading an empty content area. For visitors to modify and visualise their scenario, we must now implement the default content area.

While it is likely we'll support several different content areas later (such as introduction pages, full-page charts, infographics, or reports), we'll start by reimplementing the layout used by the ETM, hereafter called "the editor". This consists of the accordion and sliders on the left, and one or more charts on the right.

Components and features

Routing

We must expand on the routing behaviour added in #28, by allowing the final path segment to control the currently-active accordion item:

• When a visitor arrives at "/scenario/demand/households/insulation" the play page will know to load the editor. The editor must know to open the "Insulation" accordion item.
• When a visitor arrives at "/scenario/demand", the editor must open the first accordion item and update the route to reflect the change (if possible, we should use replaceState rather than pushState, since going back to "/scenario/demand" makes no sense).
• When the visitor opens a different accordion item, the item should open and the route should be updated.

Accordion

A Play/Accordion component is needed whose content is determined by the routing information. The accordion should load with one or more AccordionItems, with the correct item opened automatically based on the current route state.

Opening a different item in the accordion should update the active route. For example, opening the "Solar panels" item updates the active route to /scenario/demand/households/solar-panels. We may update the route in the store directly, or the accordion header may behave more like a Link which triggers a route change, and the accordion updates automatically.

AccordionItem paraphernalia

Inside accordion items ("slides"), we usually have sliders representing the state of inputs. We also need some additional behaviour:

• An optional description text with optional image.

• An InputHeader component which allows us to split inputs, with a header message and optional unit:

  

• Perhaps a SliderGroup component which wraps multiple inputs with an InputHeader:

  function SliderGroup({ children, title, unit }) {
    render (
      <>
        <InputHeader title={title} unit={unit} />
        {children}
      </>
    );
  )

Charts

The charts shown on the right-hand of the page are determined

ChartWrapper

Charts are contained inside a wrapper. This wrapper also provides access to other features:

• Show the chart description
• Allow the user to "pin" (lock) the chart so that it isn't replaced with a default chart when navigating to a different section, and persists when reloading the page.
• Download the charts as an image.
• Show a table view, when supported.
• Zoom the chart.

We must create an equivalent of this wrapper.

Tasks

• Play/Accordion component: Build on top of the generic Accordion (which already exists)
• Play/AccordionItem component: These contain the items for the accordion. For example "Population & housing stock" and "Insulation" in the "Household energy demand" section.
• SliderGroup component: Combines multiple sliders inside a composite component, showing a header and optional label above them.
• Routing: Changes in the accordion must be reflected in the active route, and vice-versa.
• ChartWrapper component: provides the chrome around a chart, such as the button to show the description, pin the chart, zoom, etc.
• State persistence: the locked chart list state must be sent to the server, ensuring it persists through page reloads (see Create the main "Play" layout #28).