debug client: support stop ids in from / to inputs

[richardkoszegi]

Summary

Added support for location ids in from/to fields in debug client.

Implementation Details:

• Added locationConverter: converts strings to Location objects and back based on LocationStringParser class.
• LocationInputField: a value state introduced for the input field. The new useEffect hook updates this state when location parameter changes. On the onBlur event, this component fires the new onLocationChange event if a valid location can be parsed from the input.
• SearchBar: updates tripQueryVariables based on the changed location.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Please upload report for BASE (dev-2.x@f9ea044). Learn more about missing BASE report.

Additional details and impacted files

@@            Coverage Diff             @@
##             dev-2.x    #6133   +/-   ##
==========================================
  Coverage           ?   69.93%           
  Complexity         ?    17727           
==========================================
  Files              ?     1996           
  Lines              ?    75402           
  Branches           ?     7717           
==========================================
  Hits               ?    52730           
  Misses             ?    19995           
  Partials           ?     2677           

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

[leonardehrenfried]

We talked about it and @t2gran has requested that you look up the coordinate of the stop and place the flag icon on the map. Would that be too much to ask?

I personally like this change but @testower is the React expert and needs to review it.

[richardkoszegi]

We talked about it and @t2gran has requested that you look up the coordinate of the stop and place the flag icon on the map. Would that be too much to ask?

I personally like this change but @testower is the React expert and needs to review it.

I hope it won't be a big change, so it can be implemented in this pr. 🙂

I think I just need to write a stopId -> coordinates resolver using the quay query and call it in the NavigationMarkers component to set the flags.

[testower]

This is perfectly fine pattern, but we have done it slightly differently - passing tripQueryVariables and setTripQueryVariables into the input components, and calling them there. I suggest keeping to this for consistency.

[richardkoszegi]

I moved these functions to the LocationInputField component.

[testower]

I don't understand what this function does. In particular, there seems to be something going on with "name" which seems out of scope.

[richardkoszegi]

These function is the typescript version of the LocationStringParser.java class.

I removed the "name" parsing part.

[richardkoszegi]

I implemented the stopId -> coordinate resolver with the quay query, and it works fine with stops, but not with stop places / stop-areas or any other nodes that have id (eg. vehicle rental stations).

I think it's not the frontend's job to decide, which query has to be called to resolve the coordinates, so it would be nice, if the graphql api has a generic place query, that resolves the coordinates for any id. What do you think about it?

[t2gran]

My knowledge of JS is limited - but it looks like the arguments order is swapped according to the interface definition above. As a practice to avoid errors I like to always do lat, long never long, lat (doc, params, args, execution order and so on).

[testower]

There are still unresolved issues in this PR imho. Maybe need to discuss in developer meeting? Although I'm unable to join until week after next week.