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

@urbanslug: is that a Reagent snippet?

Using om now

It did what I expected

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

ah

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

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

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

What I really wanted is to setCustomValidity

Okay moving to Om

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

it appears uuids cannot be used as keys in a map

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

@lwhorton: oh … what do you mean?

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

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}

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

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

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

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

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?

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

that map has the same key twice at read-time

not going to work

in clojure or clojurescript

random-uuid must be time-based then?

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

not sure what you mean by time-based

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?

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

it has nothing to do with uuids

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

yeah, working on it

should be available in the next couple of days

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

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

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

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

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

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

oooh.. i see.

thanks @bronsa

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

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

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

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

@bronsa right that’s what I’m saying

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

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

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

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?

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

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

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

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

@hlolli: so minimize the variables

try it with plain JSON

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

use goog.net.XhrIo directly to remove that variable

http://google.github.io/closure-library/api/goog.net.CorsXmlHttpFactory.html

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"})))

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

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

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

ah k

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

it just automates and creates conventions around merging the response

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.

https://github.com/clojure/clojurescript/commit/23632baa35f86de8866dede624545bc0cdf4a2bb

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

awesome!

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

another big enhancement macro inference for :refer

https://github.com/clojure/clojurescript/commit/783001a6786f8dca4a13fdeadc995716903b07f9

this means

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

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

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.

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

(@dnolen that is awesome!)

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

and you can leave reader conditionals for the messy stuff

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