A Better <Button>?
I don't normally program in JS / TS so if this exists lmk.
A button element but it has 3 hooks.
On Click <- What is on mouse button down
On Confirm <- Mouse button up (on the same element)
On Cancel <- Mouse button up (on a different element)
The idea of this is to make it so that the website can start acting on your click as soon as possible but have a way to roll it back if you try to "un click".
On click will finish running before On Confirm or On Cancel is called and one of On Confirm or On Cancel is guaranteed after an On click.
This came up while I was watching one of Theo's old videos as I agree with a comment on that video:
@imaron 1 year ago The whole "undoing" a click is HUGE for me, and I'd hate to see it go...I am not familiar with web dev (I mainly mess around with discord bots and databases) and am looking at this from the user's perspective. Is this useful, are there problems with it, and does it exist already? -# I have done some research and have not found a library for it but maybe people are just implementing it themselves
Theo - t3․gg
YouTube
“Act On Press” - John Carmack's Hot Take On UI
This John Carmack tweet got me thinking. Like, REALLY thinking. onMouseDown might be my goto in the future
SOURCE
https://twitter.com/id_aa_carmack/status/1787850053912064005
Check out my Twitch, Twitter, Discord more at https://t3.gg
S/O Ph4se0n3 for the awesome edit 🙏
10 Replies
Pings are welcome
That shouldn't be hard to implement. I don't think there is a need to install a dependency just for that
It is not hard at all it was more of something that I don't think I have seen (from the user's perspective) on any website.
Not including loading content on hover.
Oh. I don't think any major websites are doing it because it's not worth the added complexity. Or at least in my opinion it isn't
I don't think there is a need to install a dependency just for thatWhile I do agree that you do not need a dependency for everything, and this seems to be able to be implemented in < 100 lines of code, I am happy to have the discussion of if it would be good to have a dependency though I have very little experience in the js world. I do see this as a valid response to this idea
What's the end goal of the idea anyway, faster UI updates?
The end goal is to make websites feel like the respond faster while keeping the accessibility of being able to "unclick" a button.
Ok trying to come up with an example other then using a database transaction is difficult for me
YouTube - loads the video on hover
And most things would be better on hover anyways
Since the UI will be updated only after mouse up. The gain will be minimal. Most users most of the time just do a quick click. The time difference between mouse down and mouse up is probably between 5 and 15 ms most of the time. That's not much.
Then there's also mobiles. On mobile if you want to "unclick" the button by leaving the button, that would also mean scrolling, which often would also mean keeping the button hovered as it follows the finger unless you reach the bottom or top of the page. So you'd have to take that into account and change how the button works on mobile, only adding more complexity for absolutely 0 gains on mobiles while giving very minimal gains, that aren't even perceptible, for desktops
Fair points
Thanks for responding!
There's a few other things, too. If that idea is just for the fetching of data from the server. Then you don't need onConfirm and onCancel.
If you want to do it also for client-side UI updates.
Correct me if I'm wrong, but how I'd imagine you'd do it is by mounting or applying whatever changes you want to other components but also keeping track of the button's "state" to keep the changes invisible to the user with display: none until the confirm has been sent from the button.
But that adds a lot of overhead. Cause the complexity is not just localized inside the button component but also in every component using it as you need to keep track of the state. And while it's as easy as a useState, that does still add complexity in many places. And for some changes that might also be extremely complex or maybe even impossible to implement depending on what the button is supposed to do
and even more complexity if the button doesn't trigger changes to a state local to the component it's used in, but if it triggers changes to the global store