re-frame

https://github.com/Day8/re-frame/blob/master/docs/README.md https://github.com/Day8/re-frame/blob/master/docs/External-Resources.md
Oz 2020-10-07T13:41:34.049500Z

I have a lot of (re-frame/reg-event-db ...) rolling around Any reason against doing

(def db-events {:event1 handler1
                :event2 handler2})
And then (map reg-event-db db-events) Just for the sake of saving characters πŸ˜…

p-himik 2020-10-07T13:46:47.049600Z

I do it sometimes. Only not map but doseq because map is lazy.

πŸ‘ 1
p-himik 2020-10-07T13:47:17.049800Z

The issue with such approach is that it would make it harder to selectively change interceptors.

πŸ‘ 1
Oz 2020-10-07T13:50:41.050Z

Thank you, I don't have interceptors currently so didn't think about it

p-himik 2020-10-07T13:54:29.050400Z

And BTW I don't do it when I have just regular event IDs with corresponding handlers - I just call reg-event-* as usual in such cases. But I always do it when I have roughly the same handler for a bunch of events. Then I iterate over event IDs with maybe some parameters that slightly alter how the handler works.

πŸ‘ 1
victorb 2020-10-07T14:19:38.050600Z

slightly unrelated but a little bit related, check out https://gitlab.com/nikperic/reframe-utils if you haven't, removes a modest amount of boilerplate

πŸ‘ 1
Oz 2020-10-07T14:41:40.051400Z

Interesting

Oliver George 2020-10-07T20:27:13.055300Z

I like the idea but don’t use it currently. One possible complication is code reloading. Does the code change trigger re-registering the event? Does re-frame throw a lot of re-register warnings?

Oliver George 2020-10-07T20:27:22.055700Z

All solvable

p-himik 2020-10-07T20:33:03.055900Z

It doesn't affect code reloading at all.