Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Htmx – high power tools for HTML

htmx.org

Post reply on HN
Print view View original

51–60 of 175 posts

Re: Htmx – high power tools for HTML

#51

Post by recursivedoubts »

gavinray wrote: post #42
recursivedoubts wrote: post #31

Earlier quoted context omitted.

I'm not dogmatic about it. Some validation has to be done on the server side (e.g. unique emails) and any validation has to be redone on the server anyway since the client side isn't a trusted computing environment, but I can see doing both.

Ahh got it, yeah in this case that makes a ton of sense. No way to know with emails about uniqueness constraints until it hits the backend anyways. I've been playing around with local demo, is it possible through extensions to make a wrapper that can perhaps compose GraphQL query inputs from forms?

yeah, you could use the json encoding extension as a starting point:

https://htmx.org/extensions/json-enc/

Re: Htmx – high power tools for HTML

#52

Post by gavinray »

recursivedoubts wrote: post #51
gavinray wrote: post #42

Earlier quoted context omitted.

Ahh got it, yeah in this case that makes a ton of sense. No way to know with emails about uniqueness constraints until it hits the backend anyways. I've been playing around with local demo, is it possible through extensions to make a wrapper that can perhaps compose GraphQL query inputs from forms?

yeah, you could use the json encoding extension as a starting point: https://htmx.org/extensions/json-enc/

I was just trying that, it seemed not to be working for some reason.

I manually copy-pasted the source code into my app, and got:

    htmx.min.js:1 TypeError: Cannot set property 'Content-Type' of undefined
        at Object.encodeParameters ((index):11)
        at htmx.min.js:1
The code for it is:

xhr.requestHeaders['Content-Type'] = 'application/json'

But I believe it should be

xhr.setRequestHeader('Content-Type', 'application/json')

When I do this, it seems to work

https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequ...

Re: Htmx – high power tools for HTML

#53

Post by [deleted] »

recursivedoubts wrote: post #51
gavinray wrote: post #42

Earlier quoted context omitted.

Ahh got it, yeah in this case that makes a ton of sense. No way to know with emails about uniqueness constraints until it hits the backend anyways. I've been playing around with local demo, is it possible through extensions to make a wrapper that can perhaps compose GraphQL query inputs from forms?

yeah, you could use the json encoding extension as a starting point: https://htmx.org/extensions/json-enc/

[deleted]

Re: Htmx – high power tools for HTML

#54

Post by recursivedoubts »

gavinray wrote: post #52
recursivedoubts wrote: post #51

Earlier quoted context omitted.

yeah, you could use the json encoding extension as a starting point: https://htmx.org/extensions/json-enc/

I was just trying that, it seemed not to be working for some reason. I manually copy-pasted the source code into my app, and got: htmx.min.js:1 TypeError: Cannot set property 'Content-Type' of undefined at Object.encodeParameters ((index):11) at htmx.min.js:1 The code for it is: xhr.requestHeaders['Content-Type'] = 'application/json' But I believe it should be xhr.setRequestHeader('Content-Type', 'application/json')…

looks like there's a bug in the json-enc extension: it's relying on the test mock which has a requestHeaders property that a real xhr won't.

so the tests passed but it doesn't work irl...

good catch! want to submit a pull request fix?

Re: Htmx – high power tools for HTML

#55

Post by akersten »

fastball wrote: post #6

For similar-goal prior-art, see Unpoly[1]. Also the IETF asks[2] that you please stop using "X-" to prepend your custom HTTP headers[3] [1] https://unpoly.com/tutorial [2] https://tools.ietf.org/html/rfc6648 [3] https://htmx.org/reference/#headers

Off topic, but that's a shame about them recommending not to prefix X- for custom headers.

Their entire reason (Appendix B) is that "well, if the header eventually becomes a standard header, then there will be old apps that will only work with X-, and we'll have to keep the X- version around forever!" That seems like a very weak reason to me. Most custom headers are not going to become standard headers, and those that do, well, apps can update nowadays and we deprecate old web features all the time.

