Rename `Chart` to `View`?

Since both Track and View are important concepts in Gosling, I think we can support explicit functions for both in the python package as well. In this regard, I was wondering whether it makes sense to rename Chart to View since Chart() looks to construct Gosling’s views.

// from
gos.Chart(
    title='Overview and Detail Views',
    arrangement='horizontal',
    views=[overview, detail_view]
)

// to
gos.View(
    title='Overview and Detail Views',
    arrangement='horizontal',
    views=[overview, detail_view] // two children views that are nested in this parent view
)

So, at the root level, users define a View, and it can contain either multiple Views or Tracks.

[manzt]

Thanks for all the thoughtful ideas. This is sort of what I had in mind already and have started implementing to some extent.

One of the reasons the partial specification is supported in Gosling (and in Vega-Lite I think) is to prevent code repetition, and my guess is that they do not necessarily support the partial specification since this issue (repetition) can be easily handled by the programmatical approach.

Completely agree. I’m thinking that for now, we don’t expose the PartialTrack and instead just work with complete Track’s. This will make the JSON larger at the end, but that is OK IMO. If it becomes an issue, we can always write a script to strip out duplicated (unecessary) fields 😃

Additionally, thank you for all the examples and explanation. It helps a lot for me to understand gosling’s data-model much better. You have actually identified a bug with the current implementation. The class Track should only be able to hold fields for a gosling Track, but the properties API is sneaky because it allows a hook to add additional fields (which) actually turn the Track into a View! For example,

track4 = Track(multivec).encode(
    x=gos.Channel("position:G", axis="top"),
    y="peak:Q",
    row="sample:N",
    color=gos.Channel("sample:N", legend=True),
    tooltip=tooltip,
).properties(
    alignment="overlay",
    tracks=[
        gos.PartialTrack().mark_line(),
        gos.PartialTrack().mark_point().encode(
            size=gos.Channel("peak:Q", range=[0, 2]),
        )
    ],
)

“Works” because the constructor for Track is called with proper arguments and passes validation. The assignment in the .properties method adds these fields to the Track instance, but effectively changes the type from a track to a SingleView. The way that the validation ends up working, this is still valid in the end. But for example if you call Track like below,

gos.Track(
    multivec,
    alignment="overlay",
    tracks=[
        gos.PartialTrack().mark_line(),
        gos.PartialTrack().mark_point().encode(
            size=gos.Channel("peak:Q", range=[0, 2]),
        )
    ],
)

# gosling.schemapi.SchemaValidationError: Invalid specification
#
#        gosling.api.Track->0, validating 'additionalProperties'
#
#        Additional properties are not allowed ('alignment', 'tracks' were unexpected)

It results in an error. The idea with properties is to have a nice shorthand modify the class instance. So technically,

gos.Track(data, ...)

# and 

gos.Track(data).properties(...) 

should be equivalent. The fact that the example still compiled with the Track(data).properties(alignemnt=..., tracks=...) confused me about what the types in gosling actually are. But now I can see clearly what’s going on.

Thanks for all your help. I’m goign to work on the API today and will ping you when I have something cleaned up 😃

[sehilyi]

Another thing I realized is that Altair does not seem to expose types at all (or may a few) that are beyond a chart level. For example, instead of alt.HConcatSpec(), Altair let users use | or alt.hconcat() to generate { hconcat: [{...}, {...}] } specs. As I personally find them really useful, I wonder if we want to (or you are planning to) support such operations and probably deprecate the use of tracks=[...]:

a = overlay_base.mark_bar().encode(...)
b = overlay_base.mark_brush().encode(...)
c = overlay_base.mark_brush().encode(...)

d = (a + b + c) # SingleTrack

If we want to support both the track and view composition, we could do something like the following?:

v1 = gos.overlay(a, b) # { alignemet: "overlay", tracks: [ /* a */, /* b */ ] }
v2 = gos.stack(a, b) # { alignemet: "stack", tracks: [ /* a */, /* b */ ] }

gos.horizontal(v1, v2) # { arrangement: "horizontal", views: [/* v1 */, /* v2 */] }
gos.vertical(v1, v2) # { arrangement: "vertical", views: [/* v1 */, /* v2 */] }
gos.parallel(v1, v2) # { arrangement: "parallel", views: [/* v1 */, /* v2 */] }
gos.serial(v1, v2) # { arrangement: "serial", views: [/* v1 */, /* v2 */] }

# specify additional properties
gos.stack(a, b, spacing=30, layout='linear', xDomain={...})
...

(Sorry, comments became too long than I expected 😅 )