-
Notifications
You must be signed in to change notification settings - Fork 45
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: fix selected track display #10394
base: dev
Are you sure you want to change the base?
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
❗ Your organization needs to install the Codecov GitHub app to enable full functionality. Additional details and impacted files@@ Coverage Diff @@
## dev #10394 +/- ##
===========================================
+ Coverage 81.61% 87.50% +5.89%
===========================================
Files 1067 31 -1036
Lines 105535 1537 -103998
Branches 727 0 -727
===========================================
- Hits 86128 1345 -84783
+ Misses 19366 192 -19174
+ Partials 41 0 -41
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
6ebdd08
to
91c86cb
Compare
Signed-off-by: theocrsb <[email protected]>
91c86cb
to
aa9a0a2
Compare
Nice fix ! It also closes #10299, there were duplicates :) |
pathSteps | ||
.map((pathStep, index): MarkerProperties | null => { | ||
const matchingOp = suggestedOP.find((op) => | ||
matchPathStepAndOp(pathStep as PathItemLocation, op) |
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.
Hm, this is dangerous… What is the reason why we can't replace or update MarkerInformation
?
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 just removed the cast
simulationPathSteps={markersInfo} | ||
/> | ||
{infraId && ( | ||
<ScenarioContextProvider infraId={infraId}> |
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 the new code require a scenario context? It seems a bit weird to use something specific to operational studies in STDCM.
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.
As you suggested, I use useCachedTrackSections
instead
simulationPathSteps={markersInfo} | ||
/> | ||
{infra && ( | ||
<ScenarioContextProvider infraId={infra.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.
I don't think it's a good idea to depend on something from another app (operational studies).
We could remove this and in ItineraryMarkers
use the custom hook instead :
const { getTrackSectionsByIds } = useCachedTrackSections(infraId);
If it works, and as useCachedTrackSections
will be used in both operational studies and stdcm, you can move this hook in src/utils/hooks
(in a separate commit probably, before the main one).
Then you should be able to remove ScenarioContextProvider
from here and StdcmResults
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.
Done :)
matchPathStepAndOp(pathStep as PathItemLocation, op) | ||
); | ||
|
||
if (!matchingOp) return null; |
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 me keep reduce
which should allow to handle that case instead of having to do a map
and then a filter
?
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.
Personally I find map
+ filter
more readable than reduce
.
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 was sure you had something to do with 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.
Most I did was nod when Theo suggested to get rid of the reduce :P
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 also find it easier to read
|
||
if (!matchingOp) return null; | ||
|
||
if (pathStep && pathStep.coordinates) { |
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.
pathStep
is always defined
if (pathStep && pathStep.coordinates) { | |
if (pathStep.coordinates) { |
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.
Done
@@ -31,7 +35,8 @@ enum MARKER_TYPE { | |||
} | |||
|
|||
type MarkerProperties = { | |||
marker: MarkerInformation; | |||
op: SuggestedOP; | |||
pathStep: MarkerInformation; |
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.
Doesn't come from you but I still don't like to see a pathStep
associated with a MarkerInformation
type.
In a separate commit, you could rename and update the type MarkerInformation
like this :
type PathStepMarker = Pick<PathStep, 'name' | 'coordinates' | 'metadata'>
if (index > 0 && index < pathSteps.length - 1) { | ||
return { | ||
coordinates: pathStep.coordinates, | ||
type: MARKER_TYPE.VIA, | ||
imageSource: showStdcmAssets ? stdcmVia : viaSVG, | ||
index, | ||
op: matchingOp, | ||
pathStep, | ||
}; | ||
} |
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 from your PR, but you could remove the if
and move the return at the end since if it's not the first or last index, it can only be a via
if (index > 0 && index < pathSteps.length - 1) { | |
return { | |
coordinates: pathStep.coordinates, | |
type: MARKER_TYPE.VIA, | |
imageSource: showStdcmAssets ? stdcmVia : viaSVG, | |
index, | |
op: matchingOp, | |
pathStep, | |
}; | |
} | |
return { | |
coordinates: pathStep.coordinates, | |
type: MARKER_TYPE.VIA, | |
imageSource: showStdcmAssets ? stdcmVia : viaSVG, | |
index, | |
op: matchingOp, | |
pathStep, | |
}; |
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.
Done
@@ -117,70 +162,60 @@ const ItineraryMarkers = ({ map, simulationPathSteps, showStdcmAssets }: Itinera | |||
return formatPointWithNoName(markerLineCode, markerLineName, markerTrackName, markerType); | |||
} | |||
|
|||
if (!markerCoordinates) return null; | |||
const { op } = markerInfo; |
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 we move this logic (no markerMetaData
) directly in extractMarkerInformation
? In the function, we can check if the pathStep
has no name
and no metadata
and add a metadata
to it.
This will allow us not to add this extra op
property in MarkerProperties
and not to have some code duplication getMarkerDisplayInformation
d408ed1
to
b9316ab
Compare
fix #10372
fix #10414