I see a lot of value in distinguishing non-standard headers as a matter of principle. Also, there's a little bit of classic charm to X-, it's almost a shibboleth of HTTP. Removing it feels as wrong to me as removing the :// from the URI protocol and saying "we really just need :/"

Re: Htmx – high power tools for HTML

#56

Post by recursivedoubts »

fastball wrote: post #6

For similar-goal prior-art, see Unpoly[1]. Also the IETF asks[2] that you please stop using "X-" to prepend your custom HTTP headers[3] [1] https://unpoly.com/tutorial [2] https://tools.ietf.org/html/rfc6648 [3] https://htmx.org/reference/#headers

fastball has submitted and I have accepted a fix for the headers issue

thank you!

Re: Htmx – high power tools for HTML

#57

Post by [deleted] »

fastball wrote: post #38
benatkin wrote: post #36

Earlier quoted context omitted.

I'm not sure about changing the headers. X- is a widely accepted convention. In the RFC also says this: > SHOULD NOT prefix their parameter names with "X-" or similar constructs. It doesn't spell out exactly what would be considered a "similar construct", but I think "HX-" might count as a similar construct. There's no good way to implement the feature you want that would satisfy all reasonable interpretations of tha…

I think the spirit of the RFC is mostly about complications arising if such headers ever became standardized, but also that the "X-" just doesn't add any value – it's a convention without a purpose and just makes headers longer. In fact, it arguably becomes less useful the more people use it. So I think it's better for new projects to drop the "X-". On the other hand, I think it's reasonable to prepend with "HX-" bec…

[deleted]

Re: Htmx – high power tools for HTML

#58

Post by gavinray »

recursivedoubts wrote: post #54
gavinray wrote: post #52

Earlier quoted context omitted.

I was just trying that, it seemed not to be working for some reason. I manually copy-pasted the source code into my app, and got: htmx.min.js:1 TypeError: Cannot set property 'Content-Type' of undefined at Object.encodeParameters ((index):11) at htmx.min.js:1 The code for it is: xhr.requestHeaders['Content-Type'] = 'application/json' But I believe it should be xhr.setRequestHeader('Content-Type', 'application/json')…

looks like there's a bug in the json-enc extension: it's relying on the test mock which has a requestHeaders property that a real xhr won't. so the tests passed but it doesn't work irl... good catch! want to submit a pull request fix?

Sure =D

Done!

Also this extension API is pretty straightforward, the element reference and parameters are right in the args so it's an easy mapping to GraphQL query strings from there. Awesome!

I was able to get a minimal version working using just this (with json-enc extension patch):

    "
    />
Pretty cool

Re: Htmx – high power tools for HTML

#59

Post by persona »

recursivedoubts wrote: post #12
JadeNB wrote: post #9

On the chance that the authors are here: on https://htmx.org/docs , there is a link "original web programming model" where the target is (for some reason) surrounded by parentheses, so that it points to the wrong location.

fixed, thanks

On docs fix reporting, there is also a typo on

https://htmx.org/extensions/client-side-templates/

any element below it in the DOM can use one of three attributes named -temlpate

Re: Htmx – high power tools for HTML

#60

Post by fsateler »

recursivedoubts wrote: post #49
combatentropy wrote: post #43

Earlier quoted context omitted.

I have a lot of respect for intercooler and wish something like it had become the go-to, with more complicated things like React reserved for apps that really need it. I'm curious why you are starting over. What is different from intercooler besides no need for jQuery? Why HTMX instead of Intercooler 2.0?

I wanted the freedom to completely reimplement things and drop ideas that didn't work out in intercooler I also wanted to stress that htmx isn't just another javascript library, competing with react and the rest. It is focused on HTML and extending HTML to make it a powerful and complete hypertext. I think that the name htmx captures that idea pretty well.

What ideas do you think didn't work out?

Btw, I'm currently a very happy user of intercooler. Thanks for the awesome lib.

Post reply on HN