Three ways of handling user input
dubroy.com
Three ways of handling user input
1–10 of 17 posts
Re: Three ways of handling user input
#2[deleted]
Re: Three ways of handling user input
#3Does anyone else find approach #3 to be wildly unintuitive? Like how does an infinite loop terminate? There's a lot of magic going on.
I like approach #1 the best. Sure, there are some bugs, but a state diagram would help make it clearer instead of introducing magic.
Re: Three ways of handling user input
#4Does anyone else find approach #3 to be wildly unintuitive? Like how does an infinite loop terminate? There's a lot of magic going on. I like approach #1 the best. Sure, there are some bugs, but a state diagram would help make it clearer instead of introducing magic.
[deleted]
Re: Three ways of handling user input
#5Does anyone else find approach #3 to be wildly unintuitive? Like how does an infinite loop terminate? There's a lot of magic going on. I like approach #1 the best. Sure, there are some bugs, but a state diagram would help make it clearer instead of introducing magic.
Its not that unintuitive once you understand async/await and how the tasks are resumed. Execution is yielded at an await. At that time the loop is not running anywhere, its not even in a sleep state. The loop "terminates" by never being resumed.
Re: Three ways of handling user input
#6Does anyone else find approach #3 to be wildly unintuitive? Like how does an infinite loop terminate? There's a lot of magic going on. I like approach #1 the best. Sure, there are some bugs, but a state diagram would help make it clearer instead of introducing magic.
Its not that unintuitive once you understand async/await and how the tasks are resumed. Execution is yielded at an await. At that time the loop is not running anywhere, its not even in a sleep state. The loop "terminates" by never being resumed.
Yeah that's still not the way the code reads. The closer the code behaves to the way it reads the better in my book.
Re: Three ways of handling user input
#7Does anyone else find approach #3 to be wildly unintuitive? Like how does an infinite loop terminate? There's a lot of magic going on. I like approach #1 the best. Sure, there are some bugs, but a state diagram would help make it clearer instead of introducing magic.
In javascript this feels like unintuitive magic, but for something like Elixir it's a model that actually makes a lot of sense to me.
Re: Three ways of handling user input
#8Using Statecharts or FRP is completely orthogonal to the choice of polling vs. event driven.
Re: Three ways of handling user input
#9Does anyone else find approach #3 to be wildly unintuitive? Like how does an infinite loop terminate? There's a lot of magic going on. I like approach #1 the best. Sure, there are some bugs, but a state diagram would help make it clearer instead of introducing magic.
Its not that unintuitive once you understand async/await and how the tasks are resumed. Execution is yielded at an await. At that time the loop is not running anywhere, its not even in a sleep state. The loop "terminates" by never being resumed.
Wouldn't that result in a thread leak? (Or a "fiber" leak)
Re: Three ways of handling user input
#10Does anyone else find approach #3 to be wildly unintuitive? Like how does an infinite loop terminate? There's a lot of magic going on. I like approach #1 the best. Sure, there are some bugs, but a state diagram would help make it clearer instead of introducing magic.
I feel like approach #3 could have been implemented without abro.or() and it would have been fine and had a little less magic. Though looking at the code I realize you'd need something like `await abro.any(events.pointermove, events.pointerup, windowEvents.keydown)` and a good way to determine which kind of event you got, and finally abro.any() doesn't exist. So maybe abro.or() (representing a group of complementary event handlers) is better than the alternative.