Fork me on GitHub

i've come across a couple of errors in our app recently of the "handler switches view, but some of the require data is missing and bork" variety. ad-hoc solutions are straightforward, but i'm wondering about a generic solution which would hold a ref to the app-db value before update, and if any sub or view run consequently to the app-db update throws an exception then rollback the change and dispatch a descriptive error event


has anyone implement such a thing already - @mikethompson ?


Hey all, Just made Re-Pressed, a keyboard event library for re-frame.

👍 36

Very relevant for me! I just implemented keyboard control in a small app of mine and was surprised with the unaligned keyCode/keyChar values of events in various browsers.


@gadfly361 do you have any general advice on keys to avoid overriding or stuff like that?


e.g., I’ve got an app where I’m assigning the space button to cycle through items, and I don’t ever expect the app to need the normal space behaviour, scrolling down. But I don’t know if it’s generally a bad idea to do, maybe for reasons yet unknown to me 🙂


Maybe you know some sources on the topic


@U0AQ3HP9U this is a list of shared shortcuts in browsers that I'd probably recommend not overriding unless you need to:


@U0AQ3HP9U and this one is decent for general perspective. My take aways are don't forget multiple character shortcuts, and also discoverability of the shortcuts themselves


I plan to utilize re-learn to inform people about the shortcuts. The app has a very narrow scope - the shortcuts are your main interaction in the app, so it’s not like they’ll be too hidden


Cheers, thanks a lot!


@gadfly361 That looks really nice. I have one question. If I read the code correctly it goes like this: "key-pressed" -> "lookup event table for key pressed" -> "excute event". But what about different contexts. Especially the Enter key may execute different events depending on the current form, etc. Am I missing something?


@sveri the event table is dynamic, so you'd just change it depending on context with set-keydown-event (or with the key press keyup variants). I usually set it explicitly for each page (but there is nothing stopping you from doing it more or less often)


Ah, so you basically create an event table for every "view", correct?


Yeah, that's what I'd recommend


Ok, that sounds reasonable, I was just unsure, because in your documentation, you have this line: (re-frame/dispatch-sync [::rp/add-keyboard-event-listener "keydown"])in the init function. Which, if you follow the general re-frame templates, is only called on pageload, but not when fighweel reloads the page, which would be the mount-rootfunction.


Thanks for the library, I will definitly give it a try.


Thanks for the feedback, I should make the docs more clear. The gist is 1. Set an event listener for keydown, keypress, or keyup (once when app starts) 2. Set / update event rules table (whenever and as many times as you want)


Looks awesome imo


Are there any potential problems from doing something like this within a sub handler function?

  (fn []
       (fn []
         ;; do stuff


The main thing I am concerned about is a possible memory leak from the inner make-reaction. Perhaps Reagent handles this without a problem?