-
Notifications
You must be signed in to change notification settings - Fork 10
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
boxel-motion improvements #1105
Conversation
59455b6
to
4b95283
Compare
Screen.Recording.2024-03-20.at.4.35.09.PM.mov |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@debugging
is great 🤩
A few other thoughts, so I don't forget them:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems fine as an incremental step. But in terms of the vision for how I think boxel-motion is supposed to work, fill
doesn't really make sense.
The use case for boxel-motion is that you already have an initial and final DOM and the behaviors explain what happens in between those states. If behaviors are able to alter the final DOM, it seems like something about the architecture is getting muddied.
- Add Split View example to boxel-motion test app as a study for the AI Assistant Panel animation - Incorporate boxel-motion builds into CI - Generalize fill behavior of behaviors rather than special casing StaticBehavior treatment - Default StaticBehavior to a duration of 1, since you can now opt into forward fill - when using StaticBehavior with SpringBehavior, you don't know how long the animation will be, and you may want a static animation to persist for the duration of the animation - Use context-relative bounds for removed sprites
860a1b1
to
609aaab
Compare
extracted from #1097