-
Notifications
You must be signed in to change notification settings - Fork 43
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
front: add waypoint menu in manchette #9398
base: dev
Are you sure you want to change the base?
Conversation
Codecov ReportAttention: Patch coverage is
❗ Your organization needs to install the Codecov GitHub app to enable full functionality. Additional details and impacted files@@ Coverage Diff @@
## dev #9398 +/- ##
============================================
- Coverage 39.09% 39.05% -0.05%
Complexity 2267 2267
============================================
Files 1308 1309 +1
Lines 99164 99245 +81
Branches 3312 3313 +1
============================================
- Hits 38771 38756 -15
- Misses 58430 58525 +95
- Partials 1963 1964 +1
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
e76334c
to
89acc1b
Compare
Signed-off-by: SharglutDev <p.filimon75@gmail.com>
89acc1b
to
accef67
Compare
- When clicking on a waypoint in the manchette, display a menu with some actions - Only action for now is to hide the waypoint in the manchette Signed-off-by: SharglutDev <p.filimon75@gmail.com>
accef67
to
589c8f7
Compare
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.
Overall I'm not a huge fan of having the menu outside of ui-manchette. IMHO the positioning and styling of the menu belongs to osrd-ui.
I'm especially concerned about the positioning logic which is quite fragile: it hardcodes a lot of assumptions about the manchette, and desynchronizes when elements move around. Example bug: zoom in the manchette, open the menu, and then scroll. This is just one example, other interactions may break the menu alike.
@@ -9,10 +9,11 @@ export type OSRDMenuItem = { | |||
type OSRDMenuProps = { | |||
menuRef: React.RefObject<HTMLDivElement>; | |||
items: OSRDMenuItem[]; | |||
style?: React.CSSProperties; |
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 this is exposed to allow callers to position the menu, should we instead add a position
property? That would deter callers from (ab)using style
for things which should stay in CSS files.
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 also need to set the width, it's not always the same depending of who's calling the menu. I made the call to pass this props instead of pass width
and position
. You would prefer that ?
@@ -7,10 +7,12 @@ import { ConflictLayer, PathLayer, SpaceTimeChart } from '@osrd-project/ui-space | |||
import type { Conflict } from '@osrd-project/ui-spacetimechart'; | |||
|
|||
import type { OperationalPoint, TrainSpaceTimeData } from 'applications/operationalStudies/types'; | |||
import WaypointMenu from 'common/OSRDMenu'; |
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.
Should this be named OSRDMenu
? It's a bit confusing to rename on import when there are no naming conflicts.
menuRef={waypointMenuData.menuRef} | ||
items={waypointMenuData.menuItems} | ||
style={{ | ||
width: '305px', |
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 we move this to a CSS file?
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 would require a div wrapper as the width it's not always the same when calling the menu. I'm not a huge fan of that. How would you do ?
onClick: (id: string, ref: HTMLDivElement | null) => { | ||
waypointMenuData.handleWaypointClick(id, ref); | ||
}, |
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.
Nit: can be simplified to:
onClick: waypointMenuData.handleWaypointClick,
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 good point, done
setMenuPosition(undefined); | ||
setActiveOperationalPointId(undefined); | ||
if (filteredWaypoints && setFilteredWaypoints) { | ||
setFilteredWaypoints( |
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 racy, because another update to filteredWaypoints
could be pending. Instead, setFilteredWaypoints
can take a callback which mutates the current value:
setFilteredWaypoints((filteredWaypoints) => filteredWaypoints.filter(…));
As a bonus, this removes the need to pass filteredWaypoints
as a prop.
import useOutsideClick from 'utils/hooks/useOutsideClick'; | ||
|
||
const SPACETIME_CHART_HEADER_HEIGHT = 40; | ||
const WAYPOINT_MENU_OFFSET = 2; |
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 could be a CSS margin instead.
setMenuPosition(undefined); | ||
setActiveOperationalPointId(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.
We could call closeMenu
here instead.
Actually, maybe this coule be used instead? https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_anchor_positioning/Using |
close #8629
Mockup :
https://www.sketch.com/s/a26d84be-5fb2-41e4-9e84-96d90f46a997/a/OeJV9yG
Note
Because of this issue : OpenRailAssociation/osrd-ui#654, some styles have been fixed here but should be removed when this issue will be closed.