unf. if there is already a heavy dependence on react (and those components talk w/ the server) then htmx might not be a great fit. If you can use them as "islands" within a larger htmx app, it might still be worth it to minimize the complexity elsewhere...

is it a known set of inputs? Better would be to group them into a div and target that div

might also be worth trying idiomorph for this case

htmx is a front-end library of peace

putting an example together now

Our current apps heavily depend on react indeed. We constantly create new ones though and I'm trying to find out if we should start introducing htmx. I think the apps we build do fit the model htmx proposes very well and there's no need for react to realize the level of interactivity that we need (and we could indeed add it localy at places where we really need it). But again, having a library off styled components is a real time-saver so Im trying to find out what my options are here. I guess it's worth trying to see if I can use the styled-react-components, but without a client-side-db and relying on htmx for the interactivity. But it's not clear to me if these will be succesful and/or sensible. I got shoelace working out-of-the-box like benoptamus mentioned, so another option to explore is how much effort it is that get this base in style of the platforms.

yeah, if you can disentangle the front end components from the back end state syncing, and you can expose them in a sane way to htmx via input values and events, it might be worth it

Cool. Thanks for the pointer. I'll do some experiments over the next few days.

You say, ”having a library of styled components”, and with HTMX you would create those in your backend, instead of React. Essentially you bundle HTML/CSS/JS into reusable, and composable, chunks of code (just like you’d do with React), except in whatever backend you’re using. I use Django and found the

django-components

library helpful to bundle my server-side HTML/CSS/JS. Except I added Tailwind for CSS, and Alpine for JS, so my “components” are just the HTML template part, in Python strings.

Yeah that's the impression I had, and it appeals to me. It's just that the platforms we integrate with already provide these styled-components (in react), saving us a lot of time, so now the question becomes if we can adapt them or create components ourselves easily/efficiently enough so there's a net-gain. We'll find out!

It is yeah - I'll try idiomorph as I think it'll solve that issue with input values being override right?

it should

experimental

but worth a try

(idiomorph will be integrated into htmx as a "merge" swap in 2.0)

Speaking of shoelace/webcomponents, I think there is a third party PR that has been sitting in the repo for a while that adds Shadow DOM support

yeah, i like the idea but didn't understand the code

real talk: semester just ended and I'm in the process of moving my family into a new house, so it's gonna be a little slow except shitposting 😑

Good luck with the move!

i will need it 😭

so i switched on the

preload

extension last night. but i can't even perceive the difference, htmx is already so fast the app feels like a SPA 😂

🙂 ramp up the latency setting in chrome devtools

but prob not worth it for most sites

good call! there's still a noticeable lag with Slow 3G. but not too bad overall

Does

hx-preserve

work with OOB swaps? EDIT: Or rather... should it be? Having trouble implementing it

How to handle form submit result if success clear the form inputs if failed show the error message(currently I am returning whole form as it is with error message if fail on success returns new form)

I am planning to rewrite with htmx an internal search application (currently on Vue). The current application retrieves data from Solr or Elasticsearch. It includes a search input, checkboxes, and resulting facets that can be used as additional filters. As these filters should be kept as URL arguments to allow for bookmarking, I am looking for a pattern to use with htmx. One option is to use

hx-post

to send the search input and

HX-Push-Url

to display the results. However, I am unsure how to send additional filters. Would it be best to keep a session (cookie, local storage) with all the query parameters?

It sounds like you should be able to wrap your search + filter inputs in a form tag and use hx-boost:

<form action="/search" method="get" hx-boost="true">

. This will swap via htmx and update the URL.

I used this as reference: https://htmx.org/examples/active-search/ In my idea the swapped content in hx-target contains the facet boxes (with filters), but is not clear to me how to add them to parent . so ok, better to use hx-boost and GET. Will try this, thanks!