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)

Most upvoted comments

Not overdue, taking a look today 😄

edit: I have a PoC, will share it tomorrow.

what would be the benefit of such strictness?

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.