Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extension to refresh hrefs of anchors with the actual URL used for the Ajax call #1261

Closed
wants to merge 1 commit into from

Conversation

jyrimatti
Copy link
Contributor

Extension that refreshes href attributes of anchor elements having hx-get attribute, with the actual URL used to make the Ajax call.

Refreshing is made by default on "init" (initialization) and "mouseover" event. These events can be changed by listing them in closest refresh-href -attribute, separated by comma.

This solves three problems:

  1. Browsers don't consider anchors without href as links. Thus it was necessary to write some href attribute even if hx-get was always used instead.
  2. Browsers show href of an anchor when hovering on them. If the url is constructed dynamically (for example using hx-params or hx-include), the shown URL would be incorrect (not the one that would actually get invoked).
  3. Browsers offer a possibility to open links in new tab/window through the context menu (e.g. "Open link in new tab"). The value of href is used for this, no Htmx involved, thus opening different page that would be shown if the link was clicked the normal way.

This extension is implemented by initiating a bogus ajax request with Htmx, but interrupting it before actually invoking it. This is a bit hackish, and it would be nicer if Htmx offered some kind of an API method to get the final URL that would be used for a request.

What do you think? Any suggestions for improvement? Any potential edge cases to consider?

@Telroshan
Copy link
Collaborator

Hey, maybe is it a stupid question, but why would you not write the URL in the href attribute directly in that case?
Given that it's up to the user to implement or not a full page response to allow an independant URL access (thus the "open in new tab" mechanism), I would say you might either not use a link at all (and for ex use a button styled like a link) if you don't support it, or explicitly define the href value to be identical to the hx-get one if you support partial + full page responses

Does it really prevent the verbosity due to duplicating URLs between 2 attributes (href and hx-get here) given that you would have to add hx-ext="refresh-href" to your links anyway?

@Telroshan Telroshan added the extension Consideration for an extension label Sep 20, 2023
@jyrimatti
Copy link
Contributor Author

Hi,

there are no stupid questions :)

why would you not write the URL in the href attribute directly

Because I don't know the URL since it is constructed dynamically.

I don't have a public example, but consider for example that you'd like to provide a list of links to pages showing different things of a "product". The user could select the product with a select box and Htmx can be used to include the value to the link elegantly and without any scripting.

Have a look at a dummy example here:
It otherwise works, but link targets show wrong, and open-in-new-tab opens a wrong page.

Instead consider the same with the extension:
Now everything works, and as a bonus I don't have to write dummy href attributes.

@Telroshan
Copy link
Collaborator

Oh ok thanks I see, I had missed the hx-include test indeed, I understand the usecase now, makes sense to me

@alexpetros
Copy link
Collaborator

This is super cool! While I don't think we can officially support it, I definitely suggest that you publish it on your own GitHub. I would also be open to potentially signal-boosting it with a 3P extensions list as well.

While I understand the use-case, I'm not sure that dynamically (and silently) updating links is a good fit for the core competencies of htmx, which is primarily concerned with replacing elements based on server responses. The default htmx way to do this would be to just replace the entire container with a new DOM element, and new links.

I'm sure there are htmx users that would want to extend htmx to do this kind of client-side munging, and that's a good fit for an extension, but probably not an officially supported one.

@jyrimatti
Copy link
Contributor Author

I published this extension in npmjs: https://www.npmjs.com/package/htmx-refresh-href

I'm not sure about the idea to maintain a list of 3rd party extension, but would it be a good idea to decide and advertise an "official" keyword and maybe package naming style for extensions in npmjs so that they could be easily found and automatically listed? I just prefixed the package name with "htmx-" and added keywords "Htmx" and "extension", don't know if it was a good idea.

@jyrimatti jyrimatti deleted the refresh-href branch April 2, 2024 15:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
extension Consideration for an extension
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants