-
Notifications
You must be signed in to change notification settings - Fork 2k
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
[experiment] Interactions #3092
base: main
Are you sure you want to change the base?
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
1 Ignored Deployment
|
This work follows some discussions that I'd had with @SomeHats on a similar API for gestures. I believe the designs she has around gestures are more oriented toward a replacement for the state chart. This PR is a step toward extracting an existing pattern "hiding" in many of our state nodes, where private "complete / cancel / update" methods were used. |
Next steps here would be to:
|
i'm sold on the benefits! I'd really recommend reading through the ios gesture recogniser docs tho: https://developer.apple.com/documentation/uikit/touches_presses_and_gestures (hard to point to just one second here as there's a lot of concepts and cool stuff, but take a look at the gesture recogniser, the APIs they take, and the way you establish relationships between different potential gestures). re names: how about just honestly these get pretty close to solving a lot more of our problems around customisation too. Right now the state chart does a couple things:
sessions take 3 away from this. 1 I think is actually what I'd like the state chart to evolve to doing exclusively. 2 is sort of the glue in the middle, which i think is where a lot of my exploration has been focused - using a single central gesture recogniser with a bunch of potential session-spawning "targets" to handle the routing part more declaratively |
Sounds good to me, let's use interaction for now. There's clearly a relationship here between the particular interaction and the gesture occurring simultaneously, but I'd like to have everything on the table before we start finding the patterns. There are still one or two things I need to move over, but once we have all the interactions covered so we can continue with that work. I may, like, print out all these different interactions so that we can compare them. There are a few places I'd like to clean up:
Yeah, if we can separate our interactions logic/lifecycles from the state chart, then that gives us better room to explore alternative ways of triggering those interactions. One of my favorite things about the current system is the degree to which we can test / drive it separate from the UI. As general as the state chart is, it's been able to handle almost everything that we've wanted from it. There's still a lot of logic in the state chart, for example handling the "shift+click" interactions around the draw or line shape when using those tools, and of course the select.idle state where we switch based on what we're hovering. Having targets would solve the second part but not the first? Anyway, big frog, many meals |
We'll need to compare with some of the changes that Mitja worked on, maybe diff against the original branch that this worked from, I'm not sure I merged these correctly. |
This PR introduces an "interactions" API for wrapping up interactions.
It adds a "brushing" interaction to demonstrate the API.
Background
In v1, we had interactions for rotating, translating, resizing, etc., which were essentially state machines designed to handle different user interactions. The editor could only have one interaction at a time and would update it when keys were pressed, when the pointer moved, etc.
This abstraction, while useful, was an incomplete abstraction for handling the complexity of the canvas.
In v2, I replaced interactions with a general state chart for handling interactions. This was much more flexible, however it also led to confusion when multiple states needed to share the same code. For example, when resizing a shape, we use the
select.resizing
state node; however, we also use theselect.resizing
state node when creating certain shapes. There are other concepts (like "tool mask") that are awkward patches for this fact.Why not both?
This PR re-introduces interactions as an additional abstraction in addition to the state chart.
interactions (2.0)
A interaction is a class instance that has several methods:
start
,update
,complete
,cancel
,interrupt
, anddispose
. When a interaction is created, it will update automatically on each tick, whenever keys are pressed, and when the user cancels or completes their interaction (i.e. by callingeditor.complete()
).interactions are purely additive. They solve the problem of "sharing code". In the case of the geo shape, the
geo.resizing
state would create and manage a resizing interaction. Theselect.resizing
state would also create and manage a resizing interaction.Multi-interactions?
There's no reason why we can't have multiple interactions running at the same time, which makes them ideal for multi-touch and other multiple input scenarios. If anything, the constraint here has to do with the way our editor manages inputs. We could add multiple inputs later and use interactions to keep track of their changes.
Change Type
major
Test Plan
Release Notes