Fork me on GitHub
#re-frame
<
2016-12-26
>
andre09:12:01

comments are opened

manenko19:12:30

Hello everyone

manenko19:12:34

So... he told us "namespaced keywords are good, use them". OK. I use namespaced keywords for subs, events and db. For example:

(ns com.manenko.pm-assistant.projects.events
  (:require [re-frame.core :as re-frame]))

(re-frame/reg-event-db
 ::sort-by
 (fn [db [_ k]]
   db))
Here we are: ::sort-by is a namespaced keyword and it will be expanded to :com.manenko.pm-assistant.projects.events/sort-by. Now, I want to dispatch this event somewhere. I can do this:
(re-frame/dispatch [:com.manenko.pm-assistant.projects.events/sort-by :com.manenko.pm-assistant.projects.db/name])
which is too verbose and long... I can
(:require [com.manenko.pm-assistant.projects.events :as events]
          [com.manenko.pm-assistant.projects.db     :as db])
and then do this:
(re-frame/dispatch [::events/sort-by ::db/name])
which is much better. But I don't like the idea of importing a namespace just to use aliased keywords. Is there any way to use aliases for namespaces without importing them? One possible workaround is to define an empty namespace just for keywords. But this seems to be overkill to me.

manenko19:12:15

Probably this is a question for #clojure channel, but I wonder if someone else have faced with this as well...

gadfly36120:12:03

@manenko while i personally prefer what you are trying to avoid. I believe the docs recommend a synthetic namespaced keyword. So when defining a keyword, you could write :synthetic-space1/event-name instead of ::event-name. This approach grants you a couple things 1) you dont have to require the namespace the keyword was defined in to use it because it is not a true namespaced keyword, and 2) the name of the synthetic-namespaced-keyword does not have to be 1:1 with the namespace the synthetic-namespaced-keyword was defined in.

manenko20:12:55

Yes, that was the first thing I tried before switching to namespaced keywords. What I don’t like about synthetic namespaced keywords is that they aren’t that unique comparing to real namespaced keywords (that’s especially true for specs, and db).

gadfly36120:12:07

For sure, i am with you on that

geoffs20:12:45

Why aren’t they as unique? You can still add arbitrary segments to them… I use synthetic-namespaced keywords a lot, and just give them namespace segments to match the semantics of what I’m using the key for. For instance, a recent example working with specs for data for a game AI perceiving things:

(s/def :<project-name>.ai/perception …)
(s/def :<project-name>.ai.perception/visual …)
(s/def :<project-name>.ai.perception/auditory …)

geoffs20:12:51

granted, I haven’t done a ton of work with syntheticly-namespaced keywords so maybe I’m missing something.

geoffs20:12:10

but for re-frame event subscriptions I might do something like this:

:<app-name>.sub.<page-name>

geoffs20:12:45

It’s a bit shorter than the example you gave, and I can still have subscriptions with the same keyword name on different pages of the app

geoffs20:12:27

I also like the synthetic names better because they have better searchability since you always write them the same way

mikethompson23:12:44

@manenko I'd be using synthetic namespaces which deliver the most meaning to the reader of the code (much like variable names). Yes, they must be unique, but I've never found that bit at all hard.

smnplk23:12:42

Howdy! Congrats on new re-frame documentation, it's much better than previous philosophy thesis 😄 It got me back to fiddling with re-frame. I am still a bit confused about event handlers. When would I use reg-event-fx instead of reg-event-db ? reg-event-db expects handlers to receive 2 params, first one is current db and second is one additional parameter. I know I need to read the whole docs before asking questions, but I'm eager 😛

mikethompson23:12:54

@smnplk the -fx variation provides a way to get alternative "inputs" (aka coeffects) over and above just db, and it also provides a way to nominate effects (side effects) other than just "update the app state".

mikethompson23:12:32

---- So the rule would be: generally you reach for the -db version, unless you have specific reason to use -fx. And that reason would be: I need a coeffect like a radom number or a GUID or something out of localstore. OR that reason would be: I need to change the world in some way other than to just update app-db.

mikethompson23:12:25

And don't think you can get away from the philosophy ! https://github.com/Day8/re-frame/blob/master/docs/MentalModelOmnibus.md It is still there, lurking. Waiting.

smnplk23:12:25

@mikethompson Ok, I kind of get it now, but still, maybe I am a bit confused by terminology used. So effects are returned by handlers, and usually this is just a map, like {:db (assoc-in db :active-page :home-page)}, but I have a feeling that this is not the whole story, what can effect also be ? So what would my special handler that i registered with reg-event-fx actually return ?

mikethompson23:12:11

I'll explain it this way: event handlers always return effects.

mikethompson23:12:33

The -fx variation returns a map of them. N effects.

smnplk23:12:39

maybe i need to look at the example code. 🙂 Hehe, yeah I had a feeling about that, I still need to read the omnibus part 🙂

mikethompson23:12:43

The -db version only returns one effect

mikethompson23:12:00

So it it a case of 1 vs N

smnplk23:12:10

Ohh. I see now.

mikethompson23:12:03

Before you do much coding, you'll need to read the main README and the Introduction section https://github.com/Day8/re-frame/blob/master/docs/README.md

smnplk23:12:53

Omg, I need read that whole page about effectful handlers, I was apparently blind. I will come back if I'm still missing something. Thanks Mike.