Read URL Search Params / Query String and pass into fetch request

[ch-dg]

Hi all. Very simple landing page, thought it would be a good place to start playing with HTMX. Forgive me if I ask sth. very stupid. The objective is really simple:

Landing page with a query string in the URL. onLoad it fires a request to server, sending the params from the query string along. Server does its thing and sends back a success or error HTML snippet.

I do not need a button or form, all the info I need comes from the queryString. Users get redireted to this page from another app.

Question 1: How can I get the searchParms into the hx-get?

I must be missing something but I couldn't find any other way than using some JS.

HTMX:

      <div
        hx-get="https://jsonplaceholder.typicode.com/users"
        hx-vals="js:{id: id, comment: comment}"
        hx-trigger="load"
        hx-target="#result"
      ></div>
      <div id="result" class="m-8 p-8 bg-slate-200">Loading…</div>

JS:

  <script>
    function getParams() {
      // const urlParams = new URLSearchParams(window.location.search);
      const urlParams = new URLSearchParams('id=4&comment=25');
      const id = urlParams.get('id');
      const comment = urlParams.get('comment');

      return { id: id, comment: comment };
    }

    const { id, comment } = getParams();
  </script>

Sample:

https://stackblitz.com/edit/stackblitz-starters-9z2kgg?file=index.html

Question 2; I would have thought the entire idea behind HTMX was that for the very largest part I don't need to write the JS.
Or is this a case where I would look at Hyperscript?

Question 3: hx-trigger="load" on a div looks odd to me, surely that's not eactly how it's thought to be done?

In production I would of course do the entire parsing of the queryString and writing the HTML response in the backend - but for that I need to get the params from the queryString back there first. What am I missing?

Thanks :)

[ch-dg]

I'm surprised no-one could help with this.

After digging into this I would like to present a more elegant solution:

HTMX adds additional headers to HTTP request headers. You can inspect these and tailor your response. In particular the "HX-Current-URL" is of interest here.

If you don't serve from or have access to your web server directly and interact with and/or have access to an endpointyou can read the request url from this additional header HTMX appends:

const requestUrl = request.headers.get("HX-Current-URL")!;

And you can then extract the query string, in this example "id":

const postId = new URL(requestUrl).searchParams.get("id");

And then append the "id" to your fetch call, e.g.:

const res = await fetch(
  `https://jsonplaceholder.typicode.com/posts/${postId}`
);

This way on page load you can feed the query string variables from your current URL into a fetch call to any API.

<div hx-get="/api/getPost" hx-trigger="load" hx-target="#result"></div>
<div id="result" class="m-8 p-8 bg-slate-200">Loading…</div>

Hope this helps someone coming across the same problem.

[zw963]

Hi, @ch-dg, where is the request object come from?

Sometimes, only get request params from backend is not necessary, especially, when hx-push-url is concerned, it change the url, but, we can't get the expected request params if use hx-vals, following is a example:

input(
      type: "search",
      value: "#{context.request.query_params["q"]?}",
      name: "q",
      class: "s12 m8 input-field",
      placeholder: "输入大学名称模糊搜索",
      "hx-get": "/universities",
      "hx-target": "#main",
      "hx-select": "#main",
      "hx-trigger": "search, keyup delay:400ms changed",
      "hx-push-url": "true",
      "hx-include": "[name='is_985'],[name='is_211'],[name='is_good']",
      "hx-vals": "{\"batch_level\": \"#{context.request.query_params["batch_level"]?}\"}"
    )

This input element not within the #main, it never refresh when typing Chinese use input method, this cause the context.request.query_params["batch_level"] always get the unexpected old value which come from the last page full refresh.

[Telroshan]

Hey,

In production I would of course do the entire parsing of the queryString and writing the HTML response in the backend

Yep, that's exactly it! I'm not sure I understand the situation here, more precisely ; why can't you do this on the backend? It seems convoluted indeed to use a hx-trigger="load" because then you could just have your server do the expected logic in its initial request handler, instead of rendering a HTML page that instructs the client to go back to that same server to do more stuff ; why not make both things server-side during the initial request? That way you wouldn't have to bother at all.

I know you said "If you don't serve from or have access to your web server directly" but I'd be curious to know more about that, what's the situation exactly?

[ch-dg]

Thanks for taking the time to reply :)

In this particular case this was for a demo with hardly any backend in place.

The scenario was the following, I had 2 givens:

1. A user clicks a button in an email to confirm a choice, gets taken to a landing page (the page I built) and relevant data is appended via query string
2. I was given an endpoint which would receive this data, do its thing, and return a success or failure

Email was sent by a 3rd party provider working on our behalf.

Endpoint was prepared by another team for us, I literally only had the endpoint, no access to any other architecture.

The page itself was just running on my localhost.

Only solution: when page loads, parse query string, create payload to send to API and if returns success display some HTML, and have a fallback for the rare cases where sth. may have got stuck.

If I used a React app I would load the page, run a useEffect to parse the string and make the query, update a state variable to reflect response and show the relevant update on the page.

Or in a newer version of React or sth. like Astro I would do this in a server component without needing the dreaded useEffect and just parse “params” and “searchParams” - which is essentially doing it in the backend before serving the page.

Both of the latter are overkill for such a small thing.

So, just a static HTML page with some JS at the bottom parsing the string and doing all of the above, then swap out some HTML or create a new dom node with the success/failure message.

OR

I would try HTMX and see if I can replicate any of the above and learn a bit about HTMX!

Maybe this wasn’t the best use case to get started with HTMX :)

In the meantime I have received access to the webserver and lambda functions and I can just parse query string and return the entire HTML page, or snippets to insert into a template - as you suggest, no need for any of the above shenanigans. But while I was constrained by access limitations I needed to send some data to an endpoint on page load.

I can see other use cases like this. E.g. I may have a static HTML page hosted on GoDaddy. When it loads I want to display a list of 80s movies, or 90s, or 2000s - depending on where I come from. I get this data from a 3rd party endpoint.

So when page loads I need to send a query to that endpoint to populate my page with the relevant data and I may need to fetch the params from the query string.

Or another scenario: I may want to pass a link to my portfolio page to a customer but want to direct him to a particular version of my portfolio. My portfolio sits on Behance, I just pull the bits I need into my page by querying the Behance API. Therefore on page load I fetch query string params and ask Behance to return the relevant portfolio items tailored to this customer..

Again I have no backend, I’m just a guy with a web page hosted on some run of the mill mass host accessing an API.

I’m sure there are plenty of similar use cases with the above limitations?

Thanks again for your time :)

[Telroshan]

Thanks for the details!

Maybe this wasn’t the best use case to get started with HTMX :)

Yeah I don't think it's an ideal usecase indeed, I wouldn't recommend htmx in a context where you don't have access to the backend anyway

I get this data from a 3rd party endpoint.

I'd recommend reading this essay : Web Security Basics (with htmx), but TL;DR : one of the most important tip we suggest is:

Only call routes you control

The reason for this is simple: htmx inserts the response from that route directly into the user’s page. If the response has a malicious <script> inside it, that script can steal the user’s data. When you don’t control the route, you cannot guarantee that whoever does control the route won’t add a malicious script.

That being said, it's ok if you do it if you know what you are doing, but I hope you'll understand that this is not the kind of usecase we'd want to push to the forefront, as it could lead to major security issues.

[ch-dg]

That makes sense! Thanks very much, that also makes me understand better where you are coming from.

I already have a follow up project, also very simple, were user interaction is key and I now have full access to the route - so I'll be having a little more fun with this :)