npm package: @strategies/visualizer.core
Description: Visualizer core library.
Author: Ken Goulding
Latest version: 0.1.0

# visualizer.core

the core interfaces, components and utilities for creating a visualizer application. These applications let you synchronize color mapping, selection and filtering across a number of visualizations such as charts and colorizers/maps.

The goal of this platform is to keep things modular (elements may be composable into other loosely-related applications) but also to provide enough structure to take advantage of connecting different visualizations and charts.

Centralized data is loaded in, states are computed for the data to be represented in charts and viewers. To help unpack the data and make sense of it, the same visualization elements can also be used to manipulate the active state of the data via hover-highlighting, selection and filtering. 

## [Viewers](..%2Fviewers)
All viewers implement IViewer and handle:
- Updating a view:
  - Display element color
  - Display element selected state
  - Display only non-hidden elements
  - Show elements as 'filtered out' / 'not-hovered'
- Allowing selection of elements
- Providing hover events for elements
- Providing x/y coordinates for overlay elements

Viewers can be used within the primary visualizer interface - or used in Dashi or other tools that require this functionality. Multiple viewers can be used within the same application and may be shown on screen simultaneously.

## [Data-Munging](..%2Fdata-munging)
Data is loaded centrally into mobx stores and used to derive state for the views. Data entities can be derived from a variety of sources and can contain calculated fields specific to the business case for a given application. 

To use data in specific viewer implementations, a Formatter may be used to derive specialized computed states specific to that viewer. Each element has a 'formatters' dictionary containing the formatter instances for each viewer type. Observability flows through these formatters.

## [Color-Mappings](..%2Fcolor-mappings)
The color mapping UI provides an intuitive way for users to map colors onto the viewers. Numerical data can be ramped or classified into ranges, while categorical data can be 'tagged' with colors.

## Overlays
Overlays are 2D elements that can be super-imposed onto viewers in order to show data in a different format such as pie charts. To support overlays each viewer simply has to return x/y coordinates for given entity IDs.

## Tooltips
Tooltips show data on mouse-over and can include the current color info as well as custom controls (such as a photo viewer for classrooms). The user choose to view this information near the mouse position or within a panel.

## Charts
Charts can represent data at a 1:1 level (like Continuity charts) - or as aggregate data (bars, pies, area charts). Charts are expected to provide a filter predicate for any hover state that can help visualize how that hovered element connects to the other charts and viewers.

new repo for visualizers

@strategies/visualizer
  @strategies/visualizer-colorizer
  @strategies/visualizer-mapbox

## Thinking through stuff:
For overlay positions, I've been using the client rect to get the position on the screen, but once we add zoom/pan into the mix, the viewer itself doesn't really know what the on-screen position is. Should the viewer not be responsible for reporting positions WITHIN its control. Then we'd need to use other events (e.g. from zoom pan) to query the actual on-screen location for that element.

It's a bit tedious, but it doesn't seem very elegant to expect the viewer to respond to all events that affect its position. 

However, the zoomable element doesn't know about the DOM elements beneath it anyway...