Passing additional params/data to routes?

[stefanisarie]

Hey all!

I'm new to Remix/React router thus the confusion for me... My case is as follow: I have a list of items like this:

{
  "data": [
    {
      "id": 1,
      "internal_id": 5487,
      "name": "some name 1"
    },
    {
      "id": 2,
      "internal_id": 7158,
      "name": "some name 2"
    },
    {
      "id": 1,
      "internal_id": 58963,
      "name": "some name 3"
    }
  ]
}

I am loading this data in a page/route, lets say "/", where I build some links to each entry, using the following file structure inside my "/app/routes/$internal_id/$name.js". In "$name.js" I want to query data by "id" instead of "internal_id" key. How do I pass additional/arbitrary params or data to routes?

Basically, I want my routes to look like: https://somehost.com/:internal_id/:name but when some user is calling that route, I want to query loader by "id".

Hope it makes sense :)

Thank you!

[kiliman]

Since loaders are independent, you will either need to pass the actual id to your $name route (via search params), or query data by internal id, to get the id, then query by id.

Option 1

// list.tsx
<Link to={`${internal_id}${name}?id={id}`>${name}</Link>

// $name.tsx
export const loader: LoaderFunction = async ({request}) => {
  // url = /some_internal_id/some_name?id=some_id
  const url = new URL(request.url)
  const id = url.searchParams.get('id')
  const data = await queryById(id)
}

Option 2

// list.tsx
<Link to={`${internal_id}${name}`>${name}</Link>

// $name.tsx
export const loader: LoaderFunction = async ({request, params}) => {
  // url = /some_internal_id/some_name
  const { internal_id } = params
  const item = await queryByInternalId(internal_id)
  const data = await queryById(item.id)
}

[stefanisarie]

Hey @kiliman !

Thank you for your answer! I would go with the second option as you suggested!

[kiliman]

If you think of your URL routes as function calls, then your arguments are either URL params or search params. Then you can typically figure out what values to send and how to get the data you need.

[JTMax1]

Since loaders are independent, you will either need to pass the actual id to your $name route (via search params), or query data by internal id, to get the id, then query by id.

Option 1

// list.tsx
<Link to={`${internal_id}${name}?id={id}`>${name}</Link>

// $name.tsx
export const loader: LoaderFunction = async ({request}) => {
  // url = /some_internal_id/some_name?id=some_id
  const url = new URL(request.url)
  const id = url.searchParams.get('id')
  const data = await queryById(id)
}

Option 2

// list.tsx
<Link to={`${internal_id}${name}`>${name}</Link>

// $name.tsx
export const loader: LoaderFunction = async ({request, params}) => {
  // url = /some_internal_id/some_name
  const { internal_id } = params
  const item = await queryByInternalId(internal_id)
  const data = await queryById(item.id)
}

This unfortunately does not work for me, in fact, am about to open an issue concerning this, as it seems anytime!! ... and I mean anytime!! my URL has an "#" symbol in it everything breaks down ... ... ...

[-] - "URLSearchParams" becomes useless, won't see anything after the "#", initially thought it was a "loaders/action" thingy, then ...
[-] - tried "useSearchParams" on the client, yep, you guessed it, still nothing ... it just fails to pick anything after the "#" symbol ...
then I decided to try the master of generic matching:
[-] - "SPLAT ROUTES", and I was actually confident that I had found a viable solution, but then again, I was in for a rude awakening,
even "splat routes" fail to recognize anything after the "#" symbol! ... and there and then I gave up on what I was trying to
achieve, and there was no way for me to "correctly" and "completely" implement SUPABASE's EMAIL SIGNUP VERIFICATION, as
the redirect URL always comes in the form of http://localhost:3000/verify?#access_token=bunch_of_base64_gibberish&type=signup&other_query_parameters_i_dont_remember.

e.g

Using http://localhost:3000/login/verify?error_code=404&error_description=Confirmation+Token+not+found everyone is happy (depicted below), even "URLSearchParams" works.

But introduce the # symbol to the URL: http://localhost:3000/login/verify?#error_code=404&error_description=Confirmation+Token+not+found and chaos ensues, nothing picks whatever is after the # symbol, everyone is suddenly blind, it's like # wraps everything after it in an invisibility cloak, and even "SPLAT ROUTES" outright don't work.

NOTES.

[-] I know that "URLSearchParams" according to MDN and personal testing won't pick up any query/search(whatever lingo you pick) parameters after the # symbol, but in those cases, according to MDN and personal testing, ( new URL(location.href) ).hash should work, and should produce #error_code=404&error_description=Confirmation+Token+not+found basically, captures whatever follows the # symbol in the URL, but NOPE ... nada, running that code in my remix "loader" produces nothing. I later realized that the "request" parameter passed to my "loader" doesn't even include the complete URL anytime there's a "#" symbol in the URL.
[-] The workaround of last resort is:

if (isBrowserEnvironment) {
        let urlHash = ( new URL(location.href) ).hash;
        if (urlHash && ( urlHash.startsWith("#access_token") || urlHash.startsWith("#error_code") ) ) {
            // Logic goes here
        };
   }

which I am not happy about, why?, 1 well what I want to do is simple enough that I shouldn't need to resort to this, according to https://remix.run/docs/en/v1/api/conventions#splat-routes, and 2 the fact that it is something that's trivially simple to achieve using web standards [MDN](https://developer.mozilla.org/en-US/docs/Web/API/URL/hash) (a core remix design philosophy) seems like something to be concerned about, now you might be tempted to say "but you still used web standard to reach a "solution" as evident in your code above", yes, true, well said, good catch ... ... ... but I would have loved this piece of the code to be server-side, not client-side, as the // Logic goes here part entails sensitive eish, keys, DB access, Auth, etc. things that have no bussiness being on the client side, why can't I do same server-side you ask??, well ... again ... the "request" parameter passed to my route's remix "loader" doesn't include the complete URL anytime there's a "#" symbol in the URL, it just truncates and since you can't do location.href server-side ... ... ... yea ... .

[-] No it's not a version thing ... opened up a new project instance and updated(1.5.0, 1.5.1) every remix dependency and yep, still persists.

[-] I might just be dumb and doing something wrong ... who knows ... although I doubt it ... the dumb part especially.

[kiliman]

The location.hash only works on the client. The browser will never send it to the server.

I had to deal with this when implementing Supabase authentication with magic links. Basically I check for the hash on the client, then navigate to a login route (converting the hash to search params):

// routes/index.tsx
export default function Index() {
  const location = useLocation();
  const navigate = useNavigate();

  // handle redirect from supabase auth
  useEffect(() => {
    if (location.hash.startsWith("#access_token=")) {
      navigate(`/login?${location.hash.slice(1)}`, { replace: true });
    }
  }, [location, navigate]);
  ...
}

// routes/login.tsx
export const loader = async ({ request }) => {
  const url = new URL(request.url);
  if (url.searchParams.get("access_token")) {
    const cookies = await getAuthCookies(request);
    return redirect("/", { headers: [...cookies] });
  }
  return null;
};

[kiliman]

P.S. In the future, it would be best to create a new discussion with a link to the related one. Especially on one that has already been answered. Otherwise, people may skip it since it was "answered". I just happened to see this.