Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    1cg
    @1cg
    along with any other larvel-friendly features that might help you guys out
    36864
    @36864
    Thanks, this works perfectly. I'm trying to find a different name for this, as it's not a laravel-specific thing, lots of javascript frameworks use the X-Requested-With header.
    36864
    @36864
    Submitted a PR for this, called it "ajax-header". Took me a while to figure out the testing mechanisms, I am not a javascript developer at all.
    1cg
    @1cg
    Me either. ;)
    36864
    @36864
    Next step is figuring out how to get triggers to work with select2 controls
    Specifically, loading data into the subtype dropdown when the primary type dropdown value changes. I've tried setting the trigger to the select2 events, the select element's change event, few other things, but it's as if the events are never fired.
    cscortes
    @cscortes
    There is an example called ValueSelect on the htmx webpage. Pretty easy stuff.
    Eugene Esca
    @scsmash3r
    @cscortes Nice explanation, thanks for video :) And for the rooster, lol xD
    36864
    @36864
    @cscortes My issue is in using select2 controls, everything works just fine with regular controls.
    oko-x
    @oko-x
    hi @chg20 on the script load there is pretty expensive traversal of full DOM which results in decreased Lighthouse scoring because of the longer main thread work, is it possible to separate this logic for projects not using extends and other features that might require initialization? standard listeners might work well when bound to document root so it wouldn't be necessary to find and bind them in the DOM
    cscortes
    @cscortes
    @scsmash3r np, hope it helps someone, but now I have a fear that I will get a nickname like - the roster programmer. :)
    1cg
    @1cg
    @oko-x yeah we should look the attributes in question up via a query. It's a little more complicated, but not too bad. I also see a pretty bad bug where I'll double execute script tags. Hope to have it cleaned up this week.
    1cg
    @1cg
    ok, script bug is fixed
    I don't want to change the init code @oko-x but I will :/
    oko-x
    @oko-x
    @chg20 will you create an Issue for that (or should I), so I can keep track :)
    1cg
    @1cg
    @oko-x please do create an issue for it. Is there a way I can test if it performs well enough?
    cscortes
    @cscortes

    @chg20 been thinking about the extension mechanism which a great idea. It seems to have some issues with the ajaxrequest call though.

    I have written some psuedo code to start the discussion. I hope to start a dialog

    // psuedo code approach 
    function revisedajax() {
    
        // figure out what the "make 80% happy case is"  
        // or the "just works out of the box" case
    
    
        var ks;  // kitchensick
    
        // implement the 80% here, for example this is the "normal" case now
    
            // NORMALLY, we change verb to either "GET", "POST"
            xhrverb = "GET" or "POST" depending on verb 
            // so add both to kitchensink
            ks.verb = verb;
            ks.xhrverb = xhrverb;
    
            // NORMALLY, we change the url if GET
            xhrurl = url + urlencodedparameters
            // so add the original url and xhrurl
            ks.url = url 
            ks.xhrurl = xhrurl 
    
            // NORMALLY, we add parameters to the body if POST
            ks.xhrbody = create body with parameters if POST-like
            ks.parameters = parameters 
    
            // NORMALLY, we set the mimetype to texthtml
            ks.xhrMimeType = text/html
    
            // NORMALLY, we set the header content type 
            // like urlencode 
            ks.xhrHeaders = set content type to ... 
    
        // give extension writer change to deviate from NORM
        // the writer will know that changing variables that 
        // have xhr prefix will change 
        xhrchangeup( ks )
    
        var xhr =new XMLHttpRequest();
    
        // set xhr events (non changeable)
    
        setheaders( xhr, ks.xhrHeaders);
        if (ks.xhrMimeType) xhr.overrideMimeType( ks.xhrMimeType );
        xhr.open( ks.xhrVerb, ks.xhrUrl, true);
        xhr.send( ks.xhrBody);
    }
    
    define extension xhrchangeup( "json-enc", ks ) {
    
        ks.xhrHeaders = change content type to ...
        ks.xhrMimeType = ... 
        ks.xhrbody = encode parameters 
    
        // use original url 
        ks.xhrurl = ks.url 
    
    }
    
    // maybe 
    
    define extension xhrchangeup( "actual-verb", ks ) {
    
        ks.xhrHeaders = change content type to ...
    
        // use the actual verb 
        ks.xhrverb = ks.verb 
    
    }
    1cg
    @1cg
    @cscortes let me get my feet under me (I was on vacation for a week) and consider
    I think hyperscript should be available for a lot of request configuration directly in HTML
    but I'm not sure about that yet
    still need to see how hyperscript develops
    but I expect a lot of plugins to be written in hyperscript :)
    (or maybe not, to maximize their portability)
    cscortes
    @cscortes
    k
    1cg
    @1cg
    @cscortes did you see my feedback on your github pull request?
    I think that the json-enc extension needs to have two parts to separate out the header setting early enough in the request cycle
    cscortes
    @cscortes
    yes, commented on your comment. But your are correct -2 places with current design.
    cscortes
    @cscortes
    @chg20 oops, -2 sounds bad -- i apologize for the miscommunication, hopefully my comments on github are better worded.
    1cg
    @1cg
    No worries 😉
    Htmx 0.1 should be going out next Friday
    Ben Croker
    @bencroker
    Great!!
    cscortes
    @cscortes

    @chg20 I wrote a sample sse example with a flask server. I make the following change to:

            function processSSETrigger(elt, verb, path, sseEventName) {
                var sseSourceElt = getClosestMatch(elt, function (parent) {
                    return getInternalData(parent).sseEventSource != null;
                });
                if (sseSourceElt) {
                    var sseEventSource = getInternalData(sseSourceElt).sseEventSource;
    
                    var sseListener = function (event) {
                        if (!maybeCloseSSESource(sseSourceElt)) {
                            if (bodyContains(elt)) {
                                getInternalData(elt).sseEvent = event;
                                issueAjaxRequest(elt, verb, path);
                            } else {
                                sseEventSource.removeEventListener(sseEventName, sseListener);
                            }
                        }

    noticed I assigned the event to internal data of the element, this may not be the best way to do it.
    Can you make some recommendations?

    1cg
    @1cg
    can you show me a diff?
    cscortes
    @cscortes
    Yes, but its been a while since I made this change, don't know how much sense it will make.
    @chg20 here you go:
    795c787,788
    <                 var sseListener = function () {
    ---
    >                 
    >                 var sseListener = function (event) {
    797a791
    >                             getInternalData(elt).sseEvent = event;
    1cg
    @1cg
    hmm
    storing the event in the internal data seems a little strange, what's the need?
    cscortes
    @cscortes
    I use that internal data later in my cusotm sse-body extension I was developing.
    like so:
    htmx.defineExtension('sse-body', {
        encodeParameters : function(headers, parameters, elt) {
            headers["Content-Type"] = "application/json";
            return elt["htmx-internal-data"].sseEvent.data;
        }
    });
    1cg
    @1cg
    @cscortes there is a bug around SSE and using the event content here: bigskysoftware/htmx#66
    Would you like to implement this change?
    I have a suggested syntax:
    <ol hx-sse="swap on eventName" hx-swap="beforeend">Loading list...</ol>
    from what I can tell, what you are trying to do in a plugin would be better done internally
    cscortes
    @cscortes
    ok. my code looks similar. but it is more verbose with the extension.
    I have a second ajax call to a routine that "handles" the sse data returned. I assumed it wasn't going to be html -- because some streams aren't.
    1cg
    @1cg
    as much as possible if it can pass through the normal response handling, that would give us the maximum flexbility
    cscortes
    @cscortes
    this is what that looks like:
       <body id="thebody" hx-sse="connect /news_updates">
    
            <h1>Receiving Messages:</h1>
            <div id="sselist" hx-trigger="sse:new_news" hx-ext="sse-body" 
            hx-post="/news" hx-target="#nid" hx-swap="beforeend">
                <ul id="nid">
                </ul>
            </div>
    
        </body>
    1cg
    @1cg
    nice