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. https://github.com/gadfly361/re-pressed

@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?

(ratom/make-reaction
  (fn []
    @(ratom/make-reaction
       (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?