https://htmx.org logo
Join Discord
Powered by
# htmx-general
  • g
    depends on “+” I guess.
  • l
    In most languages, it's an exceptional case. In object oriented, you've got 
    X.add(Y)
    or 
    Y.add(X)
    ... but, that's just not right. So, in OO you have to hack it; or say, well "numbers aren't objects". Now, what about imaginary numbers? 
    iX + iY
    ? Either you have to make 
    Imaginary
    and object, or you have to give up on 
    +
    .
  • l
    Anyway, the thing is, in most scientific projects, the kinds of data are often rather involved, like a genetic sequence. The operators may be binary, or even terinary, taking 3 arguments.
  • g
    Ok, I’m following.
  • l
    So, multidispatch has the notion of addition, let's say 
    +
    , then, there are mulitiple implementations, (Int, Int), (Float, Float), (Int, Imaginary), etc.
  • l
    Critically, you could have your own data type, say 
    Score
    . Suppose 
    x
    is a 
    Score
    . Then you can do 
    3*x
    and it'll call 
    +(Int, Score)
    .
  • l
    What's awesome about this, is that frameworks just need to know that there's a binary operator 
    +
    and let any number of applications define their data types and what it means.
  • g
    This sounds very interesting for a server-side framework to implement, possibly as a query language, too.
  • g
    Again, similar to graph-ql in a very loose way
  • l
    For visual representations, you might want to render 2 objects together, against a canvas. Object 
    X
    comes from one library, Object 
    Y
    comes from another. And the framework that defines 
    render(canvas:SVG, row, col)
    doesn't have to care what it means to create a triple product of canvas, row, and col are?
  • l
    So, your other libraries/applications can mix-in and define their own meaning for 
    render
    without touching the framework code, etc. In this example, the application which wants to mix 
    X
    and 
    Y
    will have to define what -they- mean by 
    render(canvas:SVG, x:X, y:Y)
  • l
    This is just hard in some languages; there are often conventions for doing this, but it's library specific. Julia builds this into the very core.
  • g
    Yes. Speaking of that.. it is (very) loosely similar to the CMS I’m building. Developers build objects with states and views, then the content (and user permissions) dictate what combination of those three dimensions is actually rendered.
  • l
    Yea, Zope was a CMS. I think Julia, despite being a "scientific programming language" will be the best CMS backend.
  • g
    Gotcha.
  • g
    So, how to you see this related to HTMX? Is this something purely on the server side? Or is there something we need to petition management to build into the client side?
  • l
    I hope it's just server side, just sending up HTML/SVG/CSS. It's a hypothesis. We'll have to check.
  • g
    Next-Gen CMS will need to be: free, open source, real-time, and support activitypub, RSS, and APIs to every other monolithic service out there. The Next CMS will need to beat Facebook, Instagram, and Email all at once.
  • l
    Indeed. It'll also have to have data science, graphs, and machine learning built-in... as well as a next generation data integration language (DataKnots)!
  • g
    Shoot. You’re gonna make me have to learn more, aren’t you. 😦
  • p
    Is there a pattern in HTMX to give a form field the keyboard focus on load? Classic use case would be edit-in-place. When the user initiates an edit, I want to load the editable representation of a resource and give keyboard focus to the first input element so the user can begin entering their data.
  • t
    I'm not entirely sure, but would adding the autofocus attribute to it work?
  • m
    @User yep, autofocus should work ☝️ courtesy of @User: https://github.com/bigskysoftware/htmx/pull/160
  • m
    random thought: if you want an element to respond in different ways to different events, there isn't a good way to do that now. A couple of approaches I can think of to make this work: 1) support a 
    src:<selector>
    in 
    hx-trigger
    so you could put an adjacent element and have it select the other trigger source:
    Copy code
    html
  <button id='btn1' hx-trigger='mouse-enter' hx-get=...>My Button</button>
  <a hx-trigger='click src:#btn1' hx-post=...></a>
  • m
    the listener would be added to the other element, but everything else would be relative to the tag that it is on
  • m
    Another option would be to repurpose something like the meta tag:
    Copy code
    html
<button id='btn1' hx-trigger='mouse-enter' hx-get=...>
  <meta property='htmx-ext' content='' hx-trigger='click' hx-post=.../>
  My Button
</button>
    and have a convention where if you have a meta tag with the property name 
    htmx-ext
    then we appy the hx attributes on that meta tag to the parent element
  • g
    At first glance, a 
    src:
    selector or something like it seems like a good way to go. Maybe even something like 
    hx-src
    or 
    hx-listen
    . It would be kind of like the inverse of the 
    hx-trigger
    attribute. It’s probably best to keep things as close to “vanilla” HTML as possible.
  • g
    This looks vaguely similar to something we kicked around when we explored different SSE syntaxes. How could we allow one SSE connection to send updates to two different DOM nodes? (based on message type). The final (cool) result was to have those DOM nodes “pull” the content by referencing back to the original connection. That’s what would be happening here, as well.
  • g
    It would be good to shoot for as much consistency across all parts of the library as possible, both in syntax and philosophy. 🙂
  • m
    the trigger 
    src:
    option is probably the most consistent
1...394041...1146Latest