-
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
Add tooltip for timepoints #452
Conversation
Codecov Report
@@ Coverage Diff @@
## master #452 +/- ##
=======================================
Coverage 97.36% 97.36%
=======================================
Files 153 154 +1
Lines 3527 3532 +5
Branches 461 461
=======================================
+ Hits 3434 3439 +5
Misses 90 90
Partials 3 3
Continue to review full report at Codecov.
|
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.
Not finished reviewing, I'll continue tomorrow, but there's some comments that I didn't want to hold up til I finished.
lib/gtfs/data.ex
Outdated
@spec timepoint_ids_for_routes([RoutePattern.t()], MapSet.t(Route.id()), trips_by_id()) :: | ||
timepoint_ids_by_route() | ||
defp timepoint_ids_for_routes(route_patterns, route_ids, trips) do | ||
@spec all_timepoints_by_id(binary()) :: timepoints_by_id() |
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.
Could/should this function (and/or the timepoints_by_id
type) go in timepoint.ex
instead?
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 don't have strong feelings about this. This is mirroring many other equivalent functions in this module. I thought in the past you had expressed the opinion that these should be here instead of in e.g. Timepoint
, but my memory is vague so I could easily be getting that wrong.
lib/gtfs/stop_time.ex
Outdated
|
||
@type t :: %__MODULE__{ | ||
stop_id: Stop.id(), | ||
time: Util.Time.time_of_day(), | ||
timepoint_id: timepoint_id() | nil | ||
timepoint: Timepoint.t() | nil |
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 stop_time
should still have a Timepoint.id()
. Then in the rare case we need the full timepoint (I think just for getting the list of full timepoints for a route), we look up the ids in a separate table that forms a single source of truth. For most things we do with timepoint ids (e.g. measuring a bus's progress), having an id reference would be slimmer (important since all the stop_times really bog us down) and easier to work with when doing equality checks.
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.
What do you mean by "slimmer" and "bog us down"? I'm not sure I understand the problem you are trying to solve, but adding a store for these and an additional lookup for every vehicle on every update seems pretty expensive when this data is only used as a part of stop times.
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.
The lookup wouldn't happen on every update. The vehicles don't need to know the timepoint names. We only need it for routes. So, once on startup, we would get the %{Route.id() => [Timepoint.id()]}
map as we do on master, then look those up into a %{Route.id() => [Timepoint.t()]}
map.
I guess, after we store the timepoints_by_route, we might not even need to save the full timepoints with names anywhere else.
assets/src/components/ladder.tsx
Outdated
) | ||
})} | ||
</svg> | ||
<ReactTooltip /> |
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.
Does this only have to be included once, or does it need to be near every place where tooltips appear? If we only need it once, it should probably go on <LadderPage>
(if we only want it when tooltips are on the screen) or App
(if it should always be there) instead of on every ladder.
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 is a good thought, but I just tried it and it does need to be in the same component as it's referenced in.
Copied from Slack: That’s not always the normal behavior for a tooltip, but it makes the experience more similar on desktop vs tablet and makes it overall less annoying as you scan around with the cursor. |
Is it possible that it drops any timepoints that aren’t in checkpoints.txt? |
d7877c8
to
55e4c0f
Compare
@ingridpierre I updated it to only pop up the tooltip on click/tap, not on hover. I also set it so that the tooltip pops up in the middle of the timepoint each time, not where you happen to tap on it. The updates are up on dev now, let me know if this behaves more like you were looking for. |
Added a fix to accommodate timepoints with no name. They now appear correctly on the ladder, but no tooltip appears if you try to tap on it. I reported this case to the realtime team. |
3700609
to
164c5ab
Compare
Another small detail - for our desktop users I think it would be kind to show the cursor style change (like hovering over a link), so that you can know where to click down for the tooltip. At the moment I see a text highlight cursor on hover which is not as helpful. |
@ingridpierre Changed the cursor to a pointer. |
c6a8567
to
be9335f
Compare
@ingridpierre I changed the behavior such that when you tap anywhere the tooltip closes (not just on the timepoint name. I think this is probably better behavior anyway and fixes the first bug around opening routes. Unfortunately, it does not fix the second bug as I was hoping it would. How bad do you feel that bug is? If we wrote up a bug ticket and released this as is, do you think that would be ok, or is this issue too detrimental to the experience? At this point I don't have any ideas for how to solve this bug, so I think the continued work could potentially be a lengthy investigation and reworking that could easily take longer than what we've done so far. |
@arkadyan I don't think folks are closing ladders with a terrible frequency. Thankfully with the cookie people don't really have to manage the routes in the picker too often. But when you do encounter it, it's pretty befuddling. I'd definitely still classify it as a gross bug and set it off for later. Will take a look at the new changes to make sure I haven't misspoken. |
@arkadyan lgtm 👍 |
Recorded the bug here: https://app.asana.com/0/1148853526253420/1162700422074841. It is most certainly gross and befuddling |
472161c
to
b8930e6
Compare
@skyqrose Moved the timepoint assignments to be by route pattern. |
b8930e6
to
ca75f09
Compare
@@ -220,23 +218,25 @@ const LadderTimepoint = ({ | |||
y={y} | |||
textAnchor="middle" | |||
dominantBaseline="middle" | |||
data-tip={timepoint.name} |
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.
If the name is missing, this would be null
. Does react tooltip handle that well?
(Not relevant if we decide this comment is a good idea: #452 (comment) )
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.
Yes, you can see this for "CENJF" on route 502: there's no tooltip if there's no content.
def timepoint_for_id(_timepoints_by_id, nil), do: nil | ||
|
||
def timepoint_for_id(timepoints_by_id, id) do | ||
Map.get(timepoints_by_id, id, %__MODULE__{id: id}) |
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.
Instead of my other comments about the frontend handling a missing name, what do you think about creating a default %__MODULE__{id: id, name: id}
, where the id is used as the name for the couple timepoints that we're missing, so we can depend on the name
always being present?
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.
At least for now we've said that we don't want to display a tooltip if there is no name.
Pass full timepoint data to the client-side.
Require the react-tooltip library and types.
It no longer follows your cursor or tap position.
ca75f09
to
a77ffc8
Compare
Asana ticket: Route ladders polish | add timepoint tool tip