You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Normal zooming supports customizing zoom behavior using zoomFunctions, but the drag-to-zoom functionality that's implemented by zoomRect bypasses zoomFunctions and calls updateRange correctly.
I have a custom scale implementation that relies on zoomFunctions, so trying to enable drag-to-zoom causes problems. (Specifically, I'm breaking up the axis into viewports so that I can stack multiple series within this chart - somewhat like this example. The scales for the individual portions of the chart shouldn't be directly zoomed, because their layout is managed by a separate, controlling scale, so their zoomFunctions are no-ops.)
Zooming by rectangle appears to be a distinctly different interface than zooming by percentage and focal point, so would it be reasonable to add a zoomRectFunctions to let scales customize that behavior and cover this use case? Or is this too niche/specialized?
And, if it's worth adding zoomRectFunctions, would it be worth exposing zoomRect as part of the public API, like zoom and zoomScale?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Normal zooming supports customizing zoom behavior using
zoomFunctions
, but the drag-to-zoom functionality that's implemented byzoomRect
bypasseszoomFunctions
and callsupdateRange
correctly.I have a custom scale implementation that relies on
zoomFunctions
, so trying to enable drag-to-zoom causes problems. (Specifically, I'm breaking up the axis into viewports so that I can stack multiple series within this chart - somewhat like this example. The scales for the individual portions of the chart shouldn't be directly zoomed, because their layout is managed by a separate, controlling scale, so theirzoomFunctions
are no-ops.)Zooming by rectangle appears to be a distinctly different interface than zooming by percentage and focal point, so would it be reasonable to add a
zoomRectFunctions
to let scales customize that behavior and cover this use case? Or is this too niche/specialized?And, if it's worth adding
zoomRectFunctions
, would it be worth exposingzoomRect
as part of the public API, likezoom
andzoomScale
?Beta Was this translation helpful? Give feedback.
All reactions