Fork me on GitHub
#clojurescript
<
2016-06-24
>
urbanslug10:06:35

Hey shouldn’t this work? :on-invalid (fn [_] (.log js/console "triggered"))

dnolen10:06:51

@urbanslug: is that a Reagent snippet?

urbanslug10:06:05

Using om now

urbanslug10:06:14

It did what I expected

urbanslug10:06:36

It did print with :on-invalid :on-invalid

urbanslug10:06:04

:on-invalid (.log js/console "triggered")

urbanslug10:06:12

but :on-invalid (js/setCustomValidity "Only lowercase characters and underscores allowed.”) failed

dnolen10:06:16

that’s not going to work, also the question is better directed to the #C06DT2YSY channel

urbanslug10:06:30

What I really wanted is to setCustomValidity

urbanslug10:06:34

Okay moving to Om

lwhorton13:06:35

oh geesh, what a sneaky thing to debug… {(random-uuid) :foo (random-uuid) :bar}

lwhorton13:06:34

it appears uuids cannot be used as keys in a map

dnolen13:06:37

@lwhorton: you need to be using a version of ClojureScript where that issue is fixed

dnolen13:06:18

@lwhorton: oh … what do you mean?

dnolen13:06:37

(I misread uuids as vars which was a issue until recently)

lwhorton13:06:32

what i’m trying to say (and maybe this is intended behavior) is it doesnt seem like you can create a map with uuids… {(random-uuid) :foo (random-uuid) :bar (random-uuid) :baz} will always be => {:# uuid 1234-… :baz}

dnolen13:06:01

@lwhorton: what you’re saying doesn’t make sense

dnolen13:06:16

you're saying you can’t but then show that you can?

lwhorton13:06:45

in my head the expected output would be {#someuuid :foo #someuuid :bar #someuuid :baz}

dnolen13:06:17

@lwhorton: hrm? that’s exactly what’s happening

lwhorton13:06:38

in the first case invoking 3 random-uuids to generate 3 unique keys, and then assigning each key :foo, :bar, :baz respectively. it looks like the keys are “equal” and thus the map literal accepts just the last value of {#uuid :baz} instead of all 3 key/value pairs?

dnolen13:06:22

@lwhorton: heh it would have been clearer if you had just said that 🙂 ok trying it over here

bronsa13:06:14

that map has the same key twice at read-time

bronsa13:06:26

not going to work

bronsa13:06:34

in clojure or clojurescript

lwhorton13:06:36

random-uuid must be time-based then?

bronsa13:06:00

if you (let [a (random-uuid) b (random-uuid)] {a :foo b :bar}) it will work

bronsa13:06:04

not sure what you mean by time-based

lwhorton13:06:30

why would invoking it 3 times in a row in a map literal be different than 3 times in a row in a let block?

lwhorton13:06:41

maybe I dont understand how the read-compile cycle works...

bronsa13:06:55

it has nothing to do with uuids

dnolen13:06:58

@bronsa while you’re here 🙂 I’m assuming the namespaced map literal reader support is coming soon?

bronsa13:06:14

yeah, working on it

bronsa13:06:32

should be available in the next couple of days

bronsa13:06:20

@lwhorton: a clojure expression is evaluated (I'm handwaving a bit) via (eval (read-string "the-expression"))

bronsa13:06:44

if you try to read-string "{(foo) 1 (foo) 2}" you'll get an exception

bronsa13:06:58

because the literal (foo) is appearing twice as key to that map

bronsa13:06:10

it doesn't matter that the evaluation of (foo) will produce different results

dnolen13:06:14

@bronsa huh, it’s interesting that the reader doesn’t ignore seqs for map literal key checks

bronsa13:06:41

well, how could it construct the map if it didn't?

lwhorton13:06:00

oooh.. i see.

lwhorton13:06:02

thanks @bronsa

bronsa13:06:03

also the reader has no way of knowing "this map will be evaluated" vs "I actually want to read this as a structure"

dnolen13:06:27

right, I suppose it’s tradeoff for read time duplicate key checks

bronsa13:06:02

it's not just checks, it's a problem inherent to the concept of a reader. because it has to produce a data structure, it can't behave any differently

bronsa13:06:29

unless you'd be ok with evaluating {(random-uuid) 1 (random-uuid) 2} resulting in a 1-element map

dnolen13:06:42

@bronsa right that’s what I’m saying

bronsa13:06:08

I did open a ticket about this in the clojure jira with a workaround for this that didn't build actual maps but just associative lists that the compiler would compile down to maps at runtime

bronsa13:06:15

but I don't think it's a good idea at all

bronsa13:06:24

would mean that the reader behaves differently when invoked directly vs via compilation

hlolli16:06:52

A basic http question, Im trying to make transit-post via cljs-ajax, on the backend Im using wrap-cors to allow cross origin request. But that last info is kind-a meaningless since Im getting stopped by the frontend (cljs) that Cross origin requests are only supported for protocol schemes: http, data, chrome, chrome-extension, https, chrome-extension-resource. So in general, transit post can't be used cross origin?

dnolen16:06:36

@hlolli: the error says what the issue is - nothing to do with Transit

dnolen16:06:18

@hlolli: that is unless you can show that the setting the Content-Type header for some reason causes it to fail

dnolen16:06:39

whatever the case I would minimize the variables here to sort it out

hlolli16:06:02

ok, good point, I only posted half the story, sorry

(POST "0.0.0.0:8080"
        {:params {:message "Hello World"
                  :user    "Bob"}
         :response-format :transit
         :keywords? true})
I sent this, but GET worked fine.

dnolen16:06:14

@hlolli: so minimize the variables

dnolen16:06:19

try it with plain JSON

dnolen16:06:36

also you’re using a library which may not be doing things right

dnolen16:06:47

use goog.net.XhrIo directly to remove that variable

hlolli16:06:56

yes, :json keyword returned the same, so I will do this without this library. I do use commonly used function transit-post, that appears often in om.next, but I must admit, that I dont understand what magic the reconciler is doing in :send that I would like to do manualy outside om next. So I guess I just need to wrap this in a core.async channel?

(defn transit-post [url]
  (fn [{:keys [remote]} cb]
    (.send XhrIo url
           (fn [e]
             (this-as this
               (cb (t/read (omt/reader) (.getResponseText this)))))
           "POST" (t/write (omt/writer) remote)
           #js {"Content-Type" "application/transit+json"})))
(dont want to waste too much time, need to read more on this I know)

hlolli17:06:05

ok thanks for the link, I will read more, really want and need to understand this.

dnolen17:06:30

@hlolli: there’s an #C06DT2YSY specific channel btw if you have questions about :send

hlolli17:06:11

yes, Im not using om in this specific case, and this works fine in om for me.

dnolen17:06:40

:send doesn’t do much wrt to transport, you handle all that yourself

dnolen17:06:58

it just automates and creates conventions around merging the response

hlolli17:06:31

excacly, in the autocomplete example you wrote I guess, I remember doing json and defining a channel that handled the callback. Should be no different here. Ah, nevermind, I read more and ask if Im still having problems 🙂 thanks.

dnolen20:06:42

^ means you can write clojure.{spec|pprint|test} and they are aliases for cljs.{spec|pprint|test}

adamfrey20:06:12

^My list of little quibbles with cljs keeps getting smaller and smaller these days. Thanks!

dnolen23:06:15

another big enhancement macro inference for :refer

dnolen23:06:19

this means

dnolen23:06:46

(require ‘[clojure.spec :refer [fdef]]) works

dnolen23:06:12

no need for :refer-macros we will resolve them for you

olivergeorge23:06:26

I'm not sure if this is a bug to log or expected behaviour... Building with a cljsjs package where cljs package includes :libs in deps.clj you find the out directory includes a "file:" directory. An example from my specific case: "out/file:/home/vagrant/.m2/repository/cljsjs/openlayers/3.3.0-0/openlayers-3.3.0-0.jar!/cljsjs/development/openlayers/ol/array.js" This makes the build fail on windows because ":" is not permitted in file names (based on experimentation). My feeling is that the path should have reduced to the last part, excluding the file: bit and the entire jar file path.

dnolen23:06:32

this is for the case where the macro ns & run time ns share the same name

olivergeorge23:06:50

(@dnolen that is awesome!)

dnolen23:06:11

this means for core namespaces your ns form should look really clean now between Clojure & ClojureScript

dnolen23:06:37

and you can leave reader conditionals for the messy stuff

olivergeorge23:06:38

That is seriously exciting stuff. Thanks as always for your efforts.