[✨] Support to RequestEvent from useResource$ hook as an optional parameter.

[iamriajul]

Is your feature request related to a problem?

Yes, I'm facing a problem where I've two different API URLs for the same API Service, one URL is public-network facing and the other one is local-network facing.
And now when I use the useResource$ hook which runs on both server (within local-network) and client (within public-network) If the hook runs on the server then I need to access the following to do conditional fetch request: req.env.get('API_URL').
SSR Mode: req.env.get('API_URL')
CSR Mode: import.meta.env.PUBLIC_API_URL

But because I can't RequestEvent object in the useResource$ hook I can't do those conditionals API URL choosing based on SSR and CSR mode.

Describe the solution you'd like

I would like to have access to the RequestEvent or RequestEventBase object instance optionally as useResource$'s callback parameter.
Use Case 1:

const user = useResource$((ctx, req) => {
    const apiUrl = req?.env.get('API_URL') || import.meta.env.PUBLIC_API_URL;
    // Notice: I'm using the `?` null coleasing operator. I hope it also works with undefined.
    return fetch(`${apiUrl}/v1/user`).then(res => res.json());
});

Use Case 2:

const token = useResource$((ctx, req) => {
    return req?.cookie.get('token') || jsCookie.get('token');
});

Describe alternatives you've considered

routeLoader might be an option but that is currently inefficient for this kind of task in my opinion.

For example for Use Case 1:
I might get the LOCAL API URL (from req.env.get('API_URL') using routeLoader which is kinda weird because in SPA navigation the routeLoader will called but that value no use in CSR Mode / SPA mode. and also kinda exposes the LOCAL API URL to the public source code.

For example for Use Case 2:
I might get the token (from req.cookie) using routeLoader which is okay, but when navigation is happening in SPA mode with CSR rendering I already have access to document.cookie which is enough for me to have cookie in place for me to use. So in SPA navigation, the routeLoader network call is wasted.

Additional context

No response

[mhevery]

Ohh, that is an interesting idea. So we have this in server$ as well. I think we could do something like this.

const token = useResource$(function(this: nul | RequestEvent, ctx, req) {
    console.log(this ? 'Server': 'Client');
    return req?.cookie.get('token') || jsCookie.get('token');
});

Would you be interested in creating a PR fix for this? See server$ for inspiration as it already has this argument. I would be happy to guide you through it.

[iamriajul]

Thanks for the hint about server$, I wonder if server$ can be combined with useResource$ to achieve what I wanted.

Use Case 1:

// Top-level function
const getApiUrlSsr = server$(async function() {
  return this.env.get('API_URL');
});

// Component-level hook
const user = useResource$(async ctx => {
    const apiUrl = isServer ? await getApiUrlSsr() : import.meta.env.PUBLIC_API_URL;
    return fetch(`${apiUrl}/v1/user`).then(res => res.json());
});

Use Case 2:

// Top-level function
const getTokenSsr = server$(async function() {
  return this.cookie.get('token');
});

// Component-level hook
const token = useResource$(async ctx => {
    return isServer ? await getTokenSsr() : jsCookie.get('token');
});

Does this work? I'll try soon to test it out.

If this solution works, then I think we don't need to necessarily change the API of useResource$.
And also if the solution works then we need to point it in the documentation to make easier for new users to adapt easily.

Thanks.

[iamriajul]

Also, I think just passing this: null | RequestEvent doesn't hurt any user-facing API really!
Having this: null | RequestEvent with useResource$ and useTask$ is a great plus without having to complicate simple use cases!

For example, those who need access to RequestEvent | null just need to change their arrow function to full-function! That is just it without many changes! or breaking changes for users!

What's your opinion?

[iamriajul]

Qwik AI is awesome for clarifying simple questions.

[mhevery]

I like your idea. I think all tasks functions could have this and it would not break anything.

Let me know if you are up for doing the work. Happy to guide you along.

[iamriajul]

I would be happy to contribute, but will be able to start next month.
Any guides would be helpful of course.

[iamriajul]

Wondering one thing, how can we make the import the same, as currently useResource$, useTask$ imports from @builder.io/qwik but when need to integrate some server things that can only be done inside @builder.io/qwik-city

[mhevery]

Hmm! That is a good point. Qwik cant depend on qwikcity. Maybe there is a simpler request interface which is not Qwik city specific but only platform specific?

[gioboa]

We moved this issue to qwik-evolution repo to create a RFC discussion for this.
Here is our Qwik RFC process thanks.