A heck of a wild bug chase • Hacker News Board

Re: A heck of a wild bug chase

#51

Post by de46le » Sat, Aug 10, 2024, 2:55 PM UTC

recursivedoubts wrote: post #50

williamdclt wrote: post #44

Earlier quoted context omitted.

I mean, it should just be a submit for a form with a /logout POST action. It’s standard and what web devs have been doing for decades

Yeah, the problem is that it requires a form, which has layout implications w/o styling and POST is not idempotent, whereas a logout operation typically is idempotent. Being able to issue a DELETE to a URL like /session from an element that doesn't have layout implications would be ideal.

A button doesn't have to be inside a form, though. You could have an empty form as a neighbour to the button (or anywhere else inside the page body), and associate the button with it.

  logout

No layout implications that way, barring any nth-child css (solvable by putting the form somewhere else). Doesn't solve the form being limited to GET/POST, but styling concerns are atleast handled.

Re: A heck of a wild bug chase

#52

Post by andrewfromx » Sat, Aug 10, 2024, 3:46 PM UTC

williamdclt wrote: post #49

andrewfromx wrote: post #16

Earlier quoted context omitted.

so you don't have to set "cursor: pointer" in css

why avoid so hard to make it a `submit` for a ` `, which is semantically correct and removes all the need for any javascript (logouts have never needed JS after all)?

because you often need to send a DELETE verb not POST

Re: A heck of a wild bug chase

#53

Post by ufmace » Sat, Aug 10, 2024, 4:02 PM UTC

Ethee wrote: post #4

jof wrote: post #2

It seems to me like the underlying issue was ignoring HTTP semantics and making a state-changing link like a logout link a plain (HTTP GET) and not something like a form submission (HTTP POST). Having intuition for the foundational layers of our tools saves so much time and future headaches.

Genuine question: How do you believe one should learn these semantics? This is more something I've been pondering myself recently, because I agree with you that the foundational knowledge for our work in any tech stack is usually the most important for understanding higher abstractions. But with so much to know it feels impossible to 'know it all' so to speak especially if you wear more than one specialized hat. Then…

IMO it's very understandable to not know about this sort of thing starting out. Everybody was new once, and it's much easier to get motivated to build cool stuff than to read about all the fine details of all of the technologies we're using. I say, go ahead and take the shortcuts and build some cool things in a maybe sloppy way as long as the traffic and stakes aren't too high. Then, once you've got something cool built, take some time every now and then to seek out and read about more of the details of some of the systems and tools you're using.

Re: A heck of a wild bug chase

#54

Post by williamdclt » Sat, Aug 10, 2024, 4:17 PM UTC

recursivedoubts wrote: post #50

williamdclt wrote: post #44

Earlier quoted context omitted.

I mean, it should just be a submit for a form with a /logout POST action. It’s standard and what web devs have been doing for decades

Yeah, the problem is that it requires a form, which has layout implications w/o styling and POST is not idempotent, whereas a logout operation typically is idempotent. Being able to issue a DELETE to a URL like /session from an element that doesn't have layout implications would be ideal.

> POST is not idempotent

It certainly can be, there’s just no _requirement_ that it is idempotent. There’s no problem with having an idempotent POST operation.

I’m also not a fan of a DELETE /session option, the client shouldn’t have to care about the concept of “session”, it’s the server’s problem. But I’m not a fan of resource-based endpoints in general, I tend to prefer task-based endpoint so /logout makes more sense to me.

Also, even if it was possible to trigger DELETE in html it probably would be implemented as a form. Not really a problem, making a form element inline is trivial, and probably needed in various parts of an app (any button that changes some state)

Re: A heck of a wild bug chase

#55

Post by graypegg » Sat, Aug 10, 2024, 5:15 PM UTC

zbentley wrote: post #20

graypegg wrote: post #3

Earlier quoted context omitted.

To be fair, tags can't send out non-GET requests. Which yes, can be interpreted as "logout controls should be buttons in forms, not links", but I would really like native htmx-like attributes for intractable html elements.

What’s stopping you from using htmx with a form? Hx-post works as a form element attribute just fine.

Nothing. I just think it logically makes sense as a native feature.

Re: A heck of a wild bug chase

#56

Post by recursivedoubts » Sat, Aug 10, 2024, 5:22 PM UTC

williamdclt wrote: post #54

recursivedoubts wrote: post #50

Earlier quoted context omitted.

Yeah, the problem is that it requires a form, which has layout implications w/o styling and POST is not idempotent, whereas a logout operation typically is idempotent. Being able to issue a DELETE to a URL like /session from an element that doesn't have layout implications would be ideal.

> POST is not idempotent It certainly can be, there’s just no _requirement_ that it is idempotent. There’s no problem with having an idempotent POST operation. I’m also not a fan of a DELETE /session option, the client shouldn’t have to care about the concept of “session”, it’s the server’s problem. But I’m not a fan of resource-based endpoints in general, I tend to prefer task-based endpoint so /logout makes more se…

right, but the browser doesn't know that and so it has to treat the operation as if it were not idempotent (i.e. warn on a resubmit)

You second paragraph indicates that you do not like the REST pattern of the web, which is fine, but i hope you can appreciate that some of us would like the web as the web to make it possible to abide by that pattern

the last point is addressed in Alex's proposal to allow buttons to function as stand-alone hypermedia controls

Re: A heck of a wild bug chase

#57

Post by recursivedoubts » Sat, Aug 10, 2024, 5:24 PM UTC

de46le wrote: post #51

recursivedoubts wrote: post #50

Earlier quoted context omitted.

Yeah, the problem is that it requires a form, which has layout implications w/o styling and POST is not idempotent, whereas a logout operation typically is idempotent. Being able to issue a DELETE to a URL like /session from an element that doesn't have layout implications would be ideal.

A button doesn't have to be inside a form, though. You could have an empty form as a neighbour to the button (or anywhere else inside the page body), and associate the button with it. logout No layout implications that way, barring any nth-child css (solvable by putting the form somewhere else). Doesn't solve the form being limited to GET/POST, but styling concerns are atleast handled.

doable but rarely used, inconvenient and awkward, alex proposes allowing buttons to be stand-alone hypermedia controls which also allows multiple buttons located within a form to perform different actions (e.g. save v. cancel)

Re: A heck of a wild bug chase

#58

Post by danjl » Sat, Aug 10, 2024, 5:58 PM UTC

theamk wrote: post #23

danjl wrote: post #15

Authentication is a major hurdle. Back in the days of desktop software, there was no authentication. Mobile apps can often avoid authentication too. Despite decades of web coding, and lots of "this authentication system will make life easy" claims, it is still hard and easy to mess up.

it's impossible to avoid authentication once you start sharing data between systems though. This includes basic stuff like "I only want to share the list with our graduates", as well things like "those preferences should be the same on every device which user X owns".

As my former boss at Sun, Scott McNeely said "the network is the computer"

Re: A heck of a wild bug chase

#59

Post by de46le » Sat, Aug 10, 2024, 7:12 PM UTC

recursivedoubts wrote: post #57

de46le wrote: post #51

Earlier quoted context omitted.

A button doesn't have to be inside a form, though. You could have an empty form as a neighbour to the button (or anywhere else inside the page body), and associate the button with it. logout No layout implications that way, barring any nth-child css (solvable by putting the form somewhere else). Doesn't solve the form being limited to GET/POST, but styling concerns are atleast handled.

doable but rarely used, inconvenient and awkward, alex proposes allowing buttons to be stand-alone hypermedia controls which also allows multiple buttons located within a form to perform different actions (e.g. save v. cancel)

Oh for sure, standalone elements would definitely be better, I just wanted to point out that there's a way around needing to do silly stuff like

Though in my experience, it's great in frameworks like svelte. Define your forms at the top of the component, and you can see at a glance what native actions the component can do, and where it posts to.