abought
commented
3 years ago After initial prototyping, I'm moving this off the 0.14 milestone. It could still be useful as a design approach, but there are currently too few use cases for us to justify writing another generic mechanism. Closing but we can revisit.
There are times when it is desirable to add bundles of functionality to a layout for commonly defined features (like scatter plot + gwas catalog + credible set).
Current reusable mechanisms make it difficult to merge separate bundles of functionality. Can we simplify this? One option to explore is traits.
A good "in practice / look and feel" explanation: https://factoryboy.readthedocs.io/en/stable/reference.html#traits
This change is tentatively aimed for 0.14, pending evaluation and experimentation. It might force rearrangement of some existing layouts, and could affect certain specialized usages of LZ as a breaking change.
Details: Instead of subclassing to add code one level at a time, the idea is to support composition by declaring groups of behaviors that can be added.
Example:
Right now, 2 and 3 are separate child layouts. If you want to show both, you need to manually merge features by manipulating discrete layout objects at the plot, panel, data_layer , and tooltip levels. Maybe also edit some widgets. Figure that 10-15 layout objects generated to show one piece of data with either 0, 1, or 2 kinds of addon.
Implementation plan The tentative plan is to give layouts a new mixin command that internally uses your JSONschema mutate_attrs helper to modify targeted parts of the layout object. Add one keyword to the layout definition, and auto merge properties in a selective way without manually updating every level of nesting.
Traits would internally be defined and implemented as tagged-layer mutations (using the mutate_attrs helper to address items semantically). Where possible features would be defined and grouped in a way that allowed clean merging, eg, concatenating two lists of display option dropdown items.