Implement updates tracking OWID grapher#6
Open
xrendan wants to merge 1355 commits into
Open
Conversation
✨ (auto map brackets) pick log scales less often
🎉 (bespoke) demography project
✨ (demography) drop nocache flag
It's usually the same as the `yarn query` argument and pollutes the context.
Pi dropped support for =< 22.18.0 and at least for my setup the most convenient fix is to bump the node version of our project, since I install it into the same env. Since it's just a minor version bump it should hopefully require no other changes.
* 🔨 🤖 drop approved-by field from data insights We no longer use the ArchieML-driven approval mechanism — approvals are tracked outside the gdocs flow. Removes the validation, admin UI, and type-level traces of the field. ArchieML still accepts unknown keys, so existing data insights that have `approved-by` in their front-matter keep parsing unchanged; the value just isn't surfaced anywhere. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * 📜 🤖 drop stale approved-by mention in gdocs docs Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Signed-off-by: dependabot[bot] <support@github.com>
🐛 disable keyboard shortcuts in article embeds
🎉 test page for charts with chart type switching
🐛 correctly adjust time selection switching from Marimekko to Line
🐛 (admin) overwrite indicator-level rounding mode
🐛 (admin) avoid resetting entity selection on switching to the Basic tab
Previously the manual text input on each control point was bounded by the chart's auto-computed domain (e.g. ~110 years for South Korea's life expectancy), making it impossible to explore scenarios outside that data-driven range. - Add `inputMin`/`inputMax` to `ParameterConfig` with per-parameter absolute limits: life expectancy 10–150 yrs, fertility rate 0.1–10, net migration rate ±20‰ - Pass those limits to the react-aria `NumberField` so manual entry accepts the full range while the +/− step buttons still respect them - Include the current control-point values in the chart domain calculation so the chart rescales automatically when a manually entered value falls outside the auto-computed range - Dragging continues to clamp to the visible chart area via `yScale.clamp: true`, which now covers the expanded domain when an extreme value has been entered Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
[Cycle issue](#6169) / [Designs](https://www.figma.com/design/dCB69o19cAVtuk283STAcY/Dumbbell-Plots?node-id=1-31&m=dev) Implements hover, focus and tooltips for dumbbell plots. ### Description * Focus mode is only available to authors, i.e. via the admin or by editing the URL params directly * Hovering and updating the selection clears focus (this is how it works for other chart types as well) * The hovered dumbbell is highlighted by muting all other dumbbells * I wasn’t sure whether it’s better to use the entire row, including the label and whitespace on the left and right, as the hover hit area, or only the actual dumbbell. I opted for the former because it makes hovering a bit easier I think * The two modes, entity and column series strategy, have different tooltips: * If series strategy = entity, the tooltip is similar to the slope tooltip (start value -> end value) * If series strategy = column, the tooltip is similar to the scatter tooltip (start and end value on separate rows) * The change value is also shown if it’s used to label the dumbbell ### Follow-up work * ~Dumbbell elements~ * ~New dumbbell-specific options: value labels, end points~ * ~In-chart legend, aligned with the top-most dots~ * ~Interaction (focus, hover, tooltips)~ * Color (hard-coded for now) * More entity sorting options * Dumbbell plots in search * Dumbbell chart thumbnails
Small refactor of the props passed to tooltip components
Adds support for dumbbell charts in search.
This includes:
- Constructing the data table rendered in search
- Making sure the big data value on the right is appropriate
- Should say `Start value -> End value` in time-range mode (same as slope charts)
- Otherwise, it should be hidden (we never show a value for multi-y charts)
The thumbnail PNGs (with imMinimal=0/1) look good as is, I think.
This is a bit difficult to test. I mainly looked at the various endpoints (`.search-result.json`, `values.json`) and added tests.
This PR also includes a refactor that drops the dumbbell's series strategy and replaces it with a custom `mode`. If the series strategy is set to `column`, search expects the series items to refer to columns, not entities. But dumbbell charts always plot entities, so the appropriate series strategy is `entity`, and we should differentiate between time-range and two-column mode separately.
### Follow-up work
* ~Dumbbell elements~
* ~New dumbbell-specific options: value labels, end points~
* ~In-chart legend, aligned with the top-most dots~
* ~Interaction (focus, hover, tooltips)~
* Color (hard-coded for now)
* More entity sorting options
* ~Dumbbell plots in search~ (addressed in this PR)
* ~Dumbbell chart thumbnails~ (addressed in this PR)
Adds three more sorting options for dumbbell plots: by start and end value, and by change. Also refactors the sorting code a bit: Chart types now expose `availableSortKeys`, which is then used in the admin to construct dropdown options, and to narrow the type for the object specifying the sorting options. Marimekkos are excluded from the refactor because their sorting is intermingled with other code, and sooner or later we'll rewrite the Marimekko chart component anyway. ### Follow-up work * ~Dumbbell elements~ * ~New dumbbell-specific options: value labels, end points~ * ~In-chart legend, aligned with the top-most dots~ * ~Interaction (focus, hover, tooltips)~ * Color (hard-coded for now) * ~More entity sorting options~ * ~Dumbbell plots in search~ * ~Dumbbell chart thumbnails~
Allows color customisation for dumbbell charts.
* For two-column mode: Authors can assign an indicator colour via the admin
* For time-range mode: Authors can assign colours in the dumbbell section via the admin. These are mapped to the new `dumbbell.trendColorMap` config field.
* Instead of introducing a dumbbell-specific colour mapping, we could also re-use the top-level colorMap config field. But the `colorMap` is shared between all chart types, so if the dumbbell chart is shown next to a line chart, the line chart colour scheme would also apply to the dumbbell chart, which isn’t ideal
* Instead of introducing a new config field type, we could also re-use the existing colorMap type inside the dumbbell namespace. This feels like overkill though, and it’s also not a great fit because the internal ColorScale needs a color column, which doesn’t exist for dumbbells since there’s no column encoding increase/decrease/noChange. Of course, we could create one on the fly, but that seemed unnecessarily complex
* I also considered simply not allowing customisation, but at the very least, we’d need an “invert colors” config because mapping increase to green and decrease to red doesn’t work when “decrease is good”. So if we have to add one piece of config anyway, we might as well allow customisation
* I also considered not allowing customisation and simply choosing neutral colours for increase/decrease, but Marwa wasn’t a fan
Misc touchups for dumbbell charts after Marwa's feedback
Surface the existing type=Dumbbell embed test view on the admin test index page, alongside the other chart-type links.
Add dumbbell chart link to admin test index
Replace the hard-coded POPULATION_INDICATOR_ID_USED_IN_ADMIN and GDP_PER_CAPITA_INDICATOR_ID_USED_IN_ADMIN constants with catalog-path resolution, so the admin scatter defaults follow data updates instead of pointing at a soon-stale version. - Add getLatestVariableIdsByCatalogPath DB helper + a matching /api/variables/latestByCatalogPath.json endpoint that resolves version-agnostic catalog paths to the latest variable id. - Prefetch the ids in ChartEditorPage (variableIdsByCatalogPath) and read them in EditorBasicTab when applying scatter defaults. CONTINENTS_INDICATOR_ID stays hard-coded: it's also used at Grapher render time via isContinentsVariableId, which has no admin-API access.
…y-catalog-path 🔨 Resolve admin scatter default indicators by catalog path
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
11 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Context
Links to issues, Figma, Slack, and a technical introduction to the work.
Screenshots / Videos / Diagrams
Add if relevant, i.e. might not be necessary when there are no UI changes.
Testing guidance
Step-by-step instructions on how to test this change
Reminder to annotate the PR diff with design notes, alternatives you considered, and any other helpful context.
Checklist
(delete all that do not apply)
Before merging
If DB migrations exists:
After merging