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

feat(ts/hooks/useDetour): control waypoints with state machine #2607

Merged
merged 1 commit into from
Jun 11, 2024

Conversation

firestack
Copy link
Member

@firestack firestack commented May 20, 2024

Summary

Part 2 of the conversion of useDetour to a state machine!
This converts the waypoint (including startPoint and endPoint) 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 and endPoints, they're now derived from the waypoints array, this is done so that startPoint and endPoint are no longer containing implicit state of the status of the machine.

Review Notes

This PR involves a few dependencies and steps.


Depends on:


This PR was done in these steps and such could be reviewed in that order to make the diff a little easier to read.

  1. feat(ts/hooks/useDetour): control waypoints with state machine
  2. cleanup(ts/hooks/useDetour): move callback intermediate state into function scope to reduce recalls

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 PRs

Edit:
This has been broken into another PR


Asana Ticket: https://app.asana.com/0/0/1207381767522634/f

@firestack firestack self-assigned this May 20, 2024
Copy link

Coverage of commit 67f6d95

Summary coverage rate:
  lines......: 93.5% (3240 of 3464 lines)
  functions..: 73.3% (1339 of 1827 functions)
  branches...: no data found

Files changed coverage rate: n/a

Download coverage report

@firestack firestack marked this pull request as ready for review May 20, 2024 12:52
@firestack firestack requested a review from a team as a code owner May 20, 2024 12:52
@firestack firestack force-pushed the kf/asn/state-machine/waypoints branch from 67f6d95 to cd015ef Compare May 20, 2024 13:30
@firestack firestack force-pushed the kf/cleanup/convert-finished-useapi branch from 6ab1fed to 8378733 Compare May 20, 2024 13:30
Copy link

Coverage of commit cd015ef

Summary coverage rate:
  lines......: 93.6% (3241 of 3464 lines)
  functions..: 73.3% (1340 of 1827 functions)
  branches...: no data found

Files changed coverage rate: n/a

Download coverage report

Copy link

Coverage of commit cd015ef

Summary coverage rate:
  lines......: 93.5% (3240 of 3464 lines)
  functions..: 73.3% (1339 of 1827 functions)
  branches...: no data found

Files changed coverage rate: n/a

Download coverage report

Base automatically changed from kf/cleanup/convert-finished-useapi to main May 20, 2024 17:53
@firestack firestack force-pushed the kf/asn/state-machine/waypoints branch from cd015ef to c9f4c62 Compare May 21, 2024 21:51
Copy link

Coverage of commit c9f4c62

Summary coverage rate:
  lines......: 93.5% (3241 of 3465 lines)
  functions..: 73.3% (1340 of 1828 functions)
  branches...: no data found

Files changed coverage rate: n/a

Download coverage report

* > strongly-typed machines can still be achieved without Typegen.
* > -- https://stately.ai/docs/migration#use-typestypegen-instead-of-tstypes
*/
if (
Copy link
Contributor

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,
 
  /* ... */
}

Copy link
Member Author

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!

@joshlarson
Copy link
Contributor

This looks so good! I'm so excited to see how this makes the rest of our work on detours easier!

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 PRs.

I think that splitting this in that way would be a good idea. I have a few reasons for thinking this:

  1. This whole thing was a lot easier to review commit-by-commit (well, those two commits - the other commits are mostly fixes and prework that would disappear in a rebase), which means that those commits make sense as standalone work.
  2. I'm pretty sure the first PR by itself unblocks the detour route selection panel.
  3. I think the first PR is either ready to merge or very very close, while there are a bunch of comments on the second one that I'd be interested in resolving before merging it.

@firestack firestack changed the base branch from main to kf/asn/state-machine/state-var May 22, 2024 00:29
@firestack firestack force-pushed the kf/asn/state-machine/waypoints branch 2 times, most recently from 9dd609f to 0ba679d Compare May 22, 2024 00:35
Copy link

Coverage of commit 0ba679d

Summary coverage rate:
  lines......: 93.6% (3242 of 3465 lines)
  functions..: 73.4% (1341 of 1828 functions)
  branches...: no data found

Files changed coverage rate: n/a

Download coverage report

@firestack
Copy link
Member Author

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 PRs.

I think that splitting this in that way would be a good idea. I have a few reasons for thinking this:

  1. I'm pretty sure the first PR by itself unblocks the detour route selection panel.

I've opened up a PR for the first half #2616

@firestack firestack changed the title cleanup:feat(ts/hooks/useDetour): convert useDetour to use State Chart feat(ts/hooks/useDetour): control waypoints with state machine May 22, 2024
@firestack firestack force-pushed the kf/asn/state-machine/waypoints branch from 0ba679d to 588dcc8 Compare May 23, 2024 12:01
@firestack firestack force-pushed the kf/asn/state-machine/state-var branch from e8b1719 to c5999e0 Compare May 23, 2024 12:01
events:
| { type: "detour.edit.clear-detour" }
| { type: "detour.edit.done" }
| { type: "detour.edit.place-connection-point"; location: ShapePoint }
Copy link
Contributor

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?

Suggested change
| { 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 😅

Copy link
Member Author

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?

Copy link
Member Author

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.

Copy link
Member Author

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"

Copy link
Contributor

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? 👻

Copy link
Member Author

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.

Copy link
Contributor

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?

@firestack firestack force-pushed the kf/asn/state-machine/waypoints branch from b82164e to b684c6d Compare May 29, 2024 17:24
Copy link

Coverage of commit b684c6d

Summary coverage rate:
  lines......: 93.6% (3242 of 3465 lines)
  functions..: 73.4% (1341 of 1828 functions)
  branches...: no data found

Files changed coverage rate: n/a

Download coverage report

hannahpurcell
hannahpurcell previously approved these changes Jun 3, 2024
Copy link
Collaborator

@hannahpurcell hannahpurcell left a 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 👍

joshlarson
joshlarson previously approved these changes Jun 5, 2024
Copy link
Contributor

@joshlarson joshlarson left a 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!

@firestack firestack force-pushed the kf/asn/state-machine/waypoints branch 2 times, most recently from 829ccc3 to 340f277 Compare June 10, 2024 15:39
@firestack firestack dismissed stale reviews from joshlarson and hannahpurcell June 10, 2024 15:40

new commits

Copy link

Coverage of commit 340f277

Summary coverage rate:
  lines......: 93.6% (3257 of 3480 lines)
  functions..: 73.4% (1343 of 1830 functions)
  branches...: no data found

Files changed coverage rate: n/a

Download coverage report

Copy link

Coverage of commit 340f277

Summary coverage rate:
  lines......: 93.6% (3257 of 3480 lines)
  functions..: 73.4% (1343 of 1830 functions)
  branches...: no data found

Files changed coverage rate: n/a

Download coverage report

Co-authored-by: Josh Larson <jlarson@mbta.com>
@firestack firestack force-pushed the kf/asn/state-machine/waypoints branch from 340f277 to 59c8e6b Compare June 10, 2024 20:22
Copy link

Coverage of commit 59c8e6b

Summary coverage rate:
  lines......: 93.6% (3257 of 3480 lines)
  functions..: 73.4% (1343 of 1830 functions)
  branches...: no data found

Files changed coverage rate: n/a

Download coverage report

@firestack firestack merged commit ddd6728 into main Jun 11, 2024
15 checks passed
@firestack firestack deleted the kf/asn/state-machine/waypoints branch June 11, 2024 18:10
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.

3 participants