-
Notifications
You must be signed in to change notification settings - Fork 9
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
feat(ts/hooks/useDetour): control waypoints with state machine #2607
Conversation
Coverage of commit
|
67f6d95
to
cd015ef
Compare
6ab1fed
to
8378733
Compare
Coverage of commit
|
Coverage of commit
|
cd015ef
to
c9f4c62
Compare
Coverage of commit
|
assets/src/hooks/useDetour.ts
Outdated
* > strongly-typed machines can still be achieved without Typegen. | ||
* > -- https://stately.ai/docs/migration#use-typestypegen-instead-of-tstypes | ||
*/ | ||
if ( |
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.
Near the bottom, we're still computing startPoint
and endPoint
(using a slightly different formula that I think will always give the same answer, assuming the state machine states are set up correctly).
Why not just compute startPoint
and endPoint
as values computed from snapshot
? So something like:
const startPoint = snapshot.context.waypoints.at(0)
const endPoint = snapshot.matches({
"Detour Drawing": { Editing: "Finished Drawing" },
}) && snapshot.context.waypoints.at(-1)
/* ... */
if (startPoint && endPoint) {
return fetchFinishedDetour(routePatternId, startPoint, endPoint)
}
/* ... */
return {
startPoint,
endPoint: endPoint || undefined,
/* ... */
}
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.
I tried to do this in 9c4e8a9
(#2607)
Let me know what you think!
This looks so good! I'm so excited to see how this makes the rest of our work on detours easier!
I think that splitting this in that way would be a good idea. I have a few reasons for thinking this:
|
9dd609f
to
0ba679d
Compare
Coverage of commit
|
I've opened up a PR for the first half #2616 |
useDetour
to use State Chart0ba679d
to
588dcc8
Compare
e8b1719
to
c5999e0
Compare
events: | ||
| { type: "detour.edit.clear-detour" } | ||
| { type: "detour.edit.done" } | ||
| { type: "detour.edit.place-connection-point"; location: ShapePoint } |
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.
We've discussed before that "Connection Point" actually means something different (the last un-missed stop before the detour begins and the first un-missed stop after the detour ends). Should we take this opportunity to come up with a different name?
| { type: "detour.edit.place-connection-point"; location: ShapePoint } | |
| { type: "detour.edit.place-point-on-original-route"; location: ShapePoint } |
☝️ a possibility, although honestly... we can do better 😅
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.
how about detour.edit.place-detour-terminus-point
?
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.
I'm mainly thinking that we may have "ghost" connection points, that are on the original route, so I'm trying to get at the root user intention.
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.
Though terminus
is not great :/ looking for something to generalize the idea of "start" and "end"
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.
👻 I'm not sure I understand "ghost" connection points on the original route? What is that? 👻
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.
Basically the ideas behind https://app.asana.com/0/1148853526253420/1207383192300456/f
We'd show the user connection points where they placed them, but the "ghost" connection points are the ones we actually use.
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.
Oh, huh.
Maybe I'm missing something, but isn't that a different question? Like, we're displaying the points in one spot, and computing them effectively from a different spot, but either way, the question is... what should they be called?
b82164e
to
b684c6d
Compare
Coverage of commit
|
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 has been greatly simplified since I last reviewed! I found it easier to read 👍
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.
Looks great!
It might be worth figuring out a better name per this comment --> #2607 (comment) <--, although I wouldn't want to block on that, since I don't have any good ideas 🙃
It might also be worth waiting until #2645 is merged, because I think they'll conflict, and #2645 blocks our current sprint goal.
Either way - those are both up to you - this PR looks excellent as it is!
829ccc3
to
340f277
Compare
Coverage of commit
|
Coverage of commit
|
Co-authored-by: Josh Larson <jlarson@mbta.com>
340f277
to
59c8e6b
Compare
Coverage of commit
|
Summary
Part 2 of the conversion of
useDetour
to a state machine!This converts the
waypoint
(includingstartPoint
andendPoint
) to be managed by a state machine, instead of manual logic for managing the state. (Considering revisiting this decision about start and end points!)Instead of managing separate
startPoint
andendPoint
s, they're now derived from the waypoints array, this is done so thatstartPoint
andendPoint
are no longer containing implicit state of the status of the machine.Review Notes
This PR involves a few dependencies and steps.
Depends on:
fetchFinishedDetour
to useuseApiCall
#2605waitFor
forexpect
#2602state
variable with state machine #2616This PR was done in these steps and such could be reviewed in that order to make the diff a little easier to read.
I optionally have cleanup(ts/hooks/useDetour): convert complex match to tags this to simplify the match logic for
finishedDetour
If desired, feat(ts/hooks/useDetour): replace state variable with state machine and feat(ts/hooks/useDetour): control waypoints with state machine can be split into two PRsEdit:
This has been broken into another PR
state
variable with state machine #2616Asana Ticket: https://app.asana.com/0/0/1207381767522634/f