fix(iosApp.NearbyTransitView): Don't reset nearby when stops reordered #921
Conversation
872a714 to
9b30fc5
Compare
| @@ -70,7 +77,7 @@ struct NearbyTransitView: View { | |||
| .onChange(of: location) { newLocation in | |||
| getNearby(location: newLocation, globalData: globalData) | |||
| } | |||
| .onChange(of: nearbyVM.nearbyState.stopIds) { nearbyStops in | |||
| .onChange(of: setOfNearbyStopIds) { nearbyStops in | |||
There was a problem hiding this comment.
it may be nicer / more testable to test the set equality of the previous & current value for nearbyStops, will try that out too
a682d64 to
783cae4
Compare
| scrollToTop() | ||
| .onChange(of: nearbyVM.nearbyState.stopIds) { [oldValue = nearbyVM.nearbyState.stopIds] newNearbyStops in | ||
|
|
||
| if Set(oldValue ?? []) != Set(newNearbyStops ?? []) { |
There was a problem hiding this comment.
this is a little icky, but it makes it easier to write a test.
|
Didn't fix the issue |
Co-authored-by: EmmaSimon <emmamaysimon@gmail.com>
…onChange for testability
…stance filter to prevent jittery nearby refetching
2d357bb to
f950655
Compare
|
This does in fact fix the scrolling issue issue when the group by direction flag is on. Updated to apply the same distance filter in android as ios for consistency. |
b333ffd to
bd97c1e
Compare
|
@EmmaSimon I tried it out walking around the block and it definitely made the difference, great call! I still think 10m is reasonable based on the amount of wobble I see at my desk locally (and is at least better than the 100m now on android), but agree we can revisit this value once it is in staging! |
Co-authored-by: EmmaSimon <emmamaysimon@gmail.com>
bd97c1e to
a702dc7
Compare
Summary
What is this PR for?
No ticket, addresses issue raised in slack where there have been some reports of nearby transit auto-scrolling to the top of the sheet when there are stops ~equidistant nearby.
iOS
android
withContext(Dispatchers.Default)where possible (ideally in shared code)Testing
What testing have you done?