This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-09-01
Channels
- # admin-announcements (1)
- # aws (1)
- # beginners (14)
- # boot (19)
- # cljs-dev (10)
- # cljsrn (2)
- # clojure (64)
- # clojure-android (4)
- # clojure-dev (5)
- # clojure-greece (7)
- # clojure-italy (10)
- # clojure-russia (42)
- # clojure-spec (117)
- # clojure-uk (78)
- # clojurescript (160)
- # cloverage (1)
- # conf-proposals (1)
- # cursive (8)
- # datomic (93)
- # editors (8)
- # editors-rus (5)
- # figwheel (1)
- # flambo (14)
- # hoplon (95)
- # jobs (2)
- # jobs-rus (1)
- # lambdaisland (4)
- # lein-figwheel (6)
- # leiningen (3)
- # om (106)
- # onyx (33)
- # planck (6)
- # proton (3)
- # protorepl (2)
- # random (2)
- # re-frame (9)
- # reagent (5)
- # ring (1)
- # untangled (61)
- # yada (50)
'lo all. I'm attempting to build my untangled-client project with advanced compilation for the first time today. Any known gotchas I should watch out for?
One I worked around was:
WARNING: Use of undeclared Var clojure.walk/prewalk at line 61 resources/public/js/untangled/client/impl/om_plumbing.cljs
WARNING: Use of undeclared Var clojure.walk/prewalk at line 247 resources/public/js/untangled/client/impl/om_plumbing.cljs
We had a lot of issues with lazy sequences
If you use map to build parts of the dom, for example.
Added [clojure.walk :as walk]
to :require
at the top of of a local checkout of impl/om_plumbing.cljs
fixed that
Could be that we're using sablono to render though: https://github.com/r0man/sablono
Depends on the situation - often mapv
or into []
I highly recommend having something in your build that will check advanced compilations for you, as well
Now seeing java.lang.NoSuchMethodError: com.google.common.base.CharMatcher.javaUpperCase()Lcom/google/common/base/CharMatcher;
Yes. Especially verifying that your components can render
We have a part of our build process that goes to the devcards page and screenshots each devcard and compares against expected screenshots
Saved us a few times from pushing something bad into prod (which is generally the only place we ever actually see the site with advanced compilations)
Well, it bit us a few times first
I like the idea of devcards: I just wish there were some way of automating the testing other than the screen-shotting you're doing.
The screenshotting of the devcards thing actually was mostly about appeasing other people at the company that were mad we weren't using their UI library (built for Ember)
But it has proven to be remarkably useful.
(Our UIs will get inconsistent! If you build it not in Ember you must have tests to verify you stay in sync with the main UI library)
We also have started building some actual automated tests that click around too though
We use clj-webdriver: https://github.com/semperos/clj-webdriver/wiki/Introduction%3A-Taxi
Damnnit, @therabidbanana you're reading my mind!
Heh, I'm planning on writing a blog post about how we test our untangled app within the next week, so it's been on my mind.
I'll be sure to read it! I'm pretty happy with my server-side testing, but pretty much have nothing on the front end. I've taken a look at the untangled spec stuff, but it doesn't grab me.
We use untangled spec too - both frontend and backend. The auto refreshing unit tests for the frontend are pretty useful
@grzm: for fronted testing (not specific to Untangled at all), React鈥檚 own TestUtils should prove useful, no?
@anmonteiro I'll take a look. Thanks for the recommendation!
ShallowRenderer
can be used in non-DOM environments
others that require a DOM can be used with phantomjs or something, I believe
I was also looking at LadderLife's full-stack testing stuff. I think using that would require porting untangled-client to cljc using cellophane.
@grzm not at all
well, it depends on what you want to test
the Ladder fullstack testing stuff started without cellophane
@grzm you can start testing your client parser by just converting it to .cljc
shouldn鈥檛 need cellophane for that at all
I learn so much when I hang out here. Thanks, @anmonteiro
Looking at the property-based testing material (https://github.com/omcljs/om/wiki/Applying-Property-Based-Testing-to-User-Interfaces), would I want to remove the references to :remote in the mutate functions?
if I call (df/load-data :X) (transact! reconciler [(app/choose-tab :tab-which-reads-X-in-query)]) is this guaranteed to work? i'm seeing it seems like when my tab is loaded :X is nil because it hasn't been loaded yet
my tab has query [:X], it's initial state is {:which-tab :tab-which-reads-X-in-query :id :tab}
@jasonjckn load-data is designed to return immediately so it doesn鈥檛 block the UI
so you鈥檙e correct, that transaction immediately after the load-field can鈥檛 assume the data exists