-
-
Notifications
You must be signed in to change notification settings - Fork 716
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
First pass at converting to CLJC for JVM testing #183
Conversation
Note that the goal of using CLJC here is to enable writing and running `deftest`s in JVM Clojure to test your (CLJS) re-frame app. Actually running a re-frame app as a meaningful thing on the JVM (other than for tests) is explicitly *not* a goal. - All files renamed *.cljs -> *.cljc - New `re-frame.interop` ns for stuff that's different between CLJS and JVM Clojure, including Reagent interop. - Other CLJS incompatibilities (eg `catch :default` and `deftype`'s `^:mutable` vs `^:volatile-mutable`) are handled with reader conditionals in-place.
(ns re-frame.interop) | ||
|
||
(defn next-tick [f] | ||
(.start (Thread. f))) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should use a thread pool here, or just call f
directly?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't like the idea of calling f
directly because it would mean that in your tests you would see synchronous behaviour that in the real-world would be synchronous. I think that makes tests a bit less likely to find bugs. Probably the best thing would be just to use future
-- the only reason I didn't was I couldn't be bothered double-checking at the time whether it's semantics for exceptions thrown by f
are sensible for this use-case. Let me double-check that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, future
is not the right answer (but nor is (.start (Thread. f))
.
Given that the purpose of this function is for re-frame.router/event-queue
to manage the dispatch of events, and given that CLJS is single-threaded, it would be kind of silly to have the tests multi-threading the processing of dispatched events. I'll change this to use a single-thread executor.
This looks pretty good to me, pending tools.logging being added. I think it probably makes sense to bring in the minimal implementation at this point, rather than trying to replicate Reagent entirely on the JVM, and as more features are needed, they can be added. Probably the only other thing that would be good to have is some simple tests in Clojure which exercise the CLJ implementation, and would provide guidance for others on how to run tests in CLJ. You can also add |
[lein-shell "0.5.0"]]}} | ||
:dev {:dependencies [[karma-reporter "0.3.0"] | ||
[binaryage/devtools "0.7.2"] | ||
[org.clojure/tools.logging "0.3.1"]] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I moved this out of dev dependencies in the develop branch, as needs to be pulled in in consuming projects
Note that the goal of using CLJC here is to enable writing and running
deftest
s in JVM Clojure to test your (CLJS) re-frame app. Actuallyrunning a re-frame app as a meaningful thing on the JVM (other than for
tests) is explicitly not a goal.
re-frame.interop
ns for stuff that's different between CLJS andJVM Clojure, including Reagent interop.
catch :default
anddeftype
's^:mutable
vs^:volatile-mutable
) are handled with readerconditionals in-place.