This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # beginners (14)
- # boot (108)
- # carry (6)
- # cider (28)
- # cljs-dev (107)
- # cljsrn (32)
- # clojars (4)
- # clojure (62)
- # clojure-austin (15)
- # clojure-berlin (1)
- # clojure-brasil (3)
- # clojure-chicago (1)
- # clojure-dev (9)
- # clojure-greece (2)
- # clojure-italy (4)
- # clojure-nl (1)
- # clojure-poland (2)
- # clojure-portugal (1)
- # clojure-russia (24)
- # clojure-spec (63)
- # clojure-uk (30)
- # clojurescript (123)
- # cursive (13)
- # data-science (1)
- # datascript (1)
- # datomic (27)
- # devcards (11)
- # dirac (1)
- # emacs (5)
- # events (4)
- # hoplon (27)
- # jobs (3)
- # juxt (3)
- # leiningen (11)
- # off-topic (18)
- # om (46)
- # om-next (7)
- # onyx (50)
- # pedestal (6)
- # portland-or (8)
- # proton (16)
- # re-frame (38)
- # reagent (21)
- # ring-swagger (14)
- # specter (46)
- # untangled (116)
- # vim (46)
- # yada (22)
is it possible in the return of
:dispatch to multiple events without registering other co-fx?
Hi, I was wondering how many people here use the tracer debugging approach https://github.com/Day8/re-frame/blob/master/docs/Debugging.md
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 https://github.com/Day8/re-frame/blob/master/docs/Debugging-Event-Handlers.md 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)
@akiroz Sweet, thanks a lot! Would you mind showing what one of the expanded prints looks like?
@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...
@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
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/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.
@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 https://github.com/flexsurfer/re-frisk 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 https://lambdaisland.com/episodes/re-frame 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 .
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: https://github.com/samroberton/re-frame/blob/de0ae5e58bf7c662c2a8b969de1c516a1715158e/examples/todomvc/test/todomvc/core_test.cljc
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.