Fork me on GitHub

is it possible in the return of reg-event-fx to :dispatch to multiple events without registering other co-fx?


it seems you can only dispatch to one further event


use :dispatch-n like this {:dispatch-n (list [:first 1] [:second])}


Hi, I was wondering how many people here use the tracer debugging approach It seems powerful, but it's kind of hard to see the benefits as there is no example output in that doc (maybe even a gif would be appropriate here to illustrate how the values are printed and which can be expanded etc). I'm also wondering whether the tracer approach makes using the debug middleware redundant considering tracing already prints return values.


I'm using tracer in my current project, they basically print out the args+return of all your events/subs/views. if you use devtools, each event/sub/view is one line and you can expand it to see the values. (like a running stack trace)


The tracer itself is enough if you write pure functions IMO.


@akiroz Sweet, thanks a lot! Would you mind showing what one of the expanded prints looks like?


The text is a bit hard to see because of the dark theme I'm using


@mikethompson I'm trying to do a subscription that will returns a Boolean, but it seams that the only supported return values are sequential, map or refs. Due to the implementation of deref-input-signals. Is there a reason for not supporting for example Boolean?


@skjutare Although I haven't tried returning a boolean, I have no problems returning a string or nil in my current project.... let me try a boolean now...


@skjutare booleans seems to be working for me too, I'm on [re-frame "0.8.0"]


@akiroz Im on the same version, will try to restart figwheel repl.


@akiroz After a figwheel restart and browser reset it works... Thanks


@mikethompson thanks a lot! Do I understand correctly that in general the approach is still viable to "prune" computation of more "heavy" subscriptions? It can even be the case that "select-keys"-like subscription can be generally useful (and included in re-frame itself). Again, if I understand correctly, the point of such "trivial" subscriptions is to minimize an overhead of frequently changing keys, e.g. when you have both "heavy" parts of your app-db (e.g. datascript storage) and "light" ones (e.g. current value of some input that is swapped on every change)


noob question here: started a new project with reframe template , however there is not a single reference to a reagent/atom in the default template code, is there a new subscription mechanisim or am I just supposed to create my own instance


With re-frame you don’t need the atom


It’s a core component they just discuss it in the docs so as a user you can fit it inot your mental model. Functionally it is re-frame.db/app-db


right thanks


so does

would set the “db” ratom thats used in subscriptions ?


@re-frame.db/my-db will dereference the atom at that point in time exposing the DB. If you wire up re-frame correctly you’ll only ever access via figwheel repl to debug the structure of the db.


Otherwise you shouldn’t ever really reference it directly.


@gregnwosu btw I wrote a blog post in September on getting started w/ reagent and re-frame.


@nfisher , thats awesome will read, im up an running now , but I’m sure theres loads that i can glean from your blogpost


@gregnwosu: I've been using for the last week or so, it's fantastic if you want to see what's happening in your app-db. For getting started info, there's also which was released recently and is a nice quick intro (subscription has a cost to it but there is a free trial)


@colindresj I know it is under active use elsewhere. The docs are certainly lacking, but it is totally functional .


As I understand it, no further development (other than docs) is required


But @sam.roberton can probably answer better than I ^^^


Awesome, do you have any recommended best practices for testing some of the newer stuff like effects, coeffects, etc.?


@colindresj: @mikethompson is spot on. I haven't yet written the docs that I've promised him multiple times, but my team's using re-frame-test to test our client-side code -- we're looking to migrate a heap of flaky Selenium tests with something simpler and more deterministic -- and so far it's working well for us. Let me promise -- again -- to write some documentation as soon as I can carve out some time. In the meantime, I'm happy to help out answering questions if people have any. In the meantime, you might find this a useful example of what re-frame-test tests might look like:


We find the effectful event handlers a god-send for writing good tests. We have an :http fx handler in ClojureScript which makes an AJAX call -- and in our JVM tests, we define a different fx handler which takes the same data, and makes a direct call to our Ring handler, so it mimics the AJAX call, but in-process. That means that we get tests which are (a) faster, and (b) capable of coordinating between server-side and client-side -- either for mocking, or for running within a single DB transaction, or for coordinating timing, or whatever.


Thanks for the insight @sam.roberton @mikethompson. I’ve been looking at the repo every couple of weeks, but didn’t want to start using it until I knew it was ready — glad to know it is. So you run tests directly on the JVM, no browser stuff used at all @sam.roberton?


@colindresj: Yes, that's what we're in the process of migrating to. Our current setup is that we have a heap of Selenium tests (powered by clj-webdriver) -- but we find that they give us a lot of false negatives when tests fail due to timing issues (Selenium fails to find an element because the async render cycle hasn't yet rendered it, or because it hasn't waited quite long enough for an AJAX call to complete, etc). Also, they're slow and somewhat annoying to write. We're in the process of moving more of our codebase to re-frame (previously we were largely ad-hoc Reagent), and as we're doing that, we're looking to replace Selenium tests with re-frame-test tests which we run on the JVM to test the client-side event handlers in concert with the full server-side stack (all in a JDBC transaction that gets rolled back at the end of the test, so that tests can't interfere with one another by putting unexpected crap in the database). In some ways, we're reducing the scope of our test coverage by doing this, in that we're no longer testing the rendering of our views. But the trade-off is that (we hope) it's dramatically improving our test quality and reliability.