Whilst working on the Tailwind renderer and the variables stuff, I noticed quite a lot of duplication, and some situations where it would be difficult or cumbersome to re-process elements once rendered as strings.
For example:
rendering the main code and preview Tailwind code requires two runs
Tailwind preview uses RegExps to parse hardcoded classes (adds complications for handling variables)
some functions require access to global settings
getLocalVariables() is deprecated in favour of getLocalVariablesAsync() meaning Tailwind functions may need to be async at some point
I know you have an interm "alt-node" format, but I figured an additional interim AST format would work at least in the HTML domain, so the Figma element would be parsed to this standard format, then that format could be more-easily processed then manipulated, for example:
single pass for HTML, Tailwind and Tailwind Preview
Tailwind preview uses AST rather than RegExps to walk classes and variable ids
resolve variables async
use single AST to render main and preview code (tweaking settings for each, injecting resolved variable values)
add in additional custom attributes easily (i.e. #96)
A single renderer which walks the tree is also simpler than having each node render its HTML.
Potentially could even simplify platform implementation by:
rendering to Tailwind by default
for HTML, walk the tree and expand classes to styles (using the build-time generated classes)
for BEM, walk the HTML tree and build CSS using layer names and styles
Hey @bernaferrari,
Whilst working on the Tailwind renderer and the variables stuff, I noticed quite a lot of duplication, and some situations where it would be difficult or cumbersome to re-process elements once rendered as strings.
For example:
getLocalVariables()
is deprecated in favour ofgetLocalVariablesAsync()
meaning Tailwind functions may need to beasync
at some pointI know you have an interm "alt-node" format, but I figured an additional interim AST format would work at least in the HTML domain, so the Figma element would be parsed to this standard format, then that format could be more-easily processed then manipulated, for example:
A single renderer which walks the tree is also simpler than having each node render its HTML.
Potentially could even simplify platform implementation by:
classes
tostyles
(using the build-time generated classes)I had a bit of bash this morning and got an initial renderer up and running (have yet to integrate with existing platform code):
Here's the AST:
And the HTML:
Anyway.
Another one for ideas to improve.
I think I can probably finish the variables stuff for now, but this would certainly be a more robust solution in the long term.
Will commit the code at some point and PR.