This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-09-26
Channels
- # arachne (4)
- # beginners (70)
- # bigdata (1)
- # boot (373)
- # braid-chat (3)
- # cider (4)
- # cljs-dev (10)
- # cljsjs (6)
- # cljsrn (27)
- # clojars (11)
- # clojure (114)
- # clojure-austria (1)
- # clojure-czech (2)
- # clojure-dusseldorf (2)
- # clojure-greece (7)
- # clojure-italy (2)
- # clojure-nl (6)
- # clojure-russia (15)
- # clojure-serbia (11)
- # clojure-spec (92)
- # clojure-uk (5)
- # clojurescript (183)
- # component (9)
- # cursive (28)
- # datomic (36)
- # editors (4)
- # emacs (1)
- # garden (11)
- # hoplon (155)
- # lein-figwheel (7)
- # mount (47)
- # om (97)
- # onyx (25)
- # proton (3)
- # rdf (3)
- # re-frame (80)
- # reagent (9)
- # ring-swagger (9)
- # spacemacs (1)
- # untangled (145)
- # vim (2)
made some improvements in 0.1.2 https://github.com/flexsurfer/re-frisk
By the way you made a typo in your description, it should be: >>> Visualize re-frame pattern data in your re-frame apps as a tree structure.
@andre: I get this error trying to compile my app with re-frisk
Invalid :refer, var re-frame.core/def-sub does not exist in file app/resources/js/compiled/dev/re_frisk/core.cljs
I’m using re-frame 0.8.0 and reagent 0.6.0
Its (reg-sub :name (fn [db _] …))
in 0.8.0
@shaun-mahood Thanks. Some might read this as a non-answer, but it assures me that I am not missing something obvious.
I think its the same for 0.7.x
I’m actually not sure. def-sub
is a macro, right?
You could always check if the symbol is defined, like (find-var ‘re-frame.core/def-sub)
, but I’m not sure if thats necessarily a good idea
I think this is quite a general question anyway, its not just clojure libraries that have this issue.
I’d just create a new release for 0.8.0
So, you have 0.1.2
, I’d do something like 0.2.0
supports reframe 0.7.x
and upwards
@kalouantonis you can try 0.1.3
Well, that was quick
I wish I could release my apps that fast 😄
Its compiling now, but I’m not seeing anything on the UI:
(defonce debug-setup!
(do (when config/debug?
(enable-console-print!)
(enable-re-frisk!)
(devtools/install!))))
Ah, never mind, I had to set {:x 200 :y 200}
Probably because I have a navbar in the way
This is actually really cool. I had to always do (require ‘[re-frame.db :refer [app-db]]) @app-db
before
I can’t scroll though, are you planning on adding that?
Also, is re-frisk meant to be emitting console output like "Emit: " 0 :contract ([:app-db])
?
i'm using https://github.com/Odinodin/data-frisk-reagent lib for showing data, and it emitting console, I'll think about what to do
I can scroll horizontally, but not vertically
Perhaps its because of the way I have my page configured. It may also be that I’m running it in electron?
what happen then you open more data? does window resize? try to resize window before expand data
Yea, :height
fixes it
One last question. I include re-frisk
as only a dev dependency, but I’m supposed to define my views using def-view
. What happens when I’m building for production? def-view
won’t be available any more
I made an option in the compiler for this purpose, in production without this option def-view just generate defn without any re-frisk code
But if I have it in
:profiles
{:dev {:dependencies [[com.cemerick/piggieback "0.2.1"]
[figwheel-sidecar "0.5.0-2"]
[re-frisk "0.1.3"]]
:source-paths ["src/clj" "src/cljs" "dev"]}}
doesn’t that mean that the entire re-frisk
dependency will be removed when building in production mode?Ok, great. Thanks
or you can use it in the project :dependencies and provide compiler option only for dev profile, thank you for your help.
Is it possible sending multiple dispatches in one single reg-event-fx
handler? Ex:
{:db (do something)
:dispatch [:my-first-event :my-second-event]}
@looveh: I think you're looking for the dispatch-n
fn
Yes:
{:db (do-something)
:dispatch-n (list [:my-first-event] [:my-second-event])}
@reefersleep @kalouantonis Yes that’s it, thank you!
@mikethompson: I just tried out day8.re-frame.http-fx
for the first time, in the readme it says that :response-format
is optional. When I leave it out of my map, I get an error from router.cljs of "unrecognied response format: nil" - is this just a problem with the readme or something else?
@shaun-mahood I think that's a problem with the README. @superstructor mentioned something similar previously
We will have a look at fixing that.
yep you need to provide a response format fn
my bad for not submitting that change yet 😞
we do something like this, which is kind of specialised to our use case:
(defn maybe-empty-json-response-format
"Returns a JSON response format. Options include
:keywords? Returns the keys as keywords
:prefix A prefix that needs to be stripped off. This is to
combat JSON hijacking. If you're using JSON with GET request,
you should think about using this.
This is identical to cljs-ajax's `json-response-format` except
that it permits empty/null values as valid entities regardless of
response status code, allowing such things as 200 OK with no entity
body (instead of strictly expecting 204 (No Content))."
([] (maybe-empty-json-response-format {}))
([{:keys [prefix keywords? raw]}]
(ajax/map->ResponseFormat
{:read (fn [xhrio]
(let [body (ajax.protocols/-body xhrio)]
(if (empty? (cstr/trim (or body "")))
{}
(let [text (ajax/strip-prefix prefix body)
json (goog-json/parse text)]
(if raw
json
(js->clj json :keywordize-keys keywords?))))))
:description (str "JSON"
(if prefix (str " prefix '" prefix "'"))
(if keywords? " keywordize"))
:content-type ["application/json", "application/hal+json"]})))
then in xhrio options we do :response-format (maybe-empty-json-response-format)
I’ve been saying I’ll get around to this for a long time so happy to do a pull request today @mikethompson only question would be would you want all of the above esp regarding: - the support for empty bodies in 200 OKs - the support for prefix stripping / anti JSON hijacking - the hal+json content type support ? (probably not?)
The more information the better, I think
(Which is very open ended of me, i know)
you want this purely in the README or do you want to provide a default JSON response format fn impl ?
How much variation do you think there will be in terms of needs?
If quite some variation, we could go Wiki
Making it easy to add further variation?
Let me put it this way ... which way would have made more sense for you and @shaun-mahood?
Having a default would be a nice convenience in my opinion
I can see at least 3 variations in the above example (empty body on 200 OK, prefix stripping and hal+json)
I would suggest parameterizing the first two and omitting hal+json but allowing overriding content types as another parameter
You have a better diea about this stuff than I ... so I'm very happy to go with whatever you think
I think something like that would get most people up and running with JSON-based APIs more quickly.
That would be terrific, thanks.
Otherwise we found we had to delve deep into cljs-ajax to work out how response format fns work, which is feasible, but not ideal to be thinking about all that when all you want is a response map in your handler
Agreed