https://htmx.org logo
Join Discord
Powered by
# htmx-general
  • m
    I wonder if the dash is screwing things up
  • m
    i don't remember if we properly tokenize there
  • m
    one sec, lemme look
  • m
    also, this should be in hyperscript probably
  • f
    Hmm, seems like that might be it, I'm no longer getting an exception. Let me test it.
  • m
  • m
    htmx 1.8.3 has pretty much everything I am thinking about for 2.0
  • m
    will likely start on 2.0 in January
  • m
    particularly interested in feedback on 
    <head/>
    processing and the ideal balance between "just works" and explicit control
  • n
    https://twitter.com/htmx_org/status/1588893106136834056?s=20&t=qsWqjhRoeoUoavuxzumQgw Hi friends. I want to make a suggestion of an approach which is very successful in minimizing pain and keep the project moving forward at full speed. The folks that use it call it "stability without stagnation". šŸ˜‰ Ember.js * Minor version upgrades do not introduce breaking changes. It's add-only * If a new breaking change is going to be introduced the respective APIs must show deprecation warnings when used but work in the exact same way. * The new APIs must be added to the current version. That does not break the add-only warranty and must not break or change any existing APIs. * When a deprecated API is used (assuming a dev build of the lib) a warning is shown on the browser console. Deprecation warnings must be removed on the production build of the lib. * Developer using the current version don't have to, but can adopt new APIs to remove deprecation warnings. Making the current version compatible with the next one. * When a new major version is released the deprecated APIs are removed. This is a breaking change and that's why it's a major version change. That means if you are running a version without deprecation warnings you are 100% compatible with the next major version.
  • m
    I'm following the guide at https://blog.benoitblanchon.fr/django-htmx-modal-form/ for using HTMX to display modal forms. Elements targeting #dialog work fine generally, except when nested under other HTMX-enabled elements. In these cases the modal dialog is called, but the content is not inserted from the html response. Any idea why that is?
  • m
    Basically the first tag with actions here is somehow preventing the second tag for swapping the response contents into #modal:
  • m
    <form hx-post="{% url 'wishlist_sort_wishes' wishlist.id %}?edit={{ request.GET.edit }}" hx-trigger="change" hx-swap="none" class="row sortable">
    <span class="action" hx-get="{% url 'wish_edit_wish' wishlist.id wish.id %}?edit={{ request.GET.edit }}" hx-target="#dialog"><i class="text-primary" data-feather="edit-3"></i><br><small>Rediger</small></span>
  • m
    hx-disinherit="*" did the trick.
  • b
    https://stenciljs.com/docs/styling Another option similar to Lit is Stencil
  • b
    I havenā€™t tried this yet, but Stencil has an option to enable or disable the shadow DOM. Not sure if that helps the issues people usually mention with web components and shadow DOM.
  • b
    I started building a demo of how Iā€™d envision head swapping but got sidetracked with work. But basically I had something like, swapping in this HTML:
    Copy code
    <head><script src=ā€œcontact.jsā€ hx-tag=ā€œcontactā€></script></head>
<div hx-tag=ā€œcontactā€>ā€¦</div>
    Then in the source page, anything in the head thatā€™s untagged is left as is. If an element within head has a tag, itā€™s kept if the same tag exists in an element in the body. Otherwise it removes the ā€œabsent tagsā€ elements from head. This allows the existing functionality to continue working as is (default append, or whatever is decided), and also creates a concept of page transitions. I can put something more detailed together to illustrate if that helps. Just trying to get my thoughts out rather than waiting until I have time to build it all šŸ™‚
  • h
    Stencil is neat but there's not a good way to embed it in a project - you need to treat it like an external resource with a dedicated build
  • h
    it is the only WC tool I found that could use the lightdom instead of the shadow dom
  • b
    I only started playing with it, because I liked how clean it looked, but had the same thought. Not a good way to include in an existing project
  • l
    Is there any trick to getting all the values of form to show up in the URL (using 
    hx-get="ā€¦"
    )? I'm trying to swap out an entire form, but changing the value of an input while typing (with a delay) just seems to push the value of that field to the URL, which doesn't let me keep other field inputs.
    b
    s
    • 3
    • 6
  • l
    Is there any trick to getting all the
  • l
    Thanks for the explanation but I was previously a Drupal developer, Flash developer, Shockwave developer and wrote CGI scripts in perl when the internet grew up. The back-ends that don't return HTML are SAAS platforms and micro-services which when dominating the eCommerce space are ones such as Shopify, BigCommerce and Magento, including headless CMS like Contentful. While this movement is a response to the API world, MACH and Microservices has a very strong influence commercially. I've asked a question to JAMStack users about their preferred techstacks and API first CMS and SAAS eCommerce platforms comeback. I like the the days of Drupal, Rails etc and agree that the API headless world built on JS (NPM is crazy btw) is convoluted. However to make change I need to understand what is required to use HTMX and it sounds like a self-hosted framework like Django, Drupal, WP et al, and no SAAS CMS currently exists as a weapon of choice where it can be configured to return HTML rather than JSON. If using BigCommerce for example into a headless storefront I would need a middle-layer to convert the API response into HTML. So I'm clarifying which oy have done in your response, that something like Drupal, Rails, Django etc is needed to work effectively with HTMX at this time in the industry. That's why I asked about ButterCMS since it's an obvious example of a known headless CMS, and if that can be configured to return HTML to integrate with an HTMX approach it is much easier to introduce to current development that explaining that an HTMX front-end means we need to install and maintain rails/Drupal and convert their API responses into HTML returns. So based on this, my original question was about suggestions/examples for HTMX in eCommerce. From your reply what would you recommend as an eCom techstack using HTMX if I was replatforming a headless enterprise store build on say Magento + Commercetools?
  • e
    You can totally do htmx with Shopify if you accept the limitations they put on their Liquid-based web storefront and/or are ok with hosting a few scripts connected to their Admin API on a (cheap) external hosting service. Iā€™ve done a prototype of a HTMX extension. Itā€™s currently not in use because we didnā€™t need the functionality after all, but it works! https://gist.github.com/fabianeichinger/ec5018a313b2bb79513286ca27c53ced
  • m
    if the back-end you are constrained to use is not set up to return HTML, then htmx probably isn't going to be a great fit. We do support client-side templates via an extension, and @echoing-book-71490 has created a very interesting shopify extension you might be interested in, but it won't be as simple as it is with systems that are comfortable returning HTML
  • e
    It's actually not client side templating. They support returning multiple server-side rendered partials (sections) as HTML on-demand or even with certain actions like adding stuff to the shopping cart as part of the response. You can't read or set headers and stuff, unsurprisingly, but you can still update sections with or without the oob-swap attributes.
  • m
    interesting!
  • e
    It would be interesting to do a full Shopify theme with HTMX. Maybe a port of the basic Dawn theme (that's the baseline for current theme development from what I understand) where all/most the JS is replaced by HTMX and (as needed) hyperscript. OTOH I feel like HTMX is something you can just drop in when you have a need for it, like we did with JQuery back in the day. Also there are just so many hours in a day.
  • c
    can I do something like hx-target="find .comment_list" ? i recieve a targetError and not sure what's the issue?
  • c
    I have a list and a comment form under, I've put the hx-target on the tag element wrapping both
1...892893894...1146Latest