Clojurians Log v2

https://github.com/vouch-opensource/krell/issues/98

Pretty sure there are other similar issues to come.

@raspasov just set the :connect-url

@olivergeorge thanks for looking into will take a look later today

@dnolen this might justify bumping tcp socket too. https://github.com/Rapsssito/react-native-tcp-socket/issues/54

Hi guys what is the best practice when it comes to saving user input and saving it? e.g. a person writing a todo in the app storage and persisting it?

Good question. I’m interested to see what answers you get. SQLite and AsyncStorage are good conservative options.

@bhauman I tried that, it doesn’t seem to get used in the generated index.js, it defaults to “localhost”; I have figwheel-main.edn like:

{:ring-server-options {:port 9500 :host "192.168.1.62"}}

^{:react-native :cli} 
{:main rf.shared.main}

import {npmDeps} from "./target/public/cljs-out/ios_rn/npm_deps.js";
import {assets} from "./target/public/cljs-out/ios/krell_assets.js";
import {krellNpmDeps} from "./target/public/cljs-out/ios/krell_npm_deps.js";
var options = {optionsUrl: "<http://localhost:9500/cljs-out/ios/cljsc_opts.json>",
               autoRefresh: true};
var figBridge = require("./target/public/cljs-out/ios_rn/figwheel-bridge.js");
figBridge.shimRequire({...assets, ...krellNpmDeps, ...npmDeps});
import {AppRegistry} from 'react-native';
import {name as appName} from './app.json';
AppRegistry.registerComponent(appName,
                              () =&gt; figBridge.createBridgeComponent(options));

{"figwheel.repl.connect_url":"ws:\/\/localhost:9500\/figwheel-connect?fwprocess=93622e&fwbuild=ios"}

no the :connect-url set that

in your cljs.edn

@raspasov ^

ah, the ios.cljs.edn ?

Thanks for looking into this, I feel like I’m missing something obvious 🙂

<ws://192.168.1.62:9500/figwheel-connect>

:connect-url

^{:react-native :cli
  :connect-url "<ws://192.168.1.62:9500/figwheel-connect>"}
{:main rf.shared.main}

yeah that should work

Like that? I believe I tried that, but I’ll try again

yeah

also make sure that the compile is completing

It is…

If I manually change the “localhost” to local ip in the generated output it all works

actually it should pick up the :host option

do me a favor and set :clean-ouputs true

Yea, it’s strange, it doesn’t pick it up with this either:

no problem, trying

ios.cljs.edn

^{:react-native :cli
  :connect-url "<ws://192.168.1.62:9500/figwheel-connect>"
  :clean-ouputs true}
{:main rf.shared.main}

Like that?

yep

^{:react-native :cli
  :connect-url "<ws://192.168.1.62:9500/figwheel-connect>"
  :clean-outputs true}
{:main rf.shared.main}

(corrected spelling)

that way it deletes everything

and recompiles from scratch

kk 1 sec

wait are you on the latest version?

0.2.10?

Yes, 0.2.10

and the index.js still has the wrong address in it?

(I’ve been using the figwheel https://github.com/bhauman/react-native-figwheel-bridge so just trying to migrate)

yes, localhost 😞

well that’s weird going to check it now

It’s not the biggest of issues; something weird with how the config get read… I tried looking through the source code but couldn’t quite make sense of it all

source code of how the index.js gets written

If I just stick to “localhost” everywhere and open the simulator on the local computer it all loads

So everything is working, it seems like a simple config issue….

(Same if I change to the IP manually and reload on the device - it works)

I have to change it in two locations: index.js target/public/cljs-out/ios/cljsc_opts.json

Change the

{"figwheel.repl.connect_url":"ws:\/\/localhost:9500\/figwheel-connect?fwprocess=34417a&fwbuild=ios"}

yeah do you have a figwheel.edn?

figwheel-main.edn ?

{:ring-server-options {:port 9500 :host "192.168.1.62"}
 }

yeah

That’s it

And the ios.cljs.edn currently is:

^{:react-native :cli
  :connect-url "<ws://192.168.1.62:9500/figwheel-connect>"
  :clean-outputs true}
{:main rf.shared.main}

I tried different options, deleting the figwheel-main.edn; putting all the config in ios.cljs.edn - it changes the IP when it says: [Figwheel] Starting Server at http://192.168.1.62:9500 But in the react-native generated files, keeps defaulting to “localhost”

cool I’m looking at it now

If I delete all the IP-related config, it all goes to localhost and it works on the simulator on the laptop

OK I’m getting the same behavior

maybe I lost a commit

found the bug

it was a refactor bug

sorry about that

No worries, thanks so much for looking into it so fast 🙂

should have just taken your work for it

No problem, glad we could re-produce

@luca.cambiaghi for non-encrypted storage AsyncStorage works well; for encrypted stuff I’ve used https://github.com/oblador/react-native-keychain and that’s a nice to use library also

Not sure about the limitation of storing huge blobs of todo in keychain; perhaps AsyncStorage is the way to go; another Clojure-style option would be writing to DataScript and serializing it to disk

0.2.11-SNAPSHOT is pushed with the change, it supports :host and connect-url , use host when you want to set the server’s listening ip, use :connect-url when you are connecting to a different address than your local one

it will be deployed after the tests run

Thank you! 🙂

Just tried it, seems to work! 🙂 IPs are set correctly in index.js and cljsc_opts.json based on

{:ring-server-options {:port 9500 :host "192.168.1.62"}}

DataScript + serializing is nice but if you have lots of data it can be slow and cause UX issues.

@olivergeorge What size data have you gotten to where it’s slow?

It was a while back and we've moved on from that approach. SQLite is less convenient but it means we're not holding lots of memory or trying to serialize/deserialize large amounts of data. The SQLite DB we package with the app is 1.8M.

The reference data was every site, building, room and floor of a university we work with.

When someone works out how to put datascript in front of SQLite I'll be very interested.

Gotcha. I’m in the 100s of KB without running into issues, so nowhere close.

I should test it to see where it starts becoming an issue.

Yep, remember you probably test on fast devices & simulators too

Yeah, good point.

We put some logging on the re-frame handlers doing the work.