Has anyone seen a cljsjs for react native?

I know of @mfikes' react-native-externs, but that's it with regard to rn packages.

everyone I know uses the react native packager at the moment

which can consume npm dependencies

the alternative would be to repackage all RN packages - a monumental effort

hopefully the latest changes to the cljs compiler will make things better soon

Does anyone use any service to track bugs with RN? In particular, I'm interested in capturing Javascript exceptions.

Crashlytics....?

@pesterhazy I use Sentry (https://sentry.io) and I think it’s pretty good. Haven’t tried anything else recently so don’t have much to compare it to!

At the moment I use their native & JS libraries to catch exceptions. This means I end up with ‘duplicated’ exceptions in Sentry, so might move away from that setup eventually.

Hey guys, I was wondering. Is re-natal the go-to cljsrn framework right now ?

I'm trying to bootstrap a project. Obviously there's a lot less people talking about it than react native with javascript.

@austinbirch thanks for the link! Do they have any explicit support for react-native?

@jdkealy yeah re-natal is definitely the most popular choice

it's a solid choice these days

@jdkealy there was a good intro talk about cljsrn at euroclojure - the video should be released within the next 2 weeks: http://2017.euroclojure.org/using-clojurescript-to-launch/

@pesterhazy https://docs.sentry.io/clients/react-native/ Looks like I need to upgrade though! The integration for React Native used to be JS-side (https://github.com/getsentry/raven-js/blob/master/docs/integrations/react-native.rst - this is what I’m currently using), but it seems like they are creating a native-side client that can also handle source mapping for JS exceptions as well. I won’t be upgrading yet though, getting source maps working using the JS client + CLJS + React Native was tricky enough…

thanks @pesterhazy

@pesterhazy I've just recently brought in react-native-firebase, which has crash reporting.

I think it uses Crashylitics.

Are any of you running into the babel timeout issue when packaging compiled JS files?

With :simple optims, my JS file ends up being ~4MB and the bundling just times out while babel is trying to parse it.

Hi! someone tried the facebook login with android? I'm not able to get the access token. I followed all the instructions of this page https://developers.facebook.com/docs/facebook-login/android/ and I'm using Linking as explained in this example. But it is not working 😞 Did someone got the same problem? thanks 🙂

This is the issue I'm talking about: https://github.com/facebook/react-native/issues/12590

@jeaye the issue is that the react-native packager tries to rewrite the code using all sorts of babel plugins

which simply takes forever but is not needed since CLJS emits ES3

you can add a .babelrc to disable all rewriting (if you are one 0.45+)

Right, we had tried using a .babelrc with {"plugins":[]} and it didn't change anything, @thheller.

That's what you were suggesting?

try {"ignore": ["*.js"]}

in the directory of your :simple output file

plugins is weird in that once its enabled it is enabled anywhere (and RN seems to enable some by default)

That's great info, thank you.

@thheller https://github.com/facebook/react-native/issues/12590#issuecomment-283389682

Does that apply here?

FWIW, even though :simple leads to less hassle with externs, :advanced results in code that loads in JavaScriptCore more quickly (for me it shaves a second off launch time on an older device)

@jeaye never tested .json files but probably?

yeah I'm seeing exactly that issue

:advanced is always worth it IMHO 🙂

TransformError: /Users/me/project/index.ios.js: Cannot read property 'tokens' of undefined

We're also looking into :advanced, @mfikes, but that's a can of worms itself.

@thheller how did you get this to work? was it on an earlier version of the packager?

https://github.com/thheller/shadow-cljs-examples/tree/master/cljs-react-native-app

works since 0.45+

I'm on 0.44.2

0.42 broke the local .babelrc, 0.45 fixed it again

We're on 0.44.0

Ok I just tried 0.45 and it's better

This works for me:

{"presets": ["react-native"], "ignore": ["index.ios.js"]}

If I ignore all .js files, it'll fail with some node modules that use import etc.

Gah, gotta give that a go.

0.45 also made the whole thing drastically slower apparently - it runs out of mem without the .babelrc

Hah. You can see how code on ClojureScript master avoids using keywords in JavaScript object literals where they would not be legal:

(.-PanResponder (js/require "react-native"))

#js {"_initializeGestureState" #object[_initializeGestureState],
     "_updateGestureStateOnMove" #object[_updateGestureStateOnMove],
     :create #object[create]}

@mfikes which keyword do you mean?

:_initializeGestureState would not be a legal keyword

because of the leading underscore?

Right. It is following the rules here https://clojure.org/reference/reader#_literals

The main benefit is working properly with things like (js-obj "foo bar" 1)

#js {"foo bar" 1} will be printed, which round-trips

@jeaye let's keep track of this issue: https://github.com/drapanjanas/re-natal/issues/127

@mfikes ah now I understand - the #js literals use string instead of keywords as keys

nice!

Yeah, it is extremely rare to need the feature, but it addresses a corner case in the way the literals were previously printed.

@pesterhazy Don't forget about Android!

You'll need "index.android.js" in there, too.

updated

When I upgrade to 0.45.0 and add that babelrc, it takes a few minutes and then I run out of memory.

really? where did you put that file

I have 16GB, so that's not quite reasonable.

My .babelrc is in the root of the project.

yeah node doesn't get that big of a heap anyway

That's where the index.android.js is generated.

This is what I'm doing: https://safepaste.org/b4fb5619#48f42f773221d9fe5fb93d4b4510378c9266b5835df315ee99d3718e38501441

can you try this?

react-native bundle --reset-cache --entry-file index.ios.js --bundle-output main.jsbundle

hm that's kind of what you're doing anyway....

so that line takes 24seconds for me

can you cat .babelrc ?

I might have a much larger app. It's still running, but it outputted some syntax errors.

ls -l index.*

I have no .bundlerc

sorry babelrc

I have an index.android.js

$ ll index.*
-rw-r--r--  1 me  staff   2.6M Jul 28 18:57 index.ios.js

https://safepaste.org/16ca1e45#9142c0d056d94de8b8cdd741bc790b0b33c717f1af1a00ad497039d661d22207

4.0MB

huh maybe that's what makes the difference

Yeah, exponential time growth relative to size.

try

node --max_old_space_size=4092 $(which react-native) bundle --reset-cache --entry-file index.ios.js --bundle-output main.jsbundle

Same syntax errors from babylon, but we'll see if/when it finished. The errors are: SyntaxError: 'import' and 'export' may appear only with 'sourceType: module' (3:0)

what? that shouldn't happen if you only ignore index.android.js

As shown here: https://safepaste.org/601d2902#a6c806f04dc1838a9c6a291a2f84de2ac5a9c0592eb11af4c82989a02c9182fb

ok if I rerun with --dev false it OOMs, with --dev true it works

Ah.

I'm guessing it's doing "whole program optimizations"

"whole memory optimizations"

Trying --dev true. Been 60s so far.

I've had a guy on this task for a week and we're still fighting it. Your help has been great progress though, thanks.

so moving from 0.44 -> 0.45 actually makes things worse - it doesn't bundle with --dev false anymore

Mk, I can try --dev false on 0.44

That wouldn't have the ignore though, I think.

so 0.44 with --dev false, using mx_old_space and the standard .babelrc works for me

node v8.2.1 if that matters

did --dev true complete?

Same here.

No, not on 0.45.

On 0.44, with all those flags, I just got Cannot read property 'tokens' of undefined

right, same for me

I need to use the stock re-natal .babelrc

That is just {"presets":["react-native"]}?

right

that should work

So, it we're back to 0.44 and no ignores, I'd expect just a timeout.

Why did it not timeout for you this time?

on 0.44 the packager doesn't timeout for me

Ah, likely because you have a smaller JS index.

right

I can try with --dev true, but I think 0.44 is just going to timeout for me and I need those ignores.

it would be good to know which steps actually fails, the transformation step or the full-program optimization step

it would be even better if the RN packager authors cared about this issue a bit more

Hell yeah it would.

The transform is what fails, when it times out.

Based on the error message: Error: TimeoutError: transforming index.android.js took longer than 301 seconds.

ah, wow I never saw that one

That's the initial issue that we have.

why doesn't it work for you with --dev true

that should do the trick in theory

Still times out.

during the transformation step?

I'll get the error again for you, so we can be certain.

that'd be great

maybe we should band together and create a cljsrn issue

To be clear, I'm on 0.44 running this: node --max_old_space_size=4092 $(which react-native) bundle --reset-cache --dev true --entry-file index.android.js --bundle-output main.jsbundle

you could try this, with RN 46: https://github.com/facebook/metro-bundler

Yeah, whatever it takes. We've spent a lot of time on this bug. Currently, the best approach looks like using :advanced with :infer-externs.

maybe you could strip out some cljs deps too, those that blow up your bundle size

Not sure of 0.46 is gonna break a lot; I know my guy looked into it for a bit and I'll need to check with him regarding where that lead.

Our deps: https://safepaste.org/7de64a75#568bf52c588bf97b3882ba51342f7b1667fe25f2a2673176cb353e74b96dd2a3

that's not too bad

Ok, with 0.44 and --dev true, I get: TimeoutError: transforming index.android.js took longer than 301 seconds.

and with 0.45?

no idea why your bundle is so much bigger

i imagine you don't have 2M of clojurescript code?

Doubt it.

Only 3639 lines across all sources.

(sorry about the big post) I’d like to refactor/rename my views to be less repetitive. I have

[view {:style (:top-level style)}
       [view {:style (:graph style)}
        [view {:style (:svg-container style)
        ... ]]]

[view.toplevel
       [view.graph
        [view.svg-container
       ... ]]]

(defn view-top-level [body] ;; i get `Unexpected Token: .` when I use a `.`
  (fn [body]
    [view {:style (:top-level style)} body]))

Looks like about 600K of cljs sources, @pesterhazy

that's def. more than what we have

0.45 with the ignores and --dev true results in an OOM.

@pesterhazy My guy has made an issue on the metro packager already, but it has no reply. https://github.com/facebook/metro-bundler/issues/23

Doesn't address the primary issue, but it was the first place we looked since the packager, when it times out, says to provide a new value for that timeout option... but then provides no way of specifying that value. Even when forking it, he's found that 30 minutes isn't long enough to finish the transformation.

So ignoring very much seemed like the best bet.

@mfm Try wrapping body like so [body].

@pesterhazy To complete the report, 0.45 without the ignores and with --dev true also just times out.

So, no ignores == timeout, ignores == OOM

@jeaye when I do

(defn view-top-level [body]
  (fn [body]
    [view {:style (:top-level style)} [body]]))

I think a simple repro repo would help

Re-natal , a bunch of deps and the resulting cljs compiler output committed to the repo

That was the developers could have a look

That way*

sorry @pesterhazy are you talking to me?

@mfm body is just a function you're passing in. Try using (fn [] and only having body come in through view-top-level.

@mfm He's talking to me.

No sorry I was still taking about the packager

@jeaye thanks!

gotcha

Let me know if that works for you; I think it should.

with this:

(defn view-top-level [body]
  (fn []
    [view {:style (:top-level style)} body]))

(defn view-top-level [body]
  (fn []
    [view {:style (:top-level style)} [body]]))

@pesterhazy Yeah, sounds like that might be needed. Hopefully we can get the :advanced build working as well.

@mfm What're you passing to view-top-level?

Whether or not you use [] around body depends on if it's a fn or a vector already.

a bunch of nested views

As functions, or [view ...]?

as [view ...]

Ok, then you don't want [body] since it's already a vector.

makes sense

i wonder why the rest of the views don’t show up

So you're using this like so: [view-top-level [view ...]]?

like

[view-top-level
 [view ...
  [view ...
 [view ..
etc

You're giving it multiple bodies.

i am. i should not?

Your view-top-level expects one param. One view.

You're giving it multiple.

So you could wrap all of those params in one view or your could change your view-top-level to accept more.

Make sense?

how would i change it to accept more? earlier i meant to ask about wrapping it in something like a do or for loop.

You could do, for example, (defn view-top-level [& body] (into [view {:style ...}] body)) and then you should be able to pass it arbitrary.

ah thanks. i have that in a different circumstance. gotcha.

This is just Clojure data, so you're just merging vectors here.

user=> (into [1 2] [3 4])
[1 2 3 4]

Similarly, with views (used keywords so the repl works):

user=> (into [:view {:style {}}] [[:view :blah] [:view :meow]])
[:view {:style {}} [:view :blah] [:view :meow]]

looks great! thanks @jeaye

Cheers.

@jeaye I have an idea

I like it so far.

We could trick the packager into ignoring our bundle

How so?

In outline, make a separate index.js with all the requires and a placeholder

Then bundle that

Finally replace the placeholder with the actual cljs compiler output

Ok, I think I follow so far.

Also, in making the test repo, I've copied my existing project, removed all the business sources, and left only the deps. If I remove all package.json deps, I can bundle with --dev false in 2.5 minutes.

That's with like 300 bytes of cljs sources and only the lein deps.

Adding each dep back in, to see what it does to the build. react + rn give another 30s, which is fine. Something in there must be adding minutes/hours.

@pesterhazy What would need to be in the separate index.js to get the bundle to work? Just all of the requires which are otherwise in all of the sources?

Basically immediately invoked function with an argument called require

Which is a function that takes a module name and looks it up in a map

This can be generated from . re-natal

I'm terse because I'm on my phone btw

Edited ^^

This should be foolproof, i.e. even the RN packager can't screw this up

And similar to how re-natal sets up figwheel

@jeaye good idea to incrementally add code

I'm surprised that it's actually in the code, not in the deps

What pushes it over the edge?

I'm checking the deps right now, not the code.

Ok, I have all of our deps now, but only a single source file, and I can package in 2.5 minutes all the same... derp, I'm not requiring any of them.

Maybe the compiler leaves them out if not required

Yep. Thanks for your patience. 🙂

Are you privy to the details of how re-natal can generate this mock index?

Looks like it's nothing re-natal exposes, but may be in its source.

Hrm. I’m trying to use RCT_EXPORT_MODULE(); per the CalendarManager example at https://facebook.github.io/react-native/docs/native-modules-ios.html and when I look at NativeModules property, it is empty.

(.-NativeModules (js/require "react-native"))

Is everything else empty as well, or just that?

Just that property

I’ve also stopped the debugger in the RCT_EXPORT_MODULE(); macro and I can see that it is registering properly

you could try this: https://github.com/frostney/react-native-create-library

@jeaye your .re-natal should have a module section with all additional modules

Correct.

I’m actually attempting to consume an existing (purely native) component: https://github.com/chirag04/react-native-in-app-utils

@jeaye https://github.com/drapanjanas/re-natal/blob/master/re-natal.coffee#L651

I’m going to repro the CalendarManager failure with a fresh re-natal init ... project

I’m suspicious the React Native packager might be doing something to make it work for regular projects

@pesterhazy That's almost exactly what I've written for this test repo.

'cept I was doing it in cljs.

(function (require){
	// PLACEHOLDER
})(function (name) {
	var modules={'react-native': require('react-native'), 'react': require('react')};modules['./images/cljs.png']=require('./images/cljs.png');
	if (modules[name]){
		return modules[name];
	}
	else {
		console.error("Not found:", name);
	}
});

the output should be something like this

then // PLACEHOLDER would be replaced by the actual cljs bundle, after through the rn packager

So, here's the crazy thing: https://safepaste.org/9e9bda68#911d52bb42bb7a1bc6a28afa5889f86c2f962a7bba736dec6b14d021a34eb9aa

That bundles in 2.5m just the same.

Using this: https://safepaste.org/0991626b#d43014d2500df3219ae1b627b1fa8b2e69a7e416495a9109c04456b0ccd90539

Could it really be the 600K of cljs that does this?

so weird

It is trivial to repro the inability to use a native code module with a fresh re-natal project. I threw a copy of a repro repo up at https://github.com/mfikes/use-native-code along with instructions on how to see the issue. Perhaps there is something more that needs to be done to use native modules?

I don't think re-natal should be different from a regular rn project?

Right. I suspect I can take that repro and replace the index.ios.js content with the sample code from the Facebook page above

It's entirely due to the cljs size, @pesterhazy. I wrote a macro to generate lots of useless code, worth 4MB when compiled, and now I hit the same exact issues.

haha nice hack

could you put that up as a repo somewhere?

Bah! I found that if I go into the simulator and turn on “Debug JS Remotely”, then the native stuff works.

ios:cljs.user=> (js-keys (.-NativeModules (js/require "react-native")))
#js ["CalendarManager" "StatusBarManager" "SourceCode" "AlertManager" "ExceptionsManager" "DevMenu" "AsyncLocalStorage" "DevSettings" "ScrollViewManager" "JSCSamplingProfiler" "AccessibilityManager" "DevLoadingView" "Timing" "AppState" "DeviceInfo" "Clipboard" "PlatformConstants" "KeyboardObserver" "I18nManager" "WebViewManager" "RedBox" "UIManager" "NavigatorManager" "NativeAnimatedModule" "ActionSheetManager" "LocationObserver" "ImageStoreManager" "ImageViewManager" "ImageEditingManager" "LinkingManager" "NetInfo" "Networking" "SettingsManager" "Vibration" "WebSocketModule"]

If I flip back to turn off remote debugging:

ios:cljs.user=> (js-keys (.-NativeModules (js/require "react-native")))
#js []

Also, when enabling remote debugging, it sets up the bridge and ends up calling my RCT_EXPORT_MODULE(); macro code again.

https://github.com/facebook/react-native/issues/11654

@pesterhazy https://github.com/jeaye/react-native-packager-bug

Sources: https://github.com/jeaye/react-native-packager-bug/tree/master/env/prod/env/android

cool!

I've opened https://github.com/pesterhazy/re-natal-husk to explore my "empty husk" bundle idea

it works, just a few problems left to solve

Oh, awesome.

I just can't get the packager not to uglify/mangle a function argument name

can't come up with any tricks

hm

like, the packager will insist on renaming function(require){BLA(require)} to function(o){BLA(o)}

That's likely not anything which is parameterized.

is there a way to trick minfiers into not renaming a var or an arg?

Nothing I know of, but that isn't much in the cljs/js world.

Fortunately, I can report that the :advanced route is actually able to get us into the app.

@pesterhazy Does exporting the fn help?

nice about :advanced comp

Ok, got it to work: https://github.com/pesterhazy/re-natal-husk#re-natal-husk

Ah need Android-specific bits then?

I only tried it with iOS, but it should work the same for android

it's hacky still - a few things should be improved

but it gives you fast packager builds that won't run out of memory

because the packager never sees the Google Closure generated bundle

this was the magic bit: https://github.com/pesterhazy/re-natal-husk/blob/master/patch-react-native-xcode.sh#L96

heh

We'll take a deep look at this, thanks!

Cool. Let me know what you think