https://htmx.org logo
Join Discord
Powered by
# htmx-general
  • g
    Could you whip up a line or two of example code to demonstrate how you'd use a component?
  • g
    Yes. Mustache is cool. HTMX does already support some client-side rendering via extensions.
  • t
    1. write it
    Copy code
    html
<target>
<style>target > *{color:red;}</style> // scoped
<b>i'm a target</b>
<script>alert('target');</script> //scoped?
</target>
    2. mount it
    Copy code
    js
tag.mount('target',{
html: "<b>123</b>",
params: {
  param1: "value",
  param2: "value"
}
});
    3. render it
  • t
    not sure about cases like this though
    Copy code
    html
<shelf>
  <item color="red"/>
  <item color="green"/>
  <item color="blue"/>
</shelf>
  • g
    So, isn't this just WebComponents? This is an interesting problem set, but a different one than HTMX is addressing. Already, today, you can use HTMX alongside Lit-Element (my personal favorite), or Svelte, or a dozen other WebComponent frameworks. But, unless I'm missing something, I don't see the reason to duplicate those (already awesome) features in HTMX.
  • t
    nope
  • t
    > Already, today, you can use HTMX alongside Lit-Element (my personal favorite), or Svelte, or a dozen other WebComponent frameworks. custom elements are retarded and svelte isn't for es5
  • g
    Sure, we can argue about the quality of specific client-side component tools (try Lit-Element, it's quite good) but the larger point is that that is the domain for other tools. HTMX a set of networking extensions to HTML, not a widget framework, so you'll have a hard time getting consensus for adding client-side widgets in this library.
  • g
    Even certain super-useful scripting features have been offloaded to the Hyperscript.org sister project to keep HTMX tight and focused.
  • g
    Now, enabling INTEGRATION into these other tools is probably a good starting point. For example, are there hooks into Riot for initializing components? Is there some way that HTMX could make this better? I'd bet there's a way to make extensions that automatically trigger the relevant 
    init()
    functions for specific client-side component library du jour.
  • t
    wait, it's not remotely widgets, geez. What is that, jquery ui?
  • t
    components != widgets, widgets are already preset, components are 100% user-defined
  • s
    Hi, I am actually intested about web components with HTMX use case. I haven’t yet started the project where I’m planning to use HTMX, but I’m very much planning to leverage custom elements there. Something like this: 
    <date-picker hx-post="/clicked" hx-swap="outerHTML">Click Me</date-picker>
    And there are many ways to leverage web components: https://webcomponents.dev Browser support isn’t perfect, but it’s pretty good these days.
  • t
    i wouldn't recommend relying on custom elements standards at all
  • g
  • g
    Support is not perfect, especially if you need so support IE11. But if you have the luxury of working with modern browsers, or if you're building something that is a year or two from mass consumption, that's a different story.
  • g
    @User I'm not sure I know or care about the semantic differences between widgets and components. I think the important issue here is what belongs in HTMX, and what would be better in another package.
  • g
    @User - I'm interested to see how well your date-picker example works. That's my plan, too, once I get the server end figured out 🙂
  • t
    hence what i'm saying is decoupling the components as a separate lib is an option
  • t
    > Support is not perfect, especially if you need so support IE11. But if you have the luxury of working with modern browsers, or if you're building something that is a year or two from mass consumption, that's a different story. @User it's not about support, it's about how retarded requirements are
  • g
    agreed on both points 🙂
  • s
    https://medium.com/@WebReflection/a-new-web-components-wonder-f9e042785a91 this fellow seems to disagree about IE11 and working with custom elements He has made small polyfills for quite old and stubborn browsers alongside several custom element libraries
  • s
    @gorgeous-ghost-95789 I’ll post something hopefully soon I think that emitting those events that HTMX listens for should work wether they are triggered from web component or regular HTML
  • g
    Yes, that's what I'd expect too. I haven't tried it, but it's all supposed to be just standard HTML events. WebComponents emit standard events, and HTMX just listens for standard events.
  • g
    You should be fine. But that's a mighty big word in web development 🙂
  • s
    Yea. I have actually had more problems on the update side. When I have used diffing libraries like Morphdom to update DOM where custom element gets new attributes they have behaved very oddly.
  • g
    That sounds right, since you have no idea what kind of internal state is getting switched out when you mess with the DOM. Kinda supports @User 's hatred of WebComponents.
  • g
    Personally, I save my hate for IE11, but that's sort of a no-no topic in the HTMX forums, so I just keep it to myself 😉
  • t
  • s
    Well, they are supposed to change their state based on attribute changes (if so coded). My problems were more about the way DOM changes from diffing libraries seemed to go against web component life cycle.
1...606162...1146Latest