Clojurians Log v2

'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

therabidbanana : worked around with that with doall ?

Depends on the situation - often mapv or into []

Cool.

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;

You mean running tests against the advanced build?

Yes. Especially verifying that your components can render

What are you using for that?

We have a part of our build process that goes to the devcards page and screenshots each devcard and compares against expected screenshots

ah

Looks like that error might be due to guava

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)

Sounds like you've got a pretty smart team, Musa 🙂

Well, it bit us a few times first

With the testing, and all

😄

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.

Hey, it solved your problem.

(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

What tools are you using for that?

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

Glad to hear it's working for you 🙂

ZOMG! It compiled!

695K

169K gzipped

@grzm: for fronted testing (not specific to Untangled at all), React’s 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

@grzm for reference: https://facebook.github.io/react/docs/test-utils.html

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

Wouldn't the network stack stuff need to run on the JVM?

granted, that wouldn't need cellophane, just any JS-specific stuff ported to clj

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’t need cellophane for that at all

I learn so much when I hang out here. Thanks, @anmonteiro

it's definitely not slacking at all

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?

I guess this is more of a general Om question, isn't it? Switching channels

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’t block the UI

so you’re correct, that transaction immediately after the load-field can’t assume the data exists

kk

thanks ethan, just rendering nothing in nil case seemed to work quite well