This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-07-22
Channels
- # aws (1)
- # bangalore-clj (3)
- # beginners (103)
- # boot (15)
- # cider (29)
- # cljs-dev (17)
- # cljsrn (43)
- # clojure (156)
- # clojure-gamedev (2)
- # clojure-italy (11)
- # clojure-spec (55)
- # clojure-uk (4)
- # clojurescript (76)
- # data-science (2)
- # datomic (7)
- # defnpodcast (2)
- # emacs (4)
- # leiningen (2)
- # luminus (3)
- # off-topic (11)
- # parinfer (3)
- # pedestal (1)
- # quil (1)
- # re-frame (3)
- # reagent (2)
- # ring-swagger (1)
- # timbre (3)
- # unrepl (10)
- # untangled (1)
- # vim (3)
- # yada (1)
I’ve started working on improved coverage of React Native externs. From a few hundred lines to over 12,000 https://github.com/mfikes/react-native-externs/commit/a46b7c34a4e11fb8f197b75884ed084a1b4cb686 I suppose ultimately if this gets mature, it can be submitted to cljsjs
@mfikes you might want to check this project: https://github.com/dmotz/natal-shell He does something similar althuogh I think he crawls the online website for components definitions. Not entirely sure though. Hope it helps 🙂
does this work with callback functions?
For example the callback you register wiht addEventListener about halfway through this page: https://facebook.github.io/react-native/releases/next/docs/linking.html
componentDidMount() {
Linking.addEventListener('url', this._handleOpenURL);
},
componentWillUnmount() {
Linking.removeEventListener('url', this._handleOpenURL);
},
_handleOpenURL(event) {
console.log(event.url);
}
you'd still need gobj/get
in a cljs version of handlOpenURL right?
@pesterhazy I’m assuming it would be fine in that whatever you name your handler function is an arbitrary name, and mangling it would not matter as RN only sees the event handler object (it doesn’t call your function by name). I could be wrong, though, because I haven’t been successful in registering AppState callbacks, so, I can’t test. I suppose if you pass a function to React Native such that it will call it by name (which would seem to require passing a string to it), then ^:export
would be appropriate when defining the function.
Ah sorry I wasn't clear.. I meant the (.-url m)
attribute access you'd need to use in the callback @mfikes
I think RN will call the function by reference, so the fn name should be fine
Exactly
In that case, I wonder if you can consider the callback value as “data”. Therefore gobj/get
is appropriate.
Interesting...
I’ve been doing this for the data that is passed to animation completion callbacks. It essentially passes you #js {:finished true}
I didn't realize that data vs code was the criterion
@pesterhazy I think it is an artificial distinction, that I’m starting to appreciate. See https://twitter.com/mfikes/status/882585745424338944
I still think that :js-keys
(as opposed to :keys [...]) destructuring would be very useful in such a case
I wonder if :js-keys
has been seriously discussed. Something like
(extend-type object
ILookup
(-lookup [o k]
(goog.object/get o (name k))))
Makes “normal” destructuring on JavaScript objects work, as well as get
, get-in
, etc., but there’s probably some ill consequences of doing something like that. But :js-keys
could be used specifically when you want it, without messing with ILookup
for objects.I suppose :js-keys
is limited in that there is no way to slip it into constructs like (let [{a :a} #js {:a 3}] a)
Hrm. Maybe ILookup
on object
is not so bad: https://stackoverflow.com/a/16904181/4284484
Interesting, I didn't know that extending ILookup was so simple. I can't tell if this would have ramifications anywhere else though
I did bring up js-keys
some time ago and there didn't seem to be interest in adding it, but maybe a more more formal proposal would be considered
Good point about not being able to rename keys
Would this be possible (let [#js {foo-bar :fooBar} #js {:fooBar 1234}])
?
this would use gobj/get internally
Same with (let [#js [head & tail] #js [1 2 3]])
which could use array functions
Interestingly, extending ILookup
to object
causes object destructuring to work via the last-ditch native-satisfies? ILookup
branch of get, and there are no other native-satisfies? ILookup
branches anywhere else in the ClojureScript codebase. (Which argues that it might be fairly safe to do.)
Perhaps a cheaper (non-recursive) alternative to outright js->clj
is something like
(defn destr [o]
(reduce (fn [acc k]
(->> acc
(cons (goog.object/get o k))
(cons (keyword k))))
()
(js-keys o)))
as in
(let [{:keys [a b]} (destr #js {:a 1 :b 2})]
[a b])
Destructuring on arrays already works, but perhaps in your tail
example, you’d like tail
to be an array instead of a sequence.
shallow js->clj is a really good idea
true that it works on arrays already
didn't realize that
Thanks for the link, that's very useful
Although it feels somewhat arbitrary given that js doesn't make such a distinction
Right. I’d like to try an experiment and see what Closure does in this case. If it renames the keys then using externs would be good in case in the future we ever figure out how to pass React Native through Closure and want to eliminate the mechanisms we have to prevent mangling without actually changing code.
I'll add externs to cover objects passed to callbacks; I'm sure this is the right thing to do (in order words, not treat the objects as data—they will be subjected to mangling unless truly constructed using strings)
out of curiosity, how do you specify externs in that case?
Is there an "object" to attach them to?
I think the var name in the file would be arbitrary—perhaps long and unique and meaningful to humans
aha, so the attribute names are actually global?
I.e. if I define React.renderComponent
as an extern, myObject.renderComponent
will also be guarded against minification?