Fork me on GitHub
#clojurescript
<
2018-01-27
>
bja02:01:57

@ag I have, but nothing I can point you to. You essentially just ^:export and you're good. I've done react components using reagent and some other stuff that was consumed from vanilla js. @dnolen's mori is an extreme example of exporting the cljs datastructures and stdlib as a vanilla js library (https://github.com/swannodette/mori) datascript-mori is an interesting example of taking two cljs libraries and exposing them to vanilla js (https://github.com/typeetfunc/datascript-mori)

mfikes02:01:32

Coming eventually to a CloureScript REPL near you:

(empty (first {:a 1}))
will evaluate to nil rather than []. 🙂

kenrestivo02:01:52

jira ticket?

kenrestivo05:01:59

that was fast

Quest16:01:24

Has anyone found a way to preserve namespaced keywords being used as map values when using js->clj?

(defn keyname [key] (str (namespace key) "/" (name key)))

(def a (clj->js {:foo/bar :baz/zot} :keyword-fn keyname))

> (js->clj a :keywordize-keys true)
{:foo/bar "baz/zot"}

;; note: cljs version 1.9.1011 from source for :keyword-fn support
;; see 

Quest17:01:12

Due to the lossy nature of encoding as strings, I don't see a straightforward solution. My data model currently uses KV pairs like :spec :model.entities.specs/foo, which render nicely and have a 1:1 correspondence with the specs in the clj/cljs runtime. It looks more reasonable to change my model to use string values and cast to the spec keywords when needed. Every solution I've thought up is too kludgey, but let's see if anyone has ideas 🙂

p-himik17:01:24

@quest What do you need js->clj for? If it's only for sending/storing the JSON, maybe you could use transit-json instead.

Quest17:01:09

@p-himik react native passing data to/from the JS layer

(defn flat-list
  [{:keys [data render-item] :as props}]
  [flat-list-class (merge props
                          {:render-item (wrap-render-fn render-item)
                           :data (clj->js data {:keyword-fn keyname})
                           :keyExtractor (fn [_ i] i)})])

Quest17:01:18

(wrap-render-fn) does casts back from js->clj and creates the reagent elements

p-himik17:01:43

I've never used React native, so I may not know something, but couldn't the CLJS data be passed to JS and back if it's not used by JS code?

Quest17:01:25

I believe the reason it's done this way is because the virtual DOM diff'ing, handled by React, is done at the javascript level

Quest17:01:11

so after the :data FN is run, the :render-item will only be run when calls bubble back up from the JS layer

Quest17:01:02

I'm still new to this stack though. maybe one of the vets from #cljsrn could weigh in

p-himik17:01:46

Yeah, but if you'd use pure JS, you'd be able to pass any kind of object into :data, right? And CLJS objects should be no different in this regard - React would just re-render your component when :data changes.

Quest17:01:38

This is a good suggestion. I removed all ->js transformations from my flat-list FN, but found something odd

Quest17:01:40

the first time it's called, the Clojure data structure is passed in from the Clojure layer

Quest17:01:25

anytime the UI re-renders, the data argument to flat-list is suddenly #js {...}

Quest17:01:48

I'm not sure why this is. There's clearly a transformation going on automatically somewhere in the reagent layer. I'll noodle over this for a while, and thanks for the suggestion

p-himik17:01:42

Hmm. Can you try convering just the top level of data, if it makes sense? If it doesn't, maybe try wrapping data in a JS object.

Quest17:01:31

I think I get what you mean about wrapping it in the JS object -- I'll give it a shot after I run some errands. Likely that it'll either work or break everything, so should find out fast

avfonarev23:01:33

What is the best overview of om next out there? A talk/article would be appreciated