Fork me on GitHub
#clojurescript
<
2018-10-18
>
isaac04:10:38

:entries should include all the packages that I required? @dnolen

Logan Powell15:10:55

đź‘‹ Hi everyone, does anyone else have experience creating tests for functions that use core.async? I've asked this on core.async channel and was recommended to ask here.

pat12:10:14

Your let block does not return anything meaningful and you are passing done as a 3rd param to the assert

pat12:10:31

you want to call done after your asserts have all run. each assert side-effects global state in the test ns which is summed up when the test finishes.

pat12:10:11

use go blocks to get values asynchronously but aim to write them as-if they were synchronous (thats what go blocks are for) ie (is (= "this" (<! that-chan)) "some msg")

kstehn15:10:34

can anyone help me here?

nha15:10:10

maybe ask in #re-frame @slack1038

alza15:10:53

Hi folks, I've been trying to get data.xml to work with NodeJS, with some success but it's not fully working.. For example, with the following setup

(require 'cljs.repl.node) (cider.piggieback/cljs-repl (cljs.repl.node/repl-env) :npm-deps {"xmldom" "0.1.27"} :install-deps true)

(require '[cljs.nodejs])

(set! js/DOMParser
      (.-DOMParser (cljs.nodejs/require "xmldom")))

(set! js/XMLSerializer
      (.-XMLSerializer (cljs.nodejs/require "xmldom")))

(require '[clojure.data.xml])
The following examples appear to parse correctly (note: element with no content, or no content and attributes)
cljs.user=> (clojure.data.xml/parse-str "<foo></foo>")
#xml/element{:tag :foo}
cljs.user=> (clojure.data.xml/parse-str "<foo attr=\"bar\"></foo>")
#xml/element{:tag :foo, :attrs {:attr "bar"}}
However the following example gives an error (note: element with content)
cljs.user=> (clojure.data.xml/parse-str "<foo>bar</foo>")

repl:13
throw e__6464__auto___7763;
^

Error: No protocol method IPrintWithWriter.-pr-writer defined for type string: bar
    at Object.cljs$core$missing_protocol [as missing_protocol] (D:\Projects\xxx\.cljs_node_repl\cljs\core.js:311:9)
    at cljs$core$_pr_writer (D:\Projects\xxx\.cljs_node_repl\cljs\core.js:2668:17)
    at cljs$core$pr_sequential_writer (D:\Projects\xxx\.cljs_node_repl\cljs\core.js:32716:142)
    at clojure.data.xml.node.Element.cljs$core$IPrintWithWriter$_pr_writer$arity$3 (D:\Projects\xxx\.cljs_node_repl\clojure\data\xml\node.js:94:32)
    at Object.cljs$core$pr_writer_impl [as pr_writer_impl] (D:\Projects\xxx\.cljs_node_repl\cljs\core.js:32897:12)
    at Object.cljs$core$pr_writer [as pr_writer] (D:\Projects\xxx\.cljs_node_repl\cljs\core.js:33018:18)
    at Object.cljs$core$pr_seq_writer [as pr_seq_writer] (D:\Projects\xxx\.cljs_node_repl\cljs\core.js:33022:11)
    at Object.cljs$core$pr_sb_with_opts [as pr_sb_with_opts] (D:\Projects\xxx\.cljs_node_repl\cljs\core.js:33087:11)
    at Object.cljs$core$pr_str_with_opts [as pr_str_with_opts] (D:\Projects\xxx\.cljs_node_repl\cljs\core.js:33101:63)
    at Function.cljs.core.pr_str.cljs$core$IFn$_invoke$arity$variadic (D:\Projects\xxx\.cljs_node_repl\cljs\core.js:33184:18)
I've been looking at the source code of data.xml, but I thought anyone with more insight might be able to understand the issue quicker than me simple_smile

Azzurite20:10:42

I was looking into that recently as well... The advantage to cljs-css-modules is that it is garden syntax, so if you already have CSS made by garden you have to basically change nothing The disadvantage is that it doesn't automatically defines variables for you. Forest has a slightly adjusted (but maybe more intuitive) syntax than garden/cljs-css-modules and it defines variables for every class/id So you do [.class-test {:style ...}] in Forest and [".class-test" {:style ...}] in cljs-css-modules and [:div {:class classTest}] in Forest and [:div {:class (:classTest style-obj)}] in cljs-css-modules

Azzurite21:10:18

both Forest and cljss create their stuff at compile-time (as they're macros) and cljs-css-modules keeps it as data, so you could theoretically compose data structures with cljs-css but not with the other two I haven't worked with either though, so I don't know if you'd even want that

jerome12:10:22

Thank you so much @UCULU82G3! This is a great summary and really helps distill things for our classical JS team.

dnolen20:10:53

@alzadude just seems like a bug

dnolen20:10:18

the impl is calling the protocol directly rather than going through a higher level helper

dnolen20:10:37

at clojure.data.xml.node.Element.cljs$core$IPrintWithWriter$_pr_writer$arity$3 (D:\Projects\dj-data-converter\.cljs_node_repl\clojure\data\xml\node.js:94:32)

dnolen20:10:39

is the clue

dnolen20:10:25

but you’re just not providing enough information to help you

dnolen20:10:34

those are NPM modules - how are they getting into your build?

alza20:10:00

@dnolen I made the xmldom NPM module available to Node by using the :npm-deps and :install-deps compiler options when I started a piggieback repl from a Clojure repl, i.e.

(require 'cljs.repl.node) (cider.piggieback/cljs-repl (cljs.repl.node/repl-env) :npm-deps {"xmldom" "0.1.27"} :install-deps true)

alza20:10:51

But I guess I could have also just made a package.json, put xmldom in there and run npm install instead (:install-deps seemed to make one for me)

dnolen20:10:57

I don’t see how that relates to the stacktrace

dnolen20:10:05

it doesn’t work because of what I said above

dnolen20:10:37

-pr-writer should not invoke -pr-writer itself

alza20:10:43

It doesn't, I was just explaining my steps in case anyone needed to reproduce the error

dnolen20:10:36

this is not going to work

alza14:10:37

Hi @dnolen just to follow this up, I've created an issue in Jira for this bug, with a proposed patch included that fixes the problem: https://dev.clojure.org/jira/browse/DXML-61

alza14:10:37
replied to a thread:this is not going to work

Hi @dnolen just to follow this up, I've created an issue in Jira for this bug, with a proposed patch included that fixes the problem: https://dev.clojure.org/jira/browse/DXML-61