Test section visibility

[bpostlethwaite]

@alexcjohnson this PR tests <Section>. During testing I realized that we presumed our UI Fields like <Numeric> always had access to traceIndex and fullTraceIndex which was only the case when they were nested within a TraceAccordion.

I factored out findFullTraceIndex from <TraceAccordion> and now each widget (via unpackPlotProps) checks its context and props for traceIndex and fullTraceIndex and will also compute fullTraceIndex if it has to. This means users should not have to worry about fullTraceIndex at all.

I built up the test fixture libs a little more. Factoring out the derefencing logic into its own function (and porting over the more robust Workspace object walkers) from Hub.js allows us to toggle between referenced and dereferenced fixtures with a config flag.

Next PR will add more robust handling of PlotSchema.

[bpostlethwaite]

wait I just thought of something. Maybe the Data Attr Fields (via connectToPlot/Section and unpackPlotProps) should expect that traceIndex and fullDataIndex come from Context. Then instead of an API that requires nesting a Data Attr Field inside a TraceAccordion or manually receiving the traceIndex Prop we can create a new wrapper component called <Trace> which takes a traceIndex and/or fullTraceIndex (it'll compute the fullTraceIndex if it isn't passed in) which will pass the indexes down as context from it onward.

This matches the proposed <Layout> wrapper so that the nested machinery knows which container to target.

<PlotlyEditor>
    <Panel name="create">
        <Trace traceIndex={0}>
            <Section name="data">
                <DataSelector attr="x" />
            </Section>
        </Trace>
    </Panel>
    <Panel name="axis">
        <Layout>
            <Axis axis="xaxis">
                <Section name="range">
                    <Toggle attr="log" />
                </Section>
            </Axis>
        </Layout>
    </Panel>
</PlotlyEditor>

(Axis stuff just pseudo API...)

So Widgets will need to be nested inside either a Layout or a Trace or they will throw an error. <TraceAccordion> will then automatically generate <Trace> wrappers for every trace in gd.data. As such <TraceAccordion> will be less magical and serve as an example on how to construct other variants of linking widgets to traces.

I think I will implement this stuff in this PR so let's hold off on the review.

[bpostlethwaite]

Okay all that took was factoring out TracePanel from TraceAccordion.js. Now <Trace> can set the attr root as gd.data and we can create a <Layout> element that will set the attr root as gd.layout. This is nice and extensible as we will be able to create other containers that send things to frames etc. This might come in handy for simplifying how breakpoints work.

[bpostlethwaite]

ready for review

[alexcjohnson]

why?

[bpostlethwaite]

not sure, I lifted this thing from the workspace. The walker is useful, the array notation probably not. In future incarnations I imagine we will not actually use this thing. Also the whole makeAttrsetterPath function is used in the workspace but you told me about nestedProperty({}, attrPath).path or whatever it is which makes this whole function redundant. I'll probably delete it.

[alexcjohnson]

Looks great, really nice tests. One question about makeAttrSetterPath behavior, unless it has some purpose I'm not seeing I'd reduce to one way of providing an array index. But I won't hold it up for that.

I really like putting traceIndex etc into context - seems like it will extend well to other item selections (maybe you already have this in other PRs even) like annotations, axes, updatemenus[ buttons]...

💃

[bpostlethwaite]

Yup plenty more context usage ahead! I'm sorta stuck on the <Axes> API - a couple possibilities. Perhaps we can ☎️ on it soon.