You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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)
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.
The text was updated successfully, but these errors were encountered: