Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add explicit tests for "complex" defkeyframes forms #20

Merged
merged 1 commit into from
Nov 1, 2024

Conversation

dhleong
Copy link
Owner

@dhleong dhleong commented Nov 1, 2024

Any form that needs top level language structures (like (let)) instead
of directly emitting their garden forms are "complex." For style
declarations like defclass, we can rely on garden's support for [:&]
as a self-referential symbol to handle these cases. (at-keyframes)
could support this symbol, but per API expects a variadic sequence of
rules, eg (at-keyframes [:from {:opacity 0}] [:to {:opacity 1}]).

In the currently published version of garden, defkeyframes sort of
abuses the fact that it incorrectly also accepts a list containing the
sequence of rules. However, there's an unpublished change that "fixes"
this bug, breaking defkeyframes. Relatedly, our unofficial support for
manual ^{:key key} meta on the first rule doesn't work with
complex defkeyframes. I'm not the most worried about that, but we'll
definitely need to fix the first issue, so if we can fix the second
while we're there, we might as well.

This PR encodes a couple ways to build these complex forms so we have a more thorough test suite to develop a fix against.

Any form that needs top level language structures (like `(let)`) instead
of directly emitting their garden forms are "complex." For style
declarations like defclass, we can rely on garden's support for `[:&]`
as a self-referential symbol to handle these cases. `(at-keyframes)`
*could* support this symbol, but per API expects a variadic sequence of
rules, eg `(at-keyframes [:from {:opacity 0}] [:to {:opacity 1}])`.

In the currently published version of garden, `defkeyframes` sort of
abuses the fact that it incorrectly also accepts a list containing the
sequence of rules. However, there's an unpublished change that "fixes"
this bug, breaking defkeyframes. Relatedly, our unofficial support for
manual `^{:key key}` meta on the first rule doesn't work with
complex `defkeyframes`. I'm not *the most* worried about that, but we'll
definitely need to fix the first issue, so if we can fix the second
while we're there, we might as well.
@dhleong dhleong marked this pull request as ready for review November 1, 2024 19:18
@dhleong dhleong merged commit e3ee554 into main Nov 1, 2024
1 check passed
@dhleong dhleong deleted the complex-defkeyframes branch November 1, 2024 19:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant