App: [$250] [Cleanup] Utility URL type for getURLWithBackParam, etc...
Coming from https://github.com/Expensify/App/pull/31543#discussion_r1405420130…
Problem
We’ve got some types that look like this:
function getUrlWithBackToParam<TUrl extends string>(url: TUrl, backTo?: string): `${TUrl}` | `${TUrl}?backTo=${string}` | `${TUrl}&backTo=${string}` {
...
}
and while that works it’s a pretty verbose way to express a pretty common format for something.
Solution
This is a rich representation of what this string could / should look like, instead of just being string, but let’s clean this up to make it more extensible/reusable. We should make a utility type for URLs that takes:
- A base URL
- an object type representing a series of optional or required query params (which of course can be in any order)
Then the resultant type would be any string matching the pattern of a valid URL with the correct base and query params.
Upwork Automation - Do Not Edit
- Upwork Job URL: https://www.upwork.com/jobs/~01ab405b1ad68ca814
- Upwork Job ID: 1729557018701299712
- Last Price Increase: 2023-11-28
About this issue
- Original URL
- State: closed
- Created 7 months ago
- Comments: 20 (11 by maintainers)
Not overdue, taking a look today 😄
edit: I have a PoC, will share it tomorrow.
My thinking is that you’d be unable to pass unexpected params or miss required params when navigating to a screen. But it sounds like I’m alone in thinking this would bring any additional value, so I’ll trust you guys and close this out.
@blazejkustra I think your solution is enough for our use cases, I don’t see too much value in being super explicit about the query params in the string type, just
${TUrl}?${string}seems to be sufficient.@hamzasaleem2 I’ll work on this, as Rory mentioned here. Just need a little more time as I have some other priorities atm.