Closed debois closed 7 years ago
Is this an elm-upstream bug? I always wondered how to deal with that on the Elm side as events cannot be conditionally prevented.
It might be, but I'm not sure: I also don't know how to do this, but I didn't think hard about it.
There is a hackish way again I believe to 'fix' this. Not sure if there is a way to do this in Elm yet
Yeah unsure either, this is precisely why my Helpers library has a Helpers.msg_ignore
function (used like Helpers.msg_ignore Helpers
where Helpers is my Message type that encompasses the Helpers messages).
I think this is an elm-upstream bug because I am assuming that value
is broken and we should replace it with defaultValue
. I will open a separate issue for that.
I am assuming, you, @vipentti, @OvermindDL1, are talking about a solution that uses value
? In any case, I would be curious to see code samples of your solutions.
Actually I am working on a program-wrapping library that makes it almost trivially easy to conditionally handle events. ^.^
Either way I handle I think it was "onKeyPress" or "onInput" or something (I have a lot of custom callbacks that preventDefault because of old javascript in that app that would break things otherwise) and I just conditionally either return my handling message or another. Every onInput I do reset the message to a 'cleaned' version, so I can 'cancel' specific keycode by just 'msg_ignore' instead, which then wipes the enter they put. Not perfectly clean, but simple.
@OvermindDL1 can you preventDefault
on specific key-codes like that? Say I want every key but spacebar do what it usually does, but I want to suppress spacebar?
(I might want that if I'm listening for shortcut keys globally, but for some reason I don't want spacebar to scroll.)
@OvermindDL1 can you preventDefault on specific key-codes like that? Say I want every key but spacebar do what it usually does, but I want to suppress spacebar?
Not that I've seen sadly, elm is lacking in a lot of different ways. So I just preventDefault on everything and handle things explicitly. Ugly, but elm libraries are very incomplete.
I've actually just finished making a first version of a library that helps clean up the testing boilerplate. Can see my examples of it at: https://groups.google.com/forum/#!topic/elm-discuss/u_30Y4iueRY
It actually works really well at cleaning up the boilerplate of things.
I think preventing everything and re-implementing desired browser behavior is not the way to go. Because, in my experience it works out well with keyboard input, it gets finicky once you realize that your cursor is not always positioned at the end, and it gets absurd once you try to mimic replacing a selection and adding support for both browser and operating system dependent shortcuts like Ctrl-u.
Very true yeah, hence why Elm really badly needs a way to specify those on the outgoing step...
I agree with @aforemny, we want to avoid re-implementing browser functionality if at all possible.
@OvermindDL1: I see what you're trying to do with boilerplate reduction. You might find it helpful to take a closer look at debois/elm-parts. We could maybe discuss this further on the elm-slack—could you look me up (@debois)?
I have been looking at elm-parts yeah, components made in it (like elm-mdl) work perfectly with the delegate functionality of my testing code. Combined it is very nice (I'm using it in production now, unsure if I really should, but it seems to work perfectly and has saved me a ton of code so far).
I usually use Gitter.im (more integrated with Github but otherwise it is Slack'ish) but I can hop on slack on occasion too.
Implemented in new-v8 (b16f79b1feef8fecd483ec96f4030f5fe6c7babe).
Upstream has this code: