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

front: fix selected track display #10394

Open
wants to merge 3 commits into
base: dev
Choose a base branch
from

Conversation

theocrsb
Copy link
Contributor

@theocrsb theocrsb commented Jan 15, 2025

fix #10372
fix #10414

@github-actions github-actions bot added the area:front Work on Standard OSRD Interface modules label Jan 15, 2025
@codecov-commenter
Copy link

codecov-commenter commented Jan 15, 2025

⚠️ Please install the 'codecov app svg image' to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 87.50%. Comparing base (9ddc06c) to head (0b3c5f8).
Report is 30 commits behind head on dev.

❗ 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     
Flag Coverage Δ
editoast ?
front ?
gateway ?
osrdyne ?
railjson_generator 87.50% <ø> (ø)
tests ?

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@theocrsb theocrsb force-pushed the tce/front/bug-wrong-track-display branch 7 times, most recently from 6ebdd08 to 91c86cb Compare January 16, 2025 17:14
@theocrsb theocrsb marked this pull request as ready for review January 16, 2025 17:20
@theocrsb theocrsb requested a review from a team as a code owner January 16, 2025 17:20
@theocrsb theocrsb force-pushed the tce/front/bug-wrong-track-display branch from 91c86cb to aa9a0a2 Compare January 17, 2025 08:25
@RomainValls
Copy link
Contributor

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)
Copy link
Member

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?

Copy link
Contributor Author

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}>
Copy link
Member

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.

Copy link
Contributor Author

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}>
Copy link
Contributor

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

Copy link
Contributor Author

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;
Copy link
Contributor

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 ?

Copy link
Member

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.

Copy link
Contributor

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 😏

Copy link
Member

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

Copy link
Contributor Author

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) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

pathStep is always defined

Suggested change
if (pathStep && pathStep.coordinates) {
if (pathStep.coordinates) {

Copy link
Contributor Author

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;
Copy link
Contributor

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'>

Comment on lines 97 to 106
if (index > 0 && index < pathSteps.length - 1) {
return {
coordinates: pathStep.coordinates,
type: MARKER_TYPE.VIA,
imageSource: showStdcmAssets ? stdcmVia : viaSVG,
index,
op: matchingOp,
pathStep,
};
}
Copy link
Contributor

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

Suggested change
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,
};

Copy link
Contributor Author

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;
Copy link
Contributor

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

@theocrsb theocrsb force-pushed the tce/front/bug-wrong-track-display branch from d408ed1 to b9316ab Compare January 17, 2025 11:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:front Work on Standard OSRD Interface modules
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Intinerary marker not always defined Inconsistency between the selected track and the track displayed
5 participants