Skip to content
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

Merged
merged 5 commits into from
Jul 21, 2016

Conversation

danielcompton
Copy link
Contributor

Note that the goal of using CLJC here is to enable writing and running
deftests 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.

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)))
Copy link
Contributor Author

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?

Copy link
Contributor

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.

Copy link
Contributor

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.

@danielcompton
Copy link
Contributor Author

danielcompton commented Jul 21, 2016

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 test to the circle.yml so that they get tested in CI, which should help prevent regressions.

@samroberton samroberton merged commit a169e1b into day8:develop Jul 21, 2016
[lein-shell "0.5.0"]]}}
:dev {:dependencies [[karma-reporter "0.3.0"]
[binaryage/devtools "0.7.2"]
[org.clojure/tools.logging "0.3.1"]]
Copy link
Contributor

@stumitchell stumitchell Jul 22, 2016

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants