Fork me on GitHub
#cljsrn
<
2016-12-29
>
vikeri09:12:49

I think I have gotten RN 0.39 working now in boot-react-native. But please test my PR on your projects: https://github.com/mjmeintjes/boot-react-native/pull/84

pesterhazy11:12:23

@vikeri very interesting

pesterhazy11:12:39

could you explain why patching is no longer needed?

pesterhazy11:12:52

in particular, does your pr work with boot-reload?

vikeri11:12:50

@pesterhazy It won’t have to be patched since the goog.require is replaced by a normal require that RN will understand. Well ouch, haven’t tested the boot-reload. And when I think of it that will probably not work 😞

vikeri11:12:36

What are the advantages of boot-reload compared to RN’s built in Hot Reload?

pesterhazy11:12:40

working with boot-reload is the tricky bit

pesterhazy11:12:58

well, does Hot Reload work?

vikeri11:12:08

Haha, good question

vikeri11:12:29

I only used it when working on a vanilla js project, and there it worked well.

pesterhazy11:12:40

we have this whole clojurescript infrastructure for making reloading simple

pesterhazy11:12:24

to my mind, that's an import advantages of clojurescript on rn

pesterhazy11:12:39

in the community we know how it works

pesterhazy11:12:56

and it's pretty snappy too

pesterhazy12:12:32

not sure if we could replace all of that with RN's JS-based reloading

vikeri12:12:11

Alright, my experience has not been great regarding speed and it crashing if using the REPL, but I agree that it should work. That makes RN 0.39 quite a bit more trickier to get going.

pesterhazy12:12:06

I don't actually use the repl (as in boot-cljs-repl)

pesterhazy12:12:25

but reloading in the running app is an important part of the package

pesterhazy12:12:00

in my experience, boot-reload is easier to get running than boot-cljs-repl

pesterhazy12:12:15

(because the latter has all the complexity of piggieback etc.)

vikeri12:12:37

I agree, I use the REPL quite frequently though

tiensonqin12:12:01

@pesterhazy Are you using inf-clojure, not cider?

tiensonqin12:12:13

I use the REPL all the time.

pesterhazy12:12:26

I'd love to use the repl more freuqently

pesterhazy12:12:40

@tiensonqin what's your workflow?

tiensonqin12:12:53

@vikeri If I comment these lines, the error will go. But you have to restart the repl.

tiensonqin12:12:12

Mostly cider + figwheel repl, also cursive.

pesterhazy12:12:15

I tried inf-clojure, I quite like it, but how do you use it with brn?

vikeri12:12:53

@tiensonqin Great work, but there are no lagging sockets then?

tiensonqin12:12:00

I've tried inf-clojure with lein, but not with boot.

tiensonqin12:12:53

@vikeri It's still there: weasel git:(master) ✗ lsof -i :9001 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME java 3727 tienson 172u IPv6 1841189 0t0 TCP debian:9001 (LISTEN) java 3727 tienson 326u IPv6 1840411 0t0 TCP debian:9001->android-e6ef9767e0a3cdfb.lan:46538 (ESTABLISHED) java 3727 tienson 327u IPv6 1848369 0t0 TCP debian:9001->android-e6ef9767e0a3cdfb.lan:46553 (ESTABLISHED)

vikeri12:12:03

@tiensonqin Sweet! Have you forked weasel?

tiensonqin12:12:45

Yeah, just installed that to local maven repo.

tiensonqin12:12:10

Also, figwheel support websocket server keep-alive and client reconnect, I think sente does that very well too. Don't see that in boot-reload or boot-cljs-repl.

tiensonqin12:12:23

I think that's very import too.

tiensonqin12:12:57

I'm still dig around figwheel to figure out how it deal with this problem. Right now boot-reload mostly not works for me.

vikeri12:12:45

@tiensonqin There is an effort to port figwheel to boot-reload so maybe that support is coming

tiensonqin12:12:27

Yeah, hope that works. I see the commit mostly related to figwheel client. figwheel doesn't rely on weasel, I think it use it's own websocket server for both reload and repl stuff. So maybe there are more work to make cljs-boot-repl works better.

vikeri12:12:25

@pesterhazy Do you have any idea of how we could solve the RN 0.39 issue. I was thinking maybe just adding a require statement below each goog.require statement. Aware that I’m in major hack-wild-west-land now 😛

pesterhazy12:12:19

@vikeri I tried something like that at some point

pesterhazy12:12:34

but didn't get anywhere, ended up patching the packager

pesterhazy12:12:57

do you have a diagnosis what change in 38->39 that broke BRN?

vikeri12:12:34

They stopped watching the node_modules folder (which makes sense, restarting the packager when adding a new package is not too much to ask, sadly it also ruined our little hack) the RN issue is here: https://github.com/facebook/react-native/issues/11301

pesterhazy12:12:44

people talk of a regression in the ticket

pesterhazy12:12:54

hm so the problem is this:

pesterhazy12:12:11

we call require("clojure.core")

pesterhazy12:12:10

for pathless requires (not starting with .), the packager searches only node_modules

pesterhazy12:12:01

requiring those still works, but changing them requires a packager restart to update

pesterhazy12:12:21

correct so far?

vikeri13:12:55

Yep exactly, require(’./hello’): requiring on path, require(‘hello’): requiring from node_modules

pesterhazy13:12:07

so I guess we need to generate relative imports (`../path/to/hello`)

vikeri13:12:49

If we wan’t to go away from the current solution of flattening everything into a single folder. My PR solves that specific issue.

pesterhazy13:12:34

what do you mean by flattening?

vikeri13:12:28

Now the whole main.out folder tree is flattened out into node_modules

pesterhazy13:12:03

whereas normally main. out has subfolders?

vikeri13:12:33

Yes, it still has (check the build folder)

pesterhazy13:12:10

sounds like a good approach then

dvcrn13:12:39

@vikeri hey! You mentioned yesterday that you are using AsyncStorage with cljs, right?

dvcrn13:12:07

are you using the await version or how did you do it in cljs

dvcrn13:12:03

you're just passing the cb?

dvcrn13:12:07

why not core.async? 😛

vikeri13:12:43

@dvcrn We’re using re-frame so I’ll just send in a #(dispatch [:storage/get %]) callback instead. So, I’m sort of using it but under the hood.

dvcrn13:12:32

didn't think about re-frame

tiensonqin14:12:05

@dvcrn Hi, I've also used realm on lymchat, it works pretty well, especially the synchornous api helps! https://github.com/tiensonqin/lymchat/blob/master/src/lymchat/realm.cljs Later I ported lymchat to exponent, then I switch realm to async storage, turns out it works fine, but async do have some troubles, since you don't know exactly when something happens. https://github.com/tiensonqin/lymchat-exp/blob/sdk10/src/lymchat/storage.cljs

dvcrn14:12:54

I read about exponent but couldn't quite get what it's for

dvcrn14:12:16

I saw the explanation video but still couldn't figure it out 😛 Looks like it's a toolbox of some sorts

dvcrn14:12:09

@tiensonqin would you recommend look at exponent when I'm currently very happy with the normal re-frame+reagent+re-natal stack?

nikki20:12:48

@dvcrn: exponent is sort of an out of the box set of tools, yup, to make it so you just simply have to write JS (in this case cljs) to make cool phone app things

nikki20:12:00

provides a dev env and out if the box APIs etc

nikki20:12:28

the description could maybe improved :thinking_face: any suggestions?