Anyone have luck incorporating HTMX with a WYSWYG text editor for notes fields?

Something like quill

Got quill working by copying quill div elements and pasting in a hidden div

@ripe-action-67367 i have successfully completed my task

js
function checklist() {
    var input_obj = document.getElementById('ProxyListInput')
    var live_obj = document.getElementById('LiveProxyOutput')
    var dead_obj = document.getElementById('DeadProxyOutput')
    const ProxyList = input_obj.value.split('\n')
    ProxyList.forEach(proxy => {
        $.get('https://api.pargonix.xyz/check/proxy', {proxy:proxy}, function (data, textStatus, jqXHR) {
            if (data.Status == "LIVE") {
                live_obj.value += data.Status + " | " + data.Type + " | " + data.Proxy + "\n"
            } else if (data.Status == "DEAD") {
                dead_obj.value += data.Status + " | " + data.Proxy + "\n"
            } else {
                alert("Error, No valid status")
            }
        });
    })
}

leaving code here to anyone who runs into same problem in future 😄

Any examples of htmx and or hyperscript drawing on a canvas?

Yeah. I just had a quick look at how to create PyCharm plugins and seemed a bit daunting U_U.

Yeah, I figured the upfront barrier is enough to deter someone casually working through it. I have been gradually learning neovim since it supports most of the niche stuff 😐

How can I reinitialize flatpickr when inserting a form into a web page using htmx. I'm using django, htmx and flatpickr and when serving the form with htmx ajax request, the flatpickr date picker does not work. I know I need to somehow reinitialize flatpickr but I have no idea how. I've been trying for days. I don't know javascript, either so that doesn't help.

Add an event listener for https://htmx.org/events/#htmx:afterSettle event and reinitialize flatpickr in it. Would probably be something like this

js
htmx.on("#form", "htmx:afterSettle", function() { flatpickr(".datetimeinput"); })

Change the selectors to match your case. Note, that \#form selector should be the one of the target element, which displays ajax response

My pattern is typically to initialize JS widgets in a load handler (and destroy them on the history snapshot event)

I must say how much I enjoy the htmx paradigm shift. I've posted previously about the application I'm writing that uses htmx in the admin area; this weekend's task is to apply user access levels throughout the application. It is so simple (as in "not complex") to not render portions of the UI, and control access to routes based on established roles! The user can't click on anything that they can't do, and if they mess with the URL (or form IDs), that won't work either. I'm very surprised that client-side escalation-of-privilege attacks on SPAs aren't a thing, and there's nothing in the architecture that prevents it. A public user gets your entire codebase! (with the exception of lazy-loaded modules, I know, but the hooks are there) All that to say - another 3 cheers from Tennessee to that "lunatic in Montana and his Internet friends" for eliminating an entire class of potential security bugs!

i regret what a dick I was back in 2016 when GraphQL first came out: https://news.ycombinator.com/item?id=11105394 on the other hand, I wasn't wrong.

snark never convinced anyone of anything, kids. learn from my mistakes.

It can be tough; when we encounter a problem, our natural tendency is to look at it and say "what do I need to add to fix this?" Solving things by reduction is not intuitive. I think, in the case of the GraphQL thing, they aren't thinking about the real-world administrative burden they're imposing to manage security at that granular a level. There's a reason "nobody" (I know there are exceptions) uses field-level security in their database. Every place I've worked didn't even use row-level security in the DB (though we filtered queries with user roles). The harder something is to do, the less likely they are to do it. This knowledge has been gained in multiple decades in software development, and includes a military environment, where you can literally command people to do something a particular way. If it's too onerous / time-consuming / complex, people simply won't do it. The best system design gets what it needs as easily as possible (and, if possible, along the way; no one wants to sit down at the end of a productive day and write about it, enter stats, etc.). I've spent more than a month working on a side project (I thought I'd have done in late May) because of some feedback I got that wasn't even really directed at me. Now, no one else may ever use this project but me, but it won't be because I made it too hard to set up. 🙂

facts

Trying to use Infinite load with djangos ListView and paginate_by, though I can't seem to get it to work properly, has anyone accomplished this?

Hey can someone tell me what is the correct hx-trigger for input type="number" i went with hx-trigger="change changed delay:1s" and it only works with keyboard, not mouse clicking those arrows in input( + -). mouseup wont work either. Any ideas?

sorry guys it is working.... i just change it in other input....

I don't but I'm curious what your use case is!

On

hx-swap-oob

- "Out of band elements must be in the top level of the response, and not children of the top level elements." Is that still true, and by design? Because I'm currently responding with a whole page (

<html><body>...

and all) and it includes non-top-level hx-swap-oob's, and they are being swapped (which is what I want!) The trigger for the request is:

<div
    id="results"
    hx-get="<?= current_url() ?>"
    hx-select="#results"
    hx-disinherit="*"
    hx-target="this"
    hx-trigger="refresh from:body"
    hx-swap="outerHTML"
>

Yes and kinda

😂 Do you know why a nested oob would still be getting swapped (when using

hx-select

in this way) and can I / should I be doing it? 😄

(the oob is a sidebar menu with "live" counters, so if I add/remove an item (shown in

#results

) then the live counter should reflect the change - which it is - but the way I read the docs, it shouldn't :D)

in the latest release there is

hx-select-oob

is this useful?

I take back the latter: it looks like oobs can be anywhere in the fragment

that is processed

if you are using an hx-select it might not be processed if the oob is outside of that select

😑