["^ ","~:rename-macros",["^ "],"~:renames",["^ "],"~:use-macros",["^ ","~$console","~$re-frame.loggers"],"~:excludes",["~#set",[]],"~:name","~$re-frame.std-interceptors","~:imports",null,"~:requires",["^ ","~$cofx","~$re-frame.cofx","~$re-frame.interceptor","^=","~$data","~$clojure.data","~$re-frame.trace","^@","~$re-frame.registrar","^A","~$registrar","^A","~$trace","^@","~$re-frame.utils","^D","^4","^4","~$utils","^D","^<","^<","^?","^?","~$re-frame.db","^F"],"~:cljs.spec/speced-vars",[],"~:uses",["^ ","^3","^4","~$assoc-coeffect","^=","~$app-db","^F","~$get-effect","^=","~$->interceptor","^=","~$get-coeffect","^=","~$assoc-effect","^="],"~:defs",["^ ","~$debug",["^ ","^7","~$re-frame.std-interceptors/debug","~:file","out-cli/re_frame/std_interceptors.cljc","~:line",14,"~:column",1,"~:end-line",14,"~:end-column",11,"~:meta",["^ ","^R","/Users/jmmk/Dropbox/clojure/javascript-externs-generator/out-cli/re_frame/std_interceptors.cljc","^S",14,"^T",6,"^U",14,"^V",11],"~:doc","An interceptor which logs/instruments an event handler's actions to\n  `js/console.debug`. See examples/todomvc/src/events.cljs for use.\n\n  Output includes:\n  1. the event vector\n  2. a `clojure.data/diff` of db, before vs after, which shows\n     the changes caused by the event handler.  You will absolutely have\n     to understand https://clojuredocs.org/clojure.data/diff to\n     understand the output.\n\n  You'd typically include this interceptor after (to the right of) any\n  path interceptor.\n\n  Warning:  calling clojure.data/diff on large, complex data structures\n  can be slow. So, you won't want this interceptor present in production\n  code. So condition it out like this :\n\n    (re-frame.core/reg-event-db\n       :evt-id\n       [(when ^boolean goog.DEBUG re-frame.core/debug)]  ;; <-- conditional\n       (fn [db v]\n         ...))\n\n  To make this code fragment work, you'll also have to set goog.DEBUG to\n  false in your production builds - look in `project.clj` of /examples/todomvc.\n  ","~:tag","~$any"],"~$trim-v",["^ ","^7","~$re-frame.std-interceptors/trim-v","^R","out-cli/re_frame/std_interceptors.cljc","^S",65,"^T",1,"^U",65,"^V",12,"^W",["^ ","^R","/Users/jmmk/Dropbox/clojure/javascript-externs-generator/out-cli/re_frame/std_interceptors.cljc","^S",65,"^T",6,"^U",65,"^V",12],"^X","An interceptor which removes the first element of the event vector,\n  allowing you to write more aesthetically pleasing event handlers. No\n  leading underscore on the event-v!\n  Your event handlers will look like this:\n\n      (defn my-handler\n        [db [x y z]]    ;; <-- instead of [_ x y z]\n        ....)","^Y","^Z"],"~$db-handler->interceptor",["^ ","~:protocol-inline",null,"^W",["^ ","^R","/Users/jmmk/Dropbox/clojure/javascript-externs-generator/out-cli/re_frame/std_interceptors.cljc","^S",93,"^T",7,"^U",93,"^V",30,"~:arglists",["~#list",["~$quote",["^14",[["~$handler-fn"]]]]],"^X","Returns an interceptor which wraps the kind of event handler given to `reg-event-db`.\n\n  These handlers take two arguments;  `db` and `event`, and they return `db`.\n\n  (fn [db event]\n     ....)\n\n  So, the interceptor wraps the given handler:\n     1. extracts two `:coeffects` keys: db and event\n     2. calls handler-fn\n     3. stores the db result back into context's `:effects`"],"^7","~$re-frame.std-interceptors/db-handler->interceptor","~:variadic",false,"^R","out-cli/re_frame/std_interceptors.cljc","^V",30,"~:method-params",["^14",[["^16"]]],"~:protocol-impl",null,"~:arglists-meta",["^14",[null,null]],"^T",1,"^S",93,"^U",93,"~:max-fixed-arity",1,"~:fn-var",true,"^13",["^14",["^15",["^14",[["^16"]]]]],"^X","Returns an interceptor which wraps the kind of event handler given to `reg-event-db`.\n\n  These handlers take two arguments;  `db` and `event`, and they return `db`.\n\n  (fn [db event]\n     ....)\n\n  So, the interceptor wraps the given handler:\n     1. extracts two `:coeffects` keys: db and event\n     2. calls handler-fn\n     3. stores the db result back into context's `:effects`"],"~$fx-handler->interceptor",["^ ","^12",null,"^W",["^ ","^R","/Users/jmmk/Dropbox/clojure/javascript-externs-generator/out-cli/re_frame/std_interceptors.cljc","^S",125,"^T",7,"^U",125,"^V",30,"^13",["^14",["^15",["^14",[["^16"]]]]],"^X","Returns an interceptor which wraps the kind of event handler given to `reg-event-fx`.\n\n  These handlers take two arguments;  `coeffects` and `event`, and they return `effects`.\n\n  (fn [coeffects event]\n     {:db ...\n      :dispatch ...})\n\n   Wrap handler in an interceptor so it can be added to (the RHS) of a chain:\n     1. extracts `:coeffects`\n     2. call handler-fn giving coeffects\n     3. stores the result back into the `:effects`"],"^7","~$re-frame.std-interceptors/fx-handler->interceptor","^18",false,"^R","out-cli/re_frame/std_interceptors.cljc","^V",30,"^19",["^14",[["^16"]]],"^1:",null,"^1;",["^14",[null,null]],"^T",1,"^S",125,"^U",125,"^1<",1,"^1=",true,"^13",["^14",["^15",["^14",[["^16"]]]]],"^X","Returns an interceptor which wraps the kind of event handler given to `reg-event-fx`.\n\n  These handlers take two arguments;  `coeffects` and `event`, and they return `effects`.\n\n  (fn [coeffects event]\n     {:db ...\n      :dispatch ...})\n\n   Wrap handler in an interceptor so it can be added to (the RHS) of a chain:\n     1. extracts `:coeffects`\n     2. call handler-fn giving coeffects\n     3. stores the result back into the `:effects`"],"~$ctx-handler->interceptor",["^ ","^12",null,"^W",["^ ","^R","/Users/jmmk/Dropbox/clojure/javascript-externs-generator/out-cli/re_frame/std_interceptors.cljc","^S",156,"^T",7,"^U",156,"^V",31,"^13",["^14",["^15",["^14",[["^16"]]]]],"^X","Returns an interceptor which wraps the kind of event handler given to `reg-event-ctx`.\n  These advanced handlers take one argument: `context` and they return a modified `context`.\n  Example:\n     (fn [context]\n        (enqueue context [more interceptors]))"],"^7","~$re-frame.std-interceptors/ctx-handler->interceptor","^18",false,"^R","out-cli/re_frame/std_interceptors.cljc","^V",31,"^19",["^14",[["^16"]]],"^1:",null,"^1;",["^14",[null,null]],"^T",1,"^S",156,"^U",156,"^1<",1,"^1=",true,"^13",["^14",["^15",["^14",[["^16"]]]]],"^X","Returns an interceptor which wraps the kind of event handler given to `reg-event-ctx`.\n  These advanced handlers take one argument: `context` and they return a modified `context`.\n  Example:\n     (fn [context]\n        (enqueue context [more interceptors]))"],"~$path",["^ ","^12",null,"^W",["^ ","^R","/Users/jmmk/Dropbox/clojure/javascript-externs-generator/out-cli/re_frame/std_interceptors.cljc","^S",181,"^T",7,"^U",181,"^V",11,"^13",["^14",["^15",["^14",[["~$&","~$args"]]]]],"^X","returns an interceptor whose `:before` substitutes the coeffects `:db` with\n  a sub-path of `:db`. Within `:after` it grafts the handler's return value\n  back into db, at the right path.\n\n  So, its overall action is to make the event handler behave like the function\n  you might give to clojure's `update-in`.\n\n  Examples:\n    (path :some :path)\n    (path [:some :path])\n    (path [:some :path] :to :here)\n    (path [:some :path] [:to] :here)\n\n  Example Use:\n\n    (reg-event-db\n      :event-id\n      (path [:a :b])  ;; used here, in interceptor chain\n      (fn [b v]       ;; 1st arg is now not db. Is the value from path [:a :b] within db\n        ... new-b))   ;; returns a new value for that path (not the entire db)\n\n  Notes:\n    1. `path` may appear more than once in an interceptor chain. Progressive narrowing.\n    2. if `:effects` contains no `:db` effect, can't graft a value back in.\n  ","~:top-fn",["^ ","^18",true,"^1<",0,"^19",[["^14",["^1C"]]],"^13",["^14",[["~$&","^1C"]]],"^1;",["^14",[null]]]],"^7","~$re-frame.std-interceptors/path","^18",true,"^R","out-cli/re_frame/std_interceptors.cljc","^V",11,"^1D",["^ ","^18",true,"^1<",0,"^19",[["^14",["^1C"]]],"^13",["^14",[["~$&","^1C"]]],"^1;",["^14",[null]]],"^19",[["^14",["^1C"]]],"^1:",null,"^1;",["^14",[null]],"^T",1,"^S",181,"^U",181,"^1<",0,"^1=",true,"^13",["^14",[["~$&","^1C"]]],"^X","returns an interceptor whose `:before` substitutes the coeffects `:db` with\n  a sub-path of `:db`. Within `:after` it grafts the handler's return value\n  back into db, at the right path.\n\n  So, its overall action is to make the event handler behave like the function\n  you might give to clojure's `update-in`.\n\n  Examples:\n    (path :some :path)\n    (path [:some :path])\n    (path [:some :path] :to :here)\n    (path [:some :path] [:to] :here)\n\n  Example Use:\n\n    (reg-event-db\n      :event-id\n      (path [:a :b])  ;; used here, in interceptor chain\n      (fn [b v]       ;; 1st arg is now not db. Is the value from path [:a :b] within db\n        ... new-b))   ;; returns a new value for that path (not the entire db)\n\n  Notes:\n    1. `path` may appear more than once in an interceptor chain. Progressive narrowing.\n    2. if `:effects` contains no `:db` effect, can't graft a value back in.\n  "],"~$enrich",["^ ","^12",null,"^W",["^ ","^R","/Users/jmmk/Dropbox/clojure/javascript-externs-generator/out-cli/re_frame/std_interceptors.cljc","^S",235,"^T",7,"^U",235,"^V",13,"^13",["^14",["^15",["^14",[["~$f"]]]]],"^X","Interceptor factory which runs the given function `f` in the `after handler`\n  position.  `f` is called with two arguments: `db` and `v`, and is expected to\n  return a modified `db`.\n\n  Unlike the `after` interceptor which is only about side effects, `enrich`\n  expects `f` to process and alter the given `db` coeffect in some useful way,\n  contributing to the derived data, flowing vibe.\n\n  Example Use:\n  ------------\n\n  Imagine that todomvc needed to do duplicate detection - if any two todos had\n  the same text, then highlight their background, and report them via a warning\n  at the bottom of the panel.\n\n  Almost any user action (edit text, add new todo, remove a todo) requires a\n  complete reassessment of duplication errors and warnings. Eg: that edit\n  just made might have introduced a new duplicate, or removed one. Same with\n  any todo removal. So we need to re-calculate warnings after any CRUD events\n  associated with the todos list.\n\n  Unless we are careful, we might end up coding subtly different checks\n  for each kind of CRUD operation.  The duplicates check made after\n  'delete todo' event might be subtly different to that done after an\n  editing operation. Nice and efficient, but fiddly. A bug generator\n  approach.\n\n  So, instead, we create an `f` which recalculates ALL warnings from scratch\n  every time there is ANY change. It will inspect all the todos, and\n  reset ALL FLAGS every time (overwriting what was there previously)\n  and fully recalculate the list of duplicates (displayed at the bottom?).\n\n  https://twitter.com/nathanmarz/status/879722740776939520\n\n  By applying `f` in an `:enrich` interceptor, after every CRUD event,\n  we keep the handlers simple and yet we ensure this important step\n  (of getting warnings right) is not missed on any change.\n\n  We can test `f` easily - it is a pure function - independently of\n  any CRUD operation.\n\n  This brings huge simplicity at the expense of some re-computation\n  each time. This may be a very satisfactory trade-off in many cases."],"^7","~$re-frame.std-interceptors/enrich","^18",false,"^R","out-cli/re_frame/std_interceptors.cljc","^V",13,"^19",["^14",[["~$f"]]],"^1:",null,"^1;",["^14",[null,null]],"^T",1,"^S",235,"^U",235,"^1<",1,"^1=",true,"^13",["^14",["^15",["^14",[["~$f"]]]]],"^X","Interceptor factory which runs the given function `f` in the `after handler`\n  position.  `f` is called with two arguments: `db` and `v`, and is expected to\n  return a modified `db`.\n\n  Unlike the `after` interceptor which is only about side effects, `enrich`\n  expects `f` to process and alter the given `db` coeffect in some useful way,\n  contributing to the derived data, flowing vibe.\n\n  Example Use:\n  ------------\n\n  Imagine that todomvc needed to do duplicate detection - if any two todos had\n  the same text, then highlight their background, and report them via a warning\n  at the bottom of the panel.\n\n  Almost any user action (edit text, add new todo, remove a todo) requires a\n  complete reassessment of duplication errors and warnings. Eg: that edit\n  just made might have introduced a new duplicate, or removed one. Same with\n  any todo removal. So we need to re-calculate warnings after any CRUD events\n  associated with the todos list.\n\n  Unless we are careful, we might end up coding subtly different checks\n  for each kind of CRUD operation.  The duplicates check made after\n  'delete todo' event might be subtly different to that done after an\n  editing operation. Nice and efficient, but fiddly. A bug generator\n  approach.\n\n  So, instead, we create an `f` which recalculates ALL warnings from scratch\n  every time there is ANY change. It will inspect all the todos, and\n  reset ALL FLAGS every time (overwriting what was there previously)\n  and fully recalculate the list of duplicates (displayed at the bottom?).\n\n  https://twitter.com/nathanmarz/status/879722740776939520\n\n  By applying `f` in an `:enrich` interceptor, after every CRUD event,\n  we keep the handlers simple and yet we ensure this important step\n  (of getting warnings right) is not missed on any change.\n\n  We can test `f` easily - it is a pure function - independently of\n  any CRUD operation.\n\n  This brings huge simplicity at the expense of some re-computation\n  each time. This may be a very satisfactory trade-off in many cases."],"~$after",["^ ","^12",null,"^W",["^ ","^R","/Users/jmmk/Dropbox/clojure/javascript-externs-generator/out-cli/re_frame/std_interceptors.cljc","^S",293,"^T",7,"^U",293,"^V",12,"^13",["^14",["^15",["^14",[["~$f"]]]]],"^X","returns an interceptor which runs a given function `f` in the `:after`\n  position, presumably for side effects.\n\n  `f` is called with two arguments: the `:effects` value for `:db`\n  (or the `coeffect` value of db if no db effect is returned) and the event.\n  Its return value is ignored, so `f` can only side-effect.\n\n  Examples use can be seen in the /examples/todomvc:\n     - `f` runs schema validation (reporting any errors found).\n     - `f` writes to localstorage."],"^7","~$re-frame.std-interceptors/after","^18",false,"^R","out-cli/re_frame/std_interceptors.cljc","^V",12,"^19",["^14",[["~$f"]]],"^1:",null,"^1;",["^14",[null,null]],"^T",1,"^S",293,"^U",293,"^1<",1,"^1=",true,"^13",["^14",["^15",["^14",[["~$f"]]]]],"^X","returns an interceptor which runs a given function `f` in the `:after`\n  position, presumably for side effects.\n\n  `f` is called with two arguments: the `:effects` value for `:db`\n  (or the `coeffect` value of db if no db effect is returned) and the event.\n  Its return value is ignored, so `f` can only side-effect.\n\n  Examples use can be seen in the /examples/todomvc:\n     - `f` runs schema validation (reporting any errors found).\n     - `f` writes to localstorage."],"~$on-changes",["^ ","^12",null,"^W",["^ ","^R","/Users/jmmk/Dropbox/clojure/javascript-externs-generator/out-cli/re_frame/std_interceptors.cljc","^S",317,"^T",8,"^U",317,"^V",18,"^13",["^14",["^15",["^14",[["~$f","~$out-path","~$&","~$in-paths"]]]]],"^X","Interceptor factory which acts a bit like `reaction`  (but it flows into\n  `db`, rather than out). It observes N paths within `db` and if any of them\n  test not identical? to their previous value  (as a result of a event handler\n  being run) then it runs `f` to compute a new value, which is then assoc-ed\n  into the given `out-path` within `db`.\n\n  Usage:\n\n  (defn my-f\n    [a-val b-val]\n    ... some computation on a and b in here)\n\n  (on-changes my-f [:c]  [:a] [:b])\n\n  Put this Interceptor on the right handlers (ones which might change :a or :b).\n  It will:\n     - call `f` each time the value at path [:a] or [:b] changes\n     - call `f` with the values extracted from [:a] [:b]\n     - assoc the return value from `f` into the path  [:c]\n  ","^1D",["^ ","^18",true,"^1<",2,"^19",[["^14",["~$f","^1K","^1L"]]],"^13",["^14",[["~$f","^1K","~$&","^1L"]]],"^1;",["^14",[null]]]],"^7","~$re-frame.std-interceptors/on-changes","^18",true,"^R","out-cli/re_frame/std_interceptors.cljc","^V",18,"^1D",["^ ","^18",true,"^1<",2,"^19",[["^14",["~$f","^1K","^1L"]]],"^13",["^14",[["~$f","^1K","~$&","^1L"]]],"^1;",["^14",[null]]],"^19",[["^14",["~$f","^1K","^1L"]]],"^1:",null,"^1;",["^14",[null]],"^T",1,"^S",317,"^U",317,"^1<",2,"^1=",true,"^13",["^14",[["~$f","^1K","~$&","^1L"]]],"^X","Interceptor factory which acts a bit like `reaction`  (but it flows into\n  `db`, rather than out). It observes N paths within `db` and if any of them\n  test not identical? to their previous value  (as a result of a event handler\n  being run) then it runs `f` to compute a new value, which is then assoc-ed\n  into the given `out-path` within `db`.\n\n  Usage:\n\n  (defn my-f\n    [a-val b-val]\n    ... some computation on a and b in here)\n\n  (on-changes my-f [:c]  [:a] [:b])\n\n  Put this Interceptor on the right handlers (ones which might change :a or :b).\n  It will:\n     - call `f` each time the value at path [:a] or [:b] changes\n     - call `f` with the values extracted from [:a] [:b]\n     - assoc the return value from `f` into the path  [:c]\n  "]],"~:cljs.spec/registry-ref",[],"~:require-macros",["^ ","^C","^@","^@","^@"],"~:cljs.analyzer/constants",["^ ","~:seen",["^6",["~:path","~:tags","~:group","~:db","~:fx-handler","~:re-frame.std-interceptors/not-found","~:operation","~:start","~:duration","~:debug","~:trim-v","~:event/handler","~:db-handler","~:event","~:after","~:id","~:effects","~:error","~:coeffects","~:re-frame-path/db-store","~:end","~:on-changes","~:groupEnd","~:ctx-handler","~:enrich","~:before","~:op-type","~:log","~:re-frame.std-interceptors/untrimmed-event"]],"~:order",["^25","^1[","^2?","^2A","^23","^24","^1U","^1W","^1T","^2<","^20","^28","^2B","^22","^2@","^1X","^21","^1Y","^1Z","^2:","^1S","^26","^1V","^2=","^29","^27","^1R","^2>","^2;"]],"^X","contains re-frame supplied, standard interceptors"]