This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-12-29
Channels
- # adventofcode (4)
- # beginners (113)
- # boot (165)
- # cider (192)
- # cljsrn (82)
- # clojure (148)
- # clojure-austin (6)
- # clojure-russia (22)
- # clojure-spec (45)
- # clojure-uk (19)
- # clojurescript (153)
- # core-async (5)
- # cursive (7)
- # datomic (2)
- # defnpodcast (2)
- # emacs (1)
- # hoplon (617)
- # instaparse (10)
- # lein-figwheel (19)
- # luminus (2)
- # off-topic (12)
- # om (3)
- # onyx (36)
- # pedestal (1)
- # protorepl (43)
- # re-frame (8)
- # ring (7)
- # specter (17)
- # testing (2)
- # untangled (117)
- # yada (12)
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
@vikeri very interesting
could you explain why patching is no longer needed?
in particular, does your pr work with boot-reload?
@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 😞
working with boot-reload is the tricky bit
well, does Hot Reload work?
we have this whole clojurescript infrastructure for making reloading simple
to my mind, that's an import advantages of clojurescript on rn
in the community we know how it works
and it's pretty snappy too
not sure if we could replace all of that with RN's JS-based reloading
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.
I don't actually use the repl (as in boot-cljs-repl)
but reloading in the running app is an important part of the package
in my experience, boot-reload is easier to get running than boot-cljs-repl
(because the latter has all the complexity of piggieback etc.)
@pesterhazy Are you using inf-clojure, not cider?
I use the REPL all the time.
Btw, I traced the 'websocket occupied' error to https://github.com/tomjakubowski/weasel/blob/master/src/clj/weasel/repl/server.clj#L16-L19
I'd love to use the repl more freuqently
@tiensonqin what's your workflow?
@vikeri If I comment these lines, the error will go. But you have to restart the repl.
Mostly cider + figwheel repl, also cursive.
I tried inf-clojure, I quite like it, but how do you use it with brn?
@tiensonqin Great work, but there are no lagging sockets then?
I've tried inf-clojure with lein, but not with boot.
@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)
@tiensonqin Sweet! Have you forked weasel?
Yeah, just installed that to local maven repo.
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.
I think that's very import too.
interesting
I'm still dig around figwheel to figure out how it deal with this problem. Right now boot-reload mostly not works for me.
great work @tiensonqin
@pesterhazy Thank you.
@tiensonqin There is an effort to port figwheel to boot-reload
so maybe that support is coming
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.
@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 😛
@vikeri I tried something like that at some point
but didn't get anywhere, ended up patching the packager
do you have a diagnosis what change in 38->39 that broke BRN?
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
people talk of a regression in the ticket
hm so the problem is this:
we call require("clojure.core")
for pathless requires (not starting with .
), the packager searches only node_modules
requiring those still works, but changing them requires a packager restart to update
correct so far?
Yep exactly, require(’./hello’)
: requiring on path, require(‘hello’)
: requiring from node_modules
so I guess we need to generate relative imports (`../path/to/hello`)
If we wan’t to go away from the current solution of flattening everything into a single folder. My PR solves that specific issue.
what do you mean by flattening?
whereas normally main. out has subfolders?
I see
sounds like a good approach then
also realm works really damn good 🙂 https://gist.github.com/dvcrn/e040c0067a7fa8adf44b174de1e837cd
@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.
@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
I saw the explanation video but still couldn't figure it out 😛 Looks like it's a toolbox of some sorts
@tiensonqin would you recommend look at exponent when I'm currently very happy with the normal re-frame+reagent+re-natal stack?