Add explicit tests for "complex" defkeyframes forms #20
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Any form that needs top level language structures (like
(let)
) insteadof 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 ofabuses 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 withcomplex
defkeyframes
. I'm not the most worried about that, but we'lldefinitely 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.