In short, it creates more complexity and redundant structures than solves the initial problem.
Conceptually, scatterregl is one of cartesian plot traces, because it does not bring any new grid or plot info, unlike geo, gl3d (better called 3d), polar, parcoods or ternary (not sure why mapbox and geo are different plot types).
Technically scatterregl reuses existing cartesian grid and data-flow.
The initial problem we are trying to address is creating regl components at the right moment, and that is rather technical nuance than the reason for new plot type.
Practically, cartesian plot has a lot of inclusions across plotly ecosystem, and if we are going to reuse cartesian plot logic we should take care of every such integration/check/edge case (like type === 'cartesian', layout._has('cartesian')), and that leads to massive code duplication (like Cartesian.plot method), which is prone to errors, edge cases, fast obsolescence and more maintaining efforts.
Envisioning ideal result, the most proper place to create scene is subplot object creation, which is neither accessible from plot CartesianRegl.plot nor trace ScatterRegl.plot, so we don't get any benefit out of that solution compared to ScatterRegl.plot. Even more, the second is pretty straightforward and wholesome.
Pragmatically speaking, the last 3 days have been spent on attempts to refactor scatterregl to use a separate base plot module, and that led to confusion, code complexity and overall mess. It is hard to imagine good maintenance of such solution, since even coding of that is of the utmost stress.
In short, it creates more complexity and redundant structures than solves the initial problem.
Conceptually,
scatterreglis one ofcartesianplot traces, because it does not bring any new grid or plot info, unlikegeo,gl3d(better called3d),polar,parcoodsorternary(not sure whymapboxandgeoare different plot types).Technically
scatterreglreuses existing cartesian grid and data-flow.The initial problem we are trying to address is creating regl components at the right moment, and that is rather technical nuance than the reason for new plot type.
Practically,
cartesianplot has a lot of inclusions across plotly ecosystem, and if we are going to reusecartesianplot logic we should take care of every such integration/check/edge case (liketype === 'cartesian',layout._has('cartesian')), and that leads to massive code duplication (likeCartesian.plotmethod), which is prone to errors, edge cases, fast obsolescence and more maintaining efforts.Envisioning ideal result, the most proper place to create scene is subplot object creation, which is neither accessible from plot
CartesianRegl.plotnor traceScatterRegl.plot, so we don't get any benefit out of that solution compared toScatterRegl.plot. Even more, the second is pretty straightforward and wholesome.Pragmatically speaking, the last 3 days have been spent on attempts to refactor
scatterreglto use a separate base plot module, and that led to confusion, code complexity and overall mess. It is hard to imagine good maintenance of such solution, since even coding of that is of the utmost stress.