Tailwind MegaSpike

[bkrmendy]

Problems explored on this spike

Patching removed props

During canvas interactions, we write props to the inline style even in Tailwind projects, so that the updates happen as fast as possible. However, when a prop is removed during a canvas interaction, we want to override it with a 0px (or similar) value so that the relevant Tailwind class doesn’t take over. Example: while the gap prop is being adjusted, the gap property value is coming from the inline style gap prop, but as soon as it’s removed, the gap value from the tailwind class takes over, making it look like the gap is jumping back to its original size. Setting 0px works for simple values, but for more complex props like padding, this approach broke down in a surprising way: React doesn’t like it when the longhand and the shorthand version of the same CSS prop are set at the same time. This manifested in the paddings randomly disappearing. This is a well-documented wontfix in React, see facebook/react#8689. We need to tackle this problem in way that won't infect all other code around it.

The solution to this is patchRemovedProperties (and everything else it calls). While internally it's still a pretty heuristic way to solve the problem, it isolates it in a way that

• only runStyleUpdateMidInteraction is involved in figuring out which properties need to be zeroed
• only the strategy dispatch in involved in zeroing these props, in an explicit, opt-in way (the opt-in happens through calling patchRemovedProperties)

Code that has reading/writing from the style prop baked in

Utopia has reading/writing from the inline style prop baked in throughout the editor code, we should investigate how widespread this is and how this could be dealt with.

This lead to the following explorations:

• I refactored AdjustCssLengthProperties to use styleInfoFactory instead of reading from element props (see the diff for details), to showcase how we can refactor a command from reading directly from the inline style prop to a style-prop agnostic approach. This refactor also showed that the StyleInfo system doesn't express the state that a prop is set, but it's a value that we can't consume (for example if instead of a CSS number, it's a JS expression or identifier), so I made the necessary adjustments.
• The SET_PROP/UNSET_PROP actions write into the inline style prop too. I updated these actions to use the commands under the hood, so if we wanted to add some extra logic related to setting/unsetting props, the actions get those automatically.
• There are some functions that write the inline style prop, and they are so high up the call stack that it would be very laborious to pass them down all the info the plugins might need (concretely, the Tailwind config for the Tailwind plugin). To deal with this, I added a Jotai atom + store to store the Tailwind config, and make it accessible without massive amounts of refactoring

Normalising props removed by an action or strategy / Alternative approaches to normalization

Commands (and the Utopia code in general) could modify elements that aren’t apparent from the command descriptor object. This is problematic because the normalisation step needs to know which elements to normalize, but this has to be communicated by the commands somehow. Since the commands and prop setting in general have to be audited anyway (because of the above), an alternative to the normalization approach (which we have now) could be investigated.

One way to approach this is that in a command/action that might remove a prop, we make a note somewhere that a prop has been removed, and then later down the line remove that prop from wherever it needs to be removed (inline style prop or className). However, instead of "making a note", what about removing the prop straight away? This is underpinned by the fact that most commands already use applyValuesAtPath to set props, and deleteValuesAtPath to remove props. I updated the StylePlugin type with the equivalents of applyValuesAtPath and deleteValuesAtPath, turning them into an official API to be implemented by the style plugins. Then, these functions can be called instead of writing the prop directly into the inline style.

The question of hard-to-refactor, high-up-the-call-stack functions comes up here too. We can take advantage of the fact that if a function reads/writes from/to element props (either via the props themselves or via ElementInstanceMetadata), because the className prop that Tailwind needs is also among the element props (this would be a harder nut to crack if we wanted to support styled-components). Style plugins already parse element styles from props, so by creating another entrypoint for reading and writing, and we use Jotai store-based approach to get the right plugin to use, this becomes a tractable problem.

[github-actions]

Try me

[relativeci]

#15089 Bundle Size — 58.07MiB (+0.01%).

0f4b889(current) vs d1d46c1 master#15082(baseline)

Warning

Bundle contains 70 duplicate packages – View duplicate packages

Bundle metrics   3 changes 1 regression

	Current #15089	Baseline #15082
Initial JS	41.05MiB(+0.01%)	41.04MiB
Initial CSS	0B	0B
Cache Invalidation	21.47%	18%
Chunks	20	20
Assets	22	22
Modules	4168(+0.02%)	4167
Duplicate Modules	213	213
Duplicate Code	27.3%	27.3%
Packages	477	477
Duplicate Packages	70	70

Bundle size by type   2 changes 1 regression 1 improvement

	Current #15089	Baseline #15082
JS	58.06MiB (+0.01%)	58.06MiB
HTML	7.37KiB (-0.25%)	7.39KiB

Bundle analysis report Branch spike/plugin-prop-setter Project dashboard

---

^{Generated by RelativeCI Documentation Report issue}

[bkrmendy]

runSetCssLengthProperty is refactored not to read directly from the inline style prop

[bkrmendy]

writing the inline styles instead of the whatever the active plugins needs during an interaction