Conversation
When estimating the extent properties inside style policies due to breakpoint switches during generation of a build spec from a style policy, we accidentally assigned the policies that contained estimated extents, which lead to weird behavior when triggering different breakpoints.
| delete morphInScope._skipMasterReplacement; | ||
| return; | ||
| if (!morphInScope.master) { | ||
| morphInScope.setProperty('master', synthesizedSpec); // how can we carry over overridden props? |
There was a problem hiding this comment.
Feel free to merge regardless, but this comment makes me worry - is there a hidden footgun in this? If so, have you made a note of that somewhere/could you open a ticket, so that we can be sure to tackle this at some point and not forget?
If there is nothing to worry about, maybe just delete the comment?
There was a problem hiding this comment.
Well, we fix the issue mentioned in the comment by not setting the master if there is already one present. That way we avoid the issue of having to worry about carrying over the overridden props.
However what won't properly work now out of the box, is manually swapping out (via aMorph.master = ...) the master of a morph which comes with a set of other components for its submorphs. We don't support this modus of operation for masters since a while now anyways, since we do everything via component definitions and custom master states for swapping out masters.
But I will look and check if there is issues about this before merging.
2 participants
Fixes #1731.