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
An unexpected use case has arisen where users try to use a variable to dynamically generate Hydrogen attributes. The problem arises when this variable is resolved on the front-end of the application, because Hydrogen compiles its production CSS on the server by checking final markup.
data-h2-border={`b(${colorMap[color][mode].border}, all, solid, s)`}
Proposal
for now, update the docs to indicate that this can't be done, and will break the final output CSS
highlight the workaround of making the entire attribute the variable, rather than part of the attribute
research ways to properly account for this type of use
Notes
suggestion from @Khristophor : have H2 process the project and create a list of variables in use?
suggestion based on discussion with @tristan-orourke : have Hydrogen parse the file by looking for data-h2-attr values, then parse the file by looking for x(.*) media queries (defined in the config), generate selectors by combining both, removing duplicates, and then match them against the CSS
problem 1: this generates CSS false positives, because it looks for any combination of an attribute and values it COULD have
problem 2: this will parse way slower, because it needs to find all instances in a file twice, and then generate a new list of selectors to look for
Hydrogen could parse variables and store them in an object and then check their values against values inside of the attributes when the time comes... this would likely be intensive, and what happens when variables are nested declarations or referring to arrays/objects?
There could be alternative syntax for defining h2_var which would accept a string and only a string, and then Hydrogen could parse those, but that would limit the variable use case.
The text was updated successfully, but these errors were encountered:
Purpose
An unexpected use case has arisen where users try to use a variable to dynamically generate Hydrogen attributes. The problem arises when this variable is resolved on the front-end of the application, because Hydrogen compiles its production CSS on the server by checking final markup.
Proposal
Notes
data-h2-attr
values, then parse the file by looking forx(.*)
media queries (defined in the config), generate selectors by combining both, removing duplicates, and then match them against the CSSHydrogen could parse variables and store them in an object and then check their values against values inside of the attributes when the time comes... this would likely be intensive, and what happens when variables are nested declarations or referring to arrays/objects?
There could be alternative syntax for defining
h2_var
which would accept a string and only a string, and then Hydrogen could parse those, but that would limit the variable use case.The text was updated successfully, but these errors were encountered: