feat: search trips #11
Conversation
|
@rosvik Lemme know if you think I should improve things in this PR or take it up in a follow up 🙌 |
|
@binarybaba I've been wanting to add trip search to the extension for a while now, but never gotten around to it, so I really appreciate you making this 💯 I've played around with it a bit now, and it works great! I'm looking over the code, and will get back to you ASAP with some minor comments. For now, I wonder if you agree that we can make one simplification on the flow (from #10):
This far, I've thought that the most common use case for the extension would be users that need a quick way to check when the next bus/tram would leave a nearby stop. (e.g. someone about to leave work and want to see if their bus is delayed) Which I think is where Raycast shines: as a fast way to get info, and not necessarily the most feature complete solution. No way we can compete with entur.no on the amount of features, but we might be able to compete on ease of use and speed 🔥 So with this in mind, I think we should drop the settings page, and just have
Maybe there are ways to fit the reverse and time selection options on the results page, with a Dropdown in the search bar to select departure time and an Action to flip direction. |
There was a problem hiding this comment.
First of all, this is so cool! I love that you were able to fit most of a travel planner in a quite simple Raycast command ✨ I did spot a few points that can be improved, but I'm exited about merging this and and iterating on it further. Initially, I think I'll publish this as a private extension at my org, so I can get feedback from colleagues before it's sent to the Raycast Store.
In addition to the comments below, I noticed there are a few linting issues that can be fixed automatically by running npm run lint -- --fix.
binarybaba
force-pushed
the
feat/plan-journey
branch
from
d712e09 to
32f57d4
Compare
binarybaba
force-pushed
the
feat/plan-journey
branch
from
32f57d4 to
be13648
Compare
|
Getting rid of the details screen suddenly made so much more sense. Feels more inline. 🙌
So I have removed them completely. |
| ]; | ||
| } | ||
| const accessories: Accessory[] = trip.legs | ||
| .filter((leg) => !(leg.mode === "foot" && leg.fromPlace.name === leg.toPlace.name)) |
There was a problem hiding this comment.
It's more precise to use stop ID for this. (We should be able to fetch id instead of name in the query)
| .filter((leg) => !(leg.mode === "foot" && leg.fromPlace.name === leg.toPlace.name)) | |
| .filter((leg) => !(leg.mode === "foot" && leg.fromPlace.id === leg.toPlace.id)) |
There was a problem hiding this comment.
id unfortunately doesn't exist in Place. It seems Place in Leg doesn't implement PlaceInterface
StopPlace does implement PlaceInterface. 🤔
There was a problem hiding this comment.
Ah, my bad. We'll have to use fromPlace.quay.stopPlace.id then. (quay.stopPlace gives the parent stop place of the quay)
There was a problem hiding this comment.
I'll pick this one up soon!
binarybaba
force-pushed
the
feat/plan-journey
branch
from
ecf5c06 to
0b569ec
Compare
Helps user to plan a journey - page: search origin - page: search destination - page: list trips (with details) This is for people like me who likes to check commute distance very frequently. While writing this, a lot of code was duplicated from the original `SearchPage`. There is a serious need for refactor. I didn't want to do it straightaway and risk touching other parts of the code as well. However, if this feature is merged, we could ideally create a standalone generic enough search page which: - only searches for venue - gets Primary action from parent, - gets all other actions from a common file (so all commands can have the same common actions for consistency) - possibly use inbuilt throttle of `List` resolves rosvik#10
binarybaba
force-pushed
the
feat/plan-journey
branch
from
0b569ec to
428c6c9
Compare
Helps user plan a journey
This is for people like me who likes to check commute distance very frequently.
Screenshots
implements #10