-
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
cleanup(ts/hooks/useDetour): replace state
with snapshot
from createDetourMachine
#2617
Conversation
Coverage of commit
|
c5999e0
to
ed07886
Compare
2cb4dbe
to
f5c2ec3
Compare
Coverage of commit
|
Coverage of commit
|
ed07886
to
5f13e11
Compare
f5c2ec3
to
2b8a7f1
Compare
5f13e11
to
d933c71
Compare
2b8a7f1
to
54a8fac
Compare
Coverage of commit
|
Coverage of commit
|
d933c71
to
cfdc141
Compare
54a8fac
to
9f5292e
Compare
Coverage of commit
|
Coverage of commit
|
Coverage of commit
|
Coverage of commit
|
@@ -99,7 +99,7 @@ export const DiversionPage = ({ | |||
</header> | |||
|
|||
<div className="l-diversion-page__panel bg-light"> | |||
{state === DetourState.Edit && ( | |||
{snapshot.matches({ "Detour Drawing": "Editing" }) ? ( |
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.
Uprooting a comment thread from the original version of this PR and bringing it here:
Me:
Hmmm - I don't love this, because it leaks the state machine guts out of useDetour and into diversionPage. I like the (imperfect but improving) idea that useDetour's role is to tell diversionPage a bunch of facts about the detour (well, really the detour editing process) as it currently is, and I feel like calling xstate methods directly strays away from that.
I know earlier I said that we should get rid of DetourState, but having something at the level of EditScreen/SharingScreen (and eventually /RouteSelectionScreen) feels like an appropriate thing for useDetour to expose.
I somewhat disagree because I see the state machine replacing useDetour/useDetour being a light wrapper around the state machine. I prefer this, because to me the state machines states should ideally match what we're trying to do in the UI, so it should read well to use the state machines states directly in the UI, and IMO, exposing extra states from useDetour that the state machine is unaware of feels wrong in an anti-pattern type way (I could be wrong!), but I think that the state machine is enough of an enum that I'd argue it's typesafe enough to be part of the public api of useDetour and the UI
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 think what's throwing me off is that I envisioned the responsibilities of the components as something like:
- state machine does all the state management, like holding onto data and figuring out how to handle state transitions. Ya know - state machine stuff.
useDetour
maps that onto ... sort of a description of what's on the screen. Things like "the start point is here", and "the undo button should do this thing" (or "the undo button should be disabled right now")<DiversionPage />
and its friends<DetourMap />
and the various<*Panel />
s handle the layout, but don't do any interpretation beyond putting the things fromuseDetour
in the right place on the screen.
So to me, the mapping of "this is the xstate state we're in" to "throw the whatever panel on the left" maps cleanly onto useDetour
's responsibilities. This code makes <DiversionPage />
do that instead, which feels like it cuts through the boundaries ☝️ differently from everything else.
The original reason I had this thought was because I envisioned useDetour
as a (thin) wrapper around the state machine, and this particular thing pokes through that wrapper. Everything ☝️ ☝️ ☝️ is, I think, why I kind of want to stand by my instinct here.
I would also maybe be open to totally removing useDetour
and putting <DiversionPage />
in charge of the "xstate state" <-> "UI description" mapping instead.
I'm not totally sold on that, because I think that there's value in keeping the layout details and the page description separate from each other (and I don't want <DiversionPage />
to get too bloated), but there might also be a bit of a fear-of-change thing going on, so I'd be interested to see how it looks if we decided to try it.
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 would also maybe be open to totally removing useDetour and putting in charge of the "xstate state" <-> "UI description" mapping instead.
...what if we just get rid of useDetour
? 😅 I'm in favor of this :) especially as I'm having to do a lot of the same calls in useDetour
as the diversion page now.
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'll have something for us to chat about soon which I think might help here!
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.
Can't wait!
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.
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.
@joshlarson, given our conversation, do you think there's any more to do here on this PR?
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 woops! Lemme give this another 👀
9f5292e
to
4c060cb
Compare
Coverage of commit
|
…eateDetourMachine`
4c060cb
to
27b4632
Compare
Coverage of commit
|
This used to be #2615 but github thought I closed it >.>
https://github.com/mbta/skate/pull/2607/files#r1608932364