@joshmiller the last variant should work, are there error messages or does the function get called?

could also be, that the data object has no rows, so renderRow is never called

did anyone try upgrading or successfully made it to RN 0.46 yet? (I would strongly suggest you either wait or backup your whole project before you try)

lol

the breakage situation is pretty tough at the moment, and I think it’s not only me 🙂

RN devs are not squeamish about breaking the world

haha yea no kidding…

this time IMO they went a little overboard though… I have not tried it but even the default install following all instructions for a brand new project seems broken as reported by a lot of people

To anyone using :simple compilation and having solved memory issues, can you please check the memory usage evolution over time of the various nodeprocesses when doing a react-native run-ios --configuration Release and report here ? Can you also include your node version + exact export NODE_BINARY... line ?

@gphilipp After a certain code size, I had to use advanced to get react native releases to build without memory errors. Lately, the only setting I have to mess with is:

node_modules/react-native/packager/src/JSTransformer/index.js:

// Worker will timeout if one of the callers timeout.
const TRANSFORM_TIMEOUT_INTERVAL = 30100000;

On my laptop, event if I set node --max_old_space_size=8192, the nodeprocess NEVER goes beyond 1.5G of memory usage. That looks terribly like some default value. I would like to know if it’s the same for others.

That sounds right (from my memory at least). I wasn’t able to increase the amount of memory usage. The only luck I had was with the garbage collection hack I found (where you manually trigger gc in the transform loop to keep memory usage stable).

but that was a while ago and I don’t know if that packager code has been re-written.

I used your trick, but it didn’t have any effect (saw the GC messages in the log)

some info here: http://davidvgalbraith.com/pushing-the-performance-limits-of-node-js/

> Third, because of the problem described above, node.js puts a hard limit of 1.5 GB on its heap. If your total heap usage reaches 1.5 GB, you will see the dreaded “FATAL ERROR: JS Allocation failed – process out of memory” message. That is not a happy message. It means your application has crashed.

javascript lol: https://github.com/endel/increase-memory-limit

I’m curious whether anyone has messed with the new :npm-deps ClojureScript compiler option. I tried a little, but started to suspect that it might be at odds with the React Native packager. I didn’t want to spend too much time, so asking.

I found that :npm-deps can be made to work, but there is a lot of stuff in the re-natal stack that can start to fall apart the more you try to use that way. (For example, I was able to simply have a (:require react) in my ns form, but trying to additionally include react-native caused other issues, and if you try to run things in dev mode, you can get Figwheel to NPE.)

@mfikes A lot of RN projects are written in ES6 without being transpiled before being published to npm. Does :npm-deps handle that, i.e. will it transpile the library code?

I don’t know. António Monteiro is the main developer of :npm-deps and much more knowledgeable on that kind of stuff than I.

My hope is that one day he becomes interested in or needs to write a mobile app 🙂

Haha ok! In general I think it would be hard to incorporate :npm-deps into the rncljs toolchain without some tweaks due to how the RN packager works. (Scanning the code for require-statements for example).

@mfikes is the idea to use :npm-deps to avoid using npm separately altogether? (that would be nice)

A successful implementation of :npm-deps + an undestanding of what the RN-packager does apart from babeling the code could allow for us to cut out the rn packager and serve the files straight from figwheel. I think a lot of work would be needed for that though.

My thinking was for 2 things: 1) If you use React that way, you can subject it to Closure (DCE, etc.) 2) It might be important for the new string-based require that is in ClojureScript master, which might make using RN components more straightforward (stuff in the ns form rather than vulgar explicit js/require, and goog.object/get calls in code

1) would be very cool

@vikeri I have been using RN/packager for a long time but never dug into this - do you know what’s the point of packager doing this require-statements scanning?

@raspasov Some kind of basic tree shaking I guess.

@vikeri possible, but i’m not sure either

@vikeri FWIW, I succeeded in using react without a (js/require "react")

When doing so, you could see that ClojureScript was pasing React through Closure (because Closure started warning about some things)

I just tried adding a random react native library through :npm-deps

ERROR: ES6_FEATURE. this language feature is only supported for ECMASCRIPT6 mode or better: modules. Use --language_in=ECMASCRIPT6 or ECMASCRIPT6_STRICT or higher to enable ES6 features. at /Users/***/node_modules/react-native-fade-in-image/index.js line 1 : 0

My very earliest attempts at working with RN (back before it was released) was based on the concept of attempting to avoid the RN Pacakager (even Nolen was thinking this way), and we had Ambly compiling directly to the device. But that way leads to challenges. Either you try to stay away from the packager or you embrace it, was the philosophy I came away with.

(it’s one of the simpler RN libraries this one that I tried https://github.com/expo/react-native-fade-in-image)

@mfikes yea packager is quite a mess IMO, but it seems very hard to avoid at this moment

(from my ~1 year experience of RN full time)

The thing that essentially killed the idea (dunno if it has been addressed), was that React was using Facebook-specific import code of some sort that the Packager knew how to process

@mfikes that’s good info, unfortunately I don’t know

Right, that sounds familiar, haste I think it’s caleed