💣 This is a work in progress pull request. It removes or changes several height and sizing related properties. These properties are tightly coupled, and the revised schema should not be depended on until the final version is merged. This ticket exists to provide an easily visible diff for developer reference.
Ticket
216
Purpose
The logic that governs height and sizing of panels in LocusZoom is complex, containing artifacts of several features that were either buggy or not ever implemented. (eg proportional origin, width, height). This makes it confusing to add or resize panels, especially when customizing premade layouts or adding content dynamically after first render.
This PR is intended to clean up the height and sizing logic by providing a smaller number of better defined options, and removing dead or unused code.
We will continue supporting responsive horizontal resize, but remove much of the "magic" behavior around height logic.
Summary of changes
Remove unused properties:
panel.proportional_width
panel.proportional_origin
Remove properties that were commonly used, but with minimal direct impact, in order to simplify the height API:
plot.height and plot.min_height (height is now exclusively determined by the sum of requested panel.heights)
panel.min_width and panel.width (all panels have the same width. Thus, width should only be specified once, in plot.layout)
Possibly breaking change:
Remove panel.proportional_height and the sumProportional internal function. Trying to constrain proportions across panels was very buggy when dynamically adding/removing tracks, and allowing this property to overrule panel.height was very confusing (especially when users tried to modify pre-existing layouts, only to find their options ignored).
After an audit of projects that use LocusZoom.js, almost no direct usages of proportional_height were found. Consequently, no explicit compatibility shim has been provided.
There may be small display artifacts for sites that used plot.height directly, but due to the nature of these as bugs, a direct compatibility layer would be tricky. Instead we will notify via release notes.
💣 This is a work in progress pull request. It removes or changes several height and sizing related properties. These properties are tightly coupled, and the revised schema should not be depended on until the final version is merged. This ticket exists to provide an easily visible diff for developer reference.
Ticket
216
Purpose
The logic that governs height and sizing of panels in LocusZoom is complex, containing artifacts of several features that were either buggy or not ever implemented. (eg proportional origin, width, height). This makes it confusing to add or resize panels, especially when customizing premade layouts or adding content dynamically after first render.
This PR is intended to clean up the height and sizing logic by providing a smaller number of better defined options, and removing dead or unused code.
We will continue supporting responsive horizontal resize, but remove much of the "magic" behavior around height logic.
Summary of changes
Remove unused properties:
panel.proportional_widthpanel.proportional_originRemove properties that were commonly used, but with minimal direct impact, in order to simplify the height API:
panel.heights)panel.min_widthandpanel.width(all panels have the same width. Thus, width should only be specified once, in plot.layout)Possibly breaking change:
panel.proportional_heightand thesumProportionalinternal function. Trying to constrain proportions across panels was very buggy when dynamically adding/removing tracks, and allowing this property to overrulepanel.heightwas very confusing (especially when users tried to modify pre-existing layouts, only to find their options ignored).After an audit of projects that use LocusZoom.js, almost no direct usages of proportional_height were found. Consequently, no explicit compatibility shim has been provided.
There may be small display artifacts for sites that used
plot.heightdirectly, but due to the nature of these as bugs, a direct compatibility layer would be tricky. Instead we will notify via release notes.