I'm new to cljs (but not to clojure) and react-native. I'm trying to use react-native-sensor-manager with re-natal and do not know how to translate the import statements here.

import React, {
  DeviceEventEmitter // will emit events that you can listen to
} from 'react-native';

import { SensorManager } from 'NativeModules';

@zakwilson - You may want to consider using Reagent (or similar, there are others), which is a Clojuric / Clojurescript wrapper around React. That way, as long as you don't stray into waters that are completely uncharted you won't need to translate such things.

After looking at Reagent, om.next, and Rum, I picked Rum. I don't think Rum will do this for me.

I'm not sure Reagent has anything for me here either. This is a library written mostly in Java that makes the sensors on an Android device available from React.

@zakwilson - OK, sorry... I need to ask someone, as I don't know myself, but there are Clojuric wrappers for ReactNative...

Thanks for the answer. I'm sure there's a simple way to do it and it's likely just a question of syntax.

Almost certainly

*scratches head*

@zakwilson - Some "people I know" use this: https://github.com/seantempesta/expo-cljs-template and the docs are here: https://docs.expo.io/versions/latest/ At first look it does appear to give access to some of the Native sensors, like the Gyroscope

It also has a codified way to "Eject" and write native code, that looks as though it's really well documented...

what predicate would I use to test to see if something supports the deref function?

is there like an IDerefable or something?

@idiomancy (satisfies? IDeref x)

oooh, didn't know about the satisfies fn!

In order to fish for this yourself, (source deref), then see -deref, then (source -deref) and you will see the protocol.

That’s a common question - it popped up some days ago too. I wonder what the pattern is that prompts it :)

Yeah, why such a recent interest in whether something can be dereffed? :thinking_face:

I sincerely doubt I am part of any kind of recent trend

Hah. Usually you statically know that deref is OK.

yeah, totally. this has to do with a silly wrapper I made a while ago

Is it perhaps to deal with promises?

lol, well, its actually just a mechanistic consideration with a library/pattern I'm working on for working with reagent+posh(datascript)

its basically defining something I call a "qpv" which is essentially a reactive var that is a composition of a datascript query, a datascript pull, and one or more view functions

it uses re-frame's frp layer caching to checkpoint at each stage

so, essentially the output of the whole thing is a function, but I wanted it to have a derefing syntax purely for the aesthetic notion that it should be treated as a value

so the testing to see if it was derefable was just so that I could start with a known set of ids in the pull stage without having to start with a query

essentially, the "pv" function takes a derefable (the output of the q step), but sometimes I just want to give it a value.

but, I should probably rework that rather than testing to see if its derefable

Run with --info or --debug option to get more log output. error: unknown option --debug'`

¯\(ツ)/¯

How do I access this in CLJS?

Or print it out

https://cljs.github.io/api/cljs.core/this-as @mario.cordova.862

can you folks recommend a CLJS idiomatic library for doing async calls in node? Kind of like cljs-http but for node

I used kvlt, since it depends on request for node: https://github.com/nervous-systems/kvlt

Looking at various articles and youtube videos I noticed there was a lot of excitement about Om Next in 2016, but it’s 2018 now and it seems things with Om next are much quiet now. Anyone have any more insight on the status of the project?

not that active, though there are some users of course, it more or less works as advertised

there are newer efforts like Fulcro that improve upon its ideas

https://github.com/fulcrologic/fulcro

haven’t had any time to use it myself, but I have noted some previous Om users are enjoying it quite a bit

Awesome! I’ll have a look. Thank you for the info @dnolen

hmm. what is '[:find ...] vs [:find ...] to the interpreter? Is there a predicate I can use to test for that? quoted or something?

i suppose the question is "is there a predicate to test to see if the form is unevaluated?"

no

to be clear there is no interpretation

just compilation

in the former the compiler will emit a vector of Clojure “inert” data, the later might not to be that simple

gotcha, okay

thanks!

can clojurescript not use "nested requires" in ztellman style? [project.protocols [x :as x] [y :as y]]

nope

and no intention to support either

👍

happy for that limitation, as well as banning :refer :all. keeping code readable and stuff

yes

not really a fan of all the flexibility in Clojure’s ns

Rich intentionally revisited and restricted

we recovered most of the usability over time but we left out the extravagances - which have really shown to be low in value in projects / libraries

for sure agree on refer (definitely :all). Not sure the nested thing hurts readability in my opinion. but i like when a decision is made and no ambiguity about it 🙂

Hi! can I do something like:

I can't change the checkbox in the browser ;-(

and I don't get any message in the console