New Search UI #55
New Search UI #55
Conversation
aaronbrethorst
force-pushed
the
route-box
branch
from
6d79871 to
0bae362
Compare
|
Done |
There was a problem hiding this comment.
@Ahmedhossamdev I think this is looking great! The one big change I'd like to see here is for you to move the switch driven logic for determining behavior depending on Google Maps or OSM into the map provider files GoogleMapProvider.js and OpenStreetMapProvider.js using a common 'interface'.
src/components/map/MapView.svelte
Outdated
| if (showRoute && selectedRoute) { | ||
| if (selectedRoute && !showRoute) { | ||
| allStops = []; | ||
| // Add stops to show |
There was a problem hiding this comment.
Is this comment still relevant? in other words, does it reflect a change that still needs to be made, or can the comment just be deleted?
There was a problem hiding this comment.
It can be deleted now, but I was thinking that instead of deleting all the stops, we should keep the state of the stops before the search so that when the user finishes the search, the stops reappear. However, I was also considering that we will have a cache, so this shouldn't be a problem.
Nice idea; I will refactor it |
…he unused mapSource variable
…eatePolyline function from googleMaps file
|
Hello @aaronbrethorst, I’ve encapsulated everything in the code now. The stop markers and info windows are properly managed within the GoogleMapProvider and OpenStreetProvider classes. Both adding and removing stop markers, as well as handling the info windows, are now fully self-contained. Please feel free to review and let me know if there’s anything else you’d like to adjust. |
|
@Ahmedhossamdev I see a couple merge conflicts on this PR. Can you resolve them? Let me know if I can help you with that. |
|
Done |
Remaining Tasks