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
{{ message }}
Repository navigation
[Proposal] AST approach for HTML, Tailwind, BEM, etc #120
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)
@bernaferrari you mentioned AST refactoring in another issue...
I think the current conversion code is a bit difficult to work with. The HTML and Tailwind builders seem to have a lot of overlapping code, and it also seems to be spread out across multiple files without much benefit. There also seems to be some inconsistency with passing around the settings that are necessary for doing the conversion vs sharing them as global variables. Many of the functions output strings (rather than something like a key/value pair for styles) meaning each function needs to consider whether it has JSX formatting. That's a lot of duplicated work spread all around.
So I think the AST idea makes a lot of sense. It's probably how I would want to build it from scratch.
At the same time, I question whether it would add much benefit at this point and seems like it could be a lot of work to redo all of that. The main reason to do it might be to make things easier to edit in the future.
Maybe it makes sense to try to completely remake this whole plugin with everything you've learned, but without all the history and legacy stuff and focus on only one language to start?
Activity
[-][Proposal] v-node approach for HTML and Tailwind[/-][+][Proposal] v-node approach for HTML, Tailwind, BEM, etc[/+][-][Proposal] v-node approach for HTML, Tailwind, BEM, etc[/-][+][Proposal] AST approach for HTML, Tailwind, BEM, etc[/+]mimshwright commentedon Jan 14, 2025
I like it!
bernaferrari commentedon Jan 14, 2025
I like it too!
mimshwright commentedon Jan 21, 2025
@bernaferrari you mentioned AST refactoring in another issue...
I think the current conversion code is a bit difficult to work with. The HTML and Tailwind builders seem to have a lot of overlapping code, and it also seems to be spread out across multiple files without much benefit. There also seems to be some inconsistency with passing around the settings that are necessary for doing the conversion vs sharing them as global variables. Many of the functions output strings (rather than something like a key/value pair for styles) meaning each function needs to consider whether it has JSX formatting. That's a lot of duplicated work spread all around.
So I think the AST idea makes a lot of sense. It's probably how I would want to build it from scratch.
At the same time, I question whether it would add much benefit at this point and seems like it could be a lot of work to redo all of that. The main reason to do it might be to make things easier to edit in the future.
Maybe it makes sense to try to completely remake this whole plugin with everything you've learned, but without all the history and legacy stuff and focus on only one language to start?