This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # architecture (9)
- # beginners (192)
- # boot (1)
- # bristol-clojurians (2)
- # cider (213)
- # cljs-dev (10)
- # clojure (195)
- # clojure-art (2)
- # clojure-austin (3)
- # clojure-belgium (4)
- # clojure-dev (4)
- # clojure-dusseldorf (1)
- # clojure-gamedev (9)
- # clojure-greece (21)
- # clojure-italy (27)
- # clojure-losangeles (2)
- # clojure-russia (1)
- # clojure-seattle-old (2)
- # clojure-serbia (1)
- # clojure-spec (114)
- # clojure-uk (136)
- # clojured (2)
- # clojurescript (100)
- # community-development (19)
- # core-async (12)
- # cursive (7)
- # duct (1)
- # figwheel (7)
- # fulcro (96)
- # hoplon (4)
- # jobs (2)
- # lein-figwheel (28)
- # leiningen (2)
- # luminus (14)
- # lumo (3)
- # off-topic (11)
- # om-next (2)
- # pedestal (10)
- # planck (11)
- # portkey (2)
- # proton (1)
- # protorepl (19)
- # re-frame (27)
- # reagent (12)
- # shadow-cljs (82)
- # spacemacs (42)
- # specter (15)
- # sql (3)
Hi folks, we've been working away at re-frame-10x (née re-frame-trace) for quite a while and we're now ready to step out of the shadows and tell the world about it. re-frame-10x is a debugging tool for re-frame that helps you become 10x more productive working on re-frame apps. Give it a go at https://github.com/Day8/re-frame-10x and let us know how you find it. We've got more planned for it to make it even better, but we think it's incredibly useful today.
Wonderful! I’m already using re-frame-trace — looking forward to trying this out!!! Thank you!
@danielcompton I am truly impressed by the tooling that has been emerging around re-frame 🎉
I’m wondering if you could help me think through re-frame xhrio/ajax call testing… In my first couple of AJAX experiments, I used the async
cljs-http library (https://github.com/r0man/cljs-http), which was great, because I finally learned how to use async channels and go blocks.
Then I learned about the
re-frame-http-fx effect handler, which I wrote new AJAX routines in — I loved the reasoning that the AJAX calls were now more declarative.
Long overdue, I’ve spend the last couple of days writing doo and cljs.test tests for those AJAX calls — I started with the
cljs-http AJAX calls first.. After some head-pounding to get async tests running, it’s been fabulous. Automated tests have made it feel safe enough to doing some refactoring. (And I loved using the dynamic vars to point the CLJS client to
localhost:3000 during testing! Another first! 🙂
It has felt incredibly worthwhile writing these tests, and even have them running inside of CircleCI now… I’ve written automated test for all the
cljs-http calls, which are used by re-frame event handlers…
But now I’m looking at all the re-frame
:xhrio effects handlers I wrote, and am wondering how to write automated tests for those — I’d like to test that given a set of AJAX inputs, I get the right set of expected outputs from my CLJ server.
- Should I turn the
:xhrio effects back into
cljs-http calls? (yuck).
- Should I call the re-frame events from cljs.test? (seems odd? not idiomatic?)
- Should I write these in
- Should I leave the
:xhrio effects in re-frame, but write duplicate
cljs-http AJAX calls? (doesn’t seem right — now two places for errors…)
I’d love some advice. Many thanks! (Here’s a snippet of cljs.test / cljs-http AJAX calls that I’m just loving…)
(As I wrote this up, it occurs to me that I’m actually testing my CLJ server, almost as much as I’m testing the CLJS/re-frame client… Not sure how that informs the right choice…)
So there's four parts to this:
1. Test that your event handlers are returning the right
effects (to trigger HTTP)
2. Test that the effects handlers work as expected (does the HTTP actually happen)
3. Test that
on-failure (event handlers) work
4. The server end
1 and 3 are pretty straight forward.
2. will be fiddly and messy to test (it is stateful), but perhaps sufficiently simple that it requires no testing. Effects handlers should be made a simple as possible.
4. Is that just testing your server-side route handlers? Is out of scope for re-frame?
If you want to do integration testsing of all 4, then
re-frame-test maybe of interest. Actually
re-frame-test may be of interest either way.
re-frame-test offers the possibility of doing your entire integration test in clojure, and not involving clojurescript. I have no experience doing this. But it was written to allow it.
@mikethompson Thank you as always for your thoughtful comments… It helped me understand that re-frame has made #1 and #3 almost non-issues for me…
Although I’d like to write test for those eventually, I’m sufficiently sloppy and inexperienced that my BIG pain points are #2 and #4, which are indeed outside of re-frame — I break the server all the time w/small changes, and I need to validate that my transformation of server results in CLJS are correct. And because of that, I think I’m going to write
cljs-http AJAX calls for each of my
xhrio calls, and use that to write tests inside of cljs.test, just to ensure correctness of all my server endpoints, and that these test running all the time.
THANKS AGAIN! (PS: congrats to you and @danielcompton and team for getting re-frame-10x out!)
@genekim I'm puzzled that #2 is a problem
re-frame-http-fx for #2 should remove the need for testing (assuming it works as advertised)
But I feel like we must thinking differently about #2. Puzzled.
@mikethompson CLJS reframe client is making an AJAX call to a CLJ server I wrote, which is making OAuth calls to Trello. Because I wrote it, it definitely needs testing. Here are some of the failures I ran into today — for your amusement: - in CLJ server, my incorrect use of require/refer for pprint caused server to no longer compile/run entirely - in CLJ server, when I deleted logging/println of Trello keys, accidentally broke something there, too :) - in CLJS, had to relearn how to unpack return values: multiple levels of text > JSON > CLJS - for circleCI, had to use dynamic vars to point AJAX calls to localhost Instead of Heroku - wrong environment vars with Trello keys can break server, too, I discovered I make a lot of errors in Category #2, sadly. And that’s just today! :) imagine me trying to get oauth working! :)
@genekim I'd probably test the server endpoints separated from re-frame. Perhaps using https://github.com/ring-clojure/ring-mock
This was almost exactly what I needed. I ended up using peridot (https://github.com/xeqi/peridot), because it could hold session state. Thanks!!!
And I totally love that it drives the testing into the Clojure server, instead of in the CLJS components. Thanks for the great advice!
@curlyfry ring-mock looks great, but a basic question? Right now, on a Mac, I have two terminal windows open during my daily work: 1) lein doo phantom test; 2) lein ring server-headless. (I used to have a 3rd to run lein figwheel to have REPL, but that now runs inside of Cursive.) It seems like now I’ll need a 3rd window for Clojure ring/unit tests… Is this how other people are running all these things?
Sometimes, I’ve also used https://github.com/kouphax/lein-cooper to start several processes in one go.
Hello all, I have an application that build an dashboard and have many datasources in it. What is the best way to fill the datasources for each element of dash using re-frame? Can I use something like
(defn fill-data  (rf/dispatch [:ds-1]) (rf/dispatch [:ds-2]) ...) ? Or is there a better way to do multiple dispatches?
@fabrao To answer your question, you might find
dispatch-n helpful (https://github.com/Day8/re-frame/blob/master/docs/API.md#dispatch-n). That said,
re-frame is built on the premise of a single
app-db. Perhaps this just semantics, or perhaps you are managing multiple stores? I am not familiar enough with the framework to offer best practices on hydrating data in the
db, so will defer to others for that...
I have simple re-frame app that uses the web speech API to speak some user-inputted text in response to a button click. Works totally as expected on Firefox and Chrome, but not at all in mobile Chrome and Safari! I suspect that the issue is due to the callback distance (not sure if that is the right term) between the button click event and the speechSynthesis.speak() invocation, but I haven't looked into it very deeply yet. Also, web speech demos using vanilla js work fine in all my browsers.
(I have no questions, I just wanted to share)