Closed joshcho closed 1 year ago
The workaround I am using at the moment is specifying the id like so:
(defn my-on-changes
[interceptor-id & rest]
(assoc (apply rf/on-changes rest)
:id interceptor-id))
It also seems like with this method, the interceptors are applied in reverse order.
Hey @joshcho, interesting problem.
I considered changing the :id to include a hash of the args, but I think this would interfere with the simplicity of the library. Not all names in std-interceptors are factories, some are values. It's not so nice to have to hold onto an auto-generated id if you want to clear the interceptor later, or select it somehow. Dealing with extra arities or option maps for the id isn't so nice either.
While it would be nice if this just worked, I think it's okay to consider your use-case non-standard. I added some documentation for it.
If you'd like the ergonomics in your first example, consider:
(defn my-on-changes [& args]
(-> (apply rf/on-changes args)
(update :id #(keyword (str (name %) "__" (hash args))))))
What happened?
Using rf/on-changes multiple times and registering them via rf/reg-global-interceptor does not work.
So something like:
will not work. I believe this is because rf/on-changes creates interceptors with the same id.
Version
1.3.0
What runtimes are you seeing the problem on?
Brave
Relevant console output
No response