This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-10-12
Channels
- # beginners (58)
- # boot (4)
- # calva (1)
- # cider (13)
- # cljdoc (1)
- # cljs-dev (7)
- # cljsrn (14)
- # clojure (93)
- # clojure-canada (1)
- # clojure-conj (1)
- # clojure-germany (1)
- # clojure-italy (6)
- # clojure-losangeles (3)
- # clojure-nl (8)
- # clojure-spec (6)
- # clojure-uk (77)
- # clojurescript (3)
- # cursive (5)
- # data-science (6)
- # datomic (52)
- # emacs (1)
- # figwheel-main (2)
- # fulcro (6)
- # graphql (7)
- # jobs (9)
- # leiningen (1)
- # luminus (15)
- # mount (14)
- # off-topic (94)
- # pedestal (1)
- # re-frame (7)
- # reagent (10)
- # shadow-cljs (75)
- # spacemacs (4)
- # test-check (15)
- # tools-deps (23)
- # unrepl (1)
Hi guys. With the latest react-native 0.57
I've encountered a really nasty issue with the metro bundler producing invalid JS on my production optimized builds. I've reported the issue and documented a workaround here https://github.com/facebook/metro/issues/291
@vikeri I feel you, those react-native upgrades and the amount of breakage they bring with them is a real pain 😢
Another interesting thing I found out by looking at metro recently:
I guess many of you have had issues with node running out of memory when bundling (caused by babel choking to death trying to build an ast from a huge file).
Babel has a way to declare that some files should simply be ignored. So if you use something like .re-natal, you can add this to your .babelrc
{
"ignore": [
"./index.ios.js",
"./index.android.js"
]
}
This used to break the metro bundler, so you could not use it, but it has been fixed very recently through https://github.com/facebook/metro/commit/66aa795a96ec0f5b15576891447d8807d3791867
I have applied the patch locally on my node_modules, and I haven't run into memory issues since.
This solutions feels a lot cleaner than the crazy stuff I've seen in the wild (like manually triggering some node gc...). Hopefully it will be available through the next release of react-nativeGiven that you typically cache more data on the client the value of minimizing HTTP requests in om-next are less attractive. We went with re-frame and are very happy with that choice.
I'm just getting started and don't know what I'm doing, so bear with me...
I've created a new expo project with lein new expo my-project +reagent
, and have lein figwheel
running. When I run expo start
and try to open the app on my phone, I get this error:
[14:05:44] Loading Closure base.
[14:05:44] Shimming require
[14:05:46] Network request failed
- node_modules/whatwg-fetch/fetch.js:441:29 in onerror
- node_modules/event-target-shim/lib/event-target.js:172:43 in dispatchEvent
- ... 8 more stack frames from framework internals
I had the same issue and for me I needed to open up my Mac’s firewall for node
Also, if I dismiss that error screen in the Expo app, it says, "Waiting for Figwheel to load files." Perhaps that has something to do with this. 😛
Figured it out. For future reference, if you have this issue, source lan-ip.sh
resolved it for me. Step 6 here: https://github.com/seantempesta/expo-cljs-template
I must have seen the [optional] heading and skipped over it, then forgot about it. 😛
Reagent + re-frame is a lot more common, you'll find a lot of resources out there for them
I had the same issue and for me I needed to open up my Mac’s firewall for node