Fork me on GitHub
#untangled
<
2016-09-01
>
grzm17:09:25

'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?

grzm17:09:04

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

therabidbanana17:09:15

We had a lot of issues with lazy sequences

therabidbanana17:09:33

If you use map to build parts of the dom, for example.

grzm17:09:07

Added [clojure.walk :as walk] to :require at the top of of a local checkout of impl/om_plumbing.cljs fixed that

therabidbanana17:09:15

Could be that we're using sablono to render though: https://github.com/r0man/sablono

grzm17:09:30

therabidbanana : worked around with that with doall ?

therabidbanana17:09:51

Depends on the situation - often mapv or into []

therabidbanana17:09:45

I highly recommend having something in your build that will check advanced compilations for you, as well

grzm17:09:56

Now seeing java.lang.NoSuchMethodError: com.google.common.base.CharMatcher.javaUpperCase()Lcom/google/common/base/CharMatcher;

grzm17:09:14

You mean running tests against the advanced build?

therabidbanana17:09:40

Yes. Especially verifying that your components can render

grzm17:09:55

What are you using for that?

therabidbanana17:09:01

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

grzm17:09:59

Looks like that error might be due to guava

therabidbanana17:09:03

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)

grzm17:09:24

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

therabidbanana17:09:34

Well, it bit us a few times first

grzm17:09:35

With the testing, and all

grzm17:09:49

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.

therabidbanana17:09:50

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)

therabidbanana17:09:10

But it has proven to be remarkably useful.

grzm17:09:45

Hey, it solved your problem.

therabidbanana17:09:58

(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)

therabidbanana17:09:51

We also have started building some actual automated tests that click around too though

grzm17:09:06

What tools are you using for that?

grzm17:09:21

Damnnit, @therabidbanana you're reading my mind!

therabidbanana17:09:02

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.

grzm17:09:11

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.

therabidbanana17:09:46

We use untangled spec too - both frontend and backend. The auto refreshing unit tests for the frontend are pretty useful

grzm17:09:44

Glad to hear it's working for you 馃檪

grzm18:09:21

ZOMG! It compiled!

grzm18:09:57

169K gzipped

anmonteiro18:09:03

@grzm: for fronted testing (not specific to Untangled at all), React鈥檚 own TestUtils should prove useful, no?

grzm18:09:31

@anmonteiro I'll take a look. Thanks for the recommendation!

anmonteiro18:09:02

ShallowRenderer can be used in non-DOM environments

anmonteiro18:09:27

others that require a DOM can be used with phantomjs or something, I believe

grzm18:09:35

I was also looking at LadderLife's full-stack testing stuff. I think using that would require porting untangled-client to cljc using cellophane.

grzm18:09:33

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

grzm18:09:59

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

anmonteiro18:09:04

well, it depends on what you want to test

anmonteiro18:09:15

the Ladder fullstack testing stuff started without cellophane

anmonteiro18:09:24

@grzm you can start testing your client parser by just converting it to .cljc

anmonteiro18:09:31

shouldn鈥檛 need cellophane for that at all

grzm18:09:56

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

grzm18:09:08

it's definitely not slacking at all

grzm18:09:28

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?

grzm18:09:31

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

jasonjckn21:09:10

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

jasonjckn21:09:59

my tab has query [:X], it's initial state is {:which-tab :tab-which-reads-X-in-query :id :tab}

ethangracer22:09:24

@jasonjckn load-data is designed to return immediately so it doesn鈥檛 block the UI

ethangracer22:09:41

so you鈥檙e correct, that transaction immediately after the load-field can鈥檛 assume the data exists

jasonjckn23:09:10

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