it’s crater podcast episode #88 , can’t tell the time because I was driving my motorbike while listening to it, but anyhow is not official 
I just used the normal NPM packages apnagent and node-gcm for both android and ios services. raix-push is too complicated and coupled. React Native handles getting the push token and an AJAX call or meteor method can save it to the server.
1 Like
I tried running the example an I get this error message regarding naming collisions. The workaround is above my head. How did you get around this problem with react-native-router-flux.
Thanks for sharing all this guys, some really insightful and helpful info here 
1 Like
What was the error that you received?
That’s a very common issue they’re running into and are trying to fix. I think this issue might have the answer. What I did was do a rm -rf node_modules && npm install.
1 Like
One major advantage of using Cordova (which is essentially a Webview, i.e. a browser) is hot code push. My understanding is with React Native you won’t have that (because the client code is, by definition, native). If so, I believe that this alone nips it in the butt and doesn’t make it appealing to many Meteor developers.
1 Like
Are you talking about a hot code push while developing or in production? In development there is hot code push for the JS side, which is pretty fast in my opinion, probably faster than Cordova. For production it also exists but in third party services, also for JS side I think. I’m sure there is an easy way to roll your own production hot code push. Also, you’re mostly going to be writing the native custom stuff once in a blue moon and update the JS most of the time after that.
@lai, I was talking about production. There was an interview of a React Native developer by @joshowens and she clearly said it was a challenge and a foreign concept since code becomes native (it’s somewhere in this forum, have to dig it up).
My understanding of React Native is that it’s really native, and not dependent on UIWebView or WkWebview (or XWalk for Android). Here is a reference from the docs: https://facebook.github.io/react-native/docs/javascript-environment.html#content
On iOS JSC doesn’t use JIT due to the absence of writable executable memory in iOS apps
Remember the JIT conflict between Jobs and Adobe over Flash?
This, by definition, excludes hot push. You mentioned you did it, are you sure and on which platform?
AppHub is one and microsoft has another similar service. I’m setting up my app soon to use this but from what i’ve read you can push any JS code up to new users (and tell how many have a certain version). The native code will still have to be reviewed by the app store (like Cordova).
1 Like
Thanks @SkinnyGeek1010
Just looked at AppHub, interesting, and it says:
Developers add our iOS library to their apps
So they use Webkit or JavscriptCore (like Cordova) – so it’s not really native. No performance improvements from core code, only from UI. This is how Meteor does it too BTW.
Now, is it worth it to manually setup your hot code push instead of benefiting from the one that comes in Meteor? In our case, it is not, but your application may be very heavy on UI.
React Native doesn’t compile your JavaScript to native code, your app always runs in a JavaScriptCore context. The performance benefits come from the use of native UI components and the overall architecture. So React Native apps can use hot code push fine, as long as you are only pushing JavaScript code and not changing the set of native views or modules you use (just as you can’t change the set of Cordova plugins through hot code push).
4 Likes
Thanks @martijnwalraven,
The question now is whether MDG / Community thinks React Native is the way to go for the future for mobile, as hot code push will have to be programmed into it (like you are doing for Cordova). It would be great to close this conversation as it came up a few times.
My take, please comment:
- We would be constrained to React as the view layer
- We would lose the flexibility of all the Cordova plugins – which have tremendous value
- Is it really worth it at this point, given how far wkWebView and XWalk have come in terms of performance (personally I think React Native is solving a problem that existed before)
- Finally, it seems React Native and ReactJS don’t 100% play well together (i.e. it’s not yet write-once). So some rewrite may be needed
React Native is not just about performance, but also about fitting in with the native platform. Although WKWebView and Crosswalk offer a much faster web view, you still end up having to recreate a native user experience using web technologies. Frameworks like Ionic try to help you here of course, but my feeling is that no matter how hard you try, a web-based UI won’t get you all the way. I also think the programming model React offers is an improvement even over native development. So I’m personally really excited about the direction React Native is taking, and I hope to work on a better integration with Meteor and Apollo in the future.
Having said that, for many people Cordova is likely still the way to go. As you mentioned, you would have to buy in to React to use React Native, so that will keep some people from making the switch. And although the beginnings of an ecosystem are there, you won’t find the broad selection of features Cordova plugins offer yet. You are also right sharing UI code between desktop apps and mobile apps is currently much harder in React Native than it is for web, although I believe the React component model makes it very suitable for progressive enhancement (I’ll actually be giving a talk about this at React Europe).
4 Likes
They’re not using Webkit for this. It does use JavaScript core to talk to an async bridge though.
Finally, it seems React Native and ReactJS don’t 100% play well together (i.e. it’s not yet write-once). So some rewrite may be needed
It will never be write-once with React Native. They have a ‘learn once, write many’ mindset. However, you can share a lot of code. Especially if you separate business logic from the UI (ie, Redux).
I have a simple app that can re-use 90% of the code. The init files are different for the platform and then the Header component is different (via Navigator). The router also has conditionals to use different transition animations based on the current platform.
Certain things do not share because I want a native feel… like the date picker for example. I just require ../components/datepicker and then have two files, one with a .ios.js and one with .android.js extension and the correct datepicker will be rendered. Because styles are inline with the component, each datepicker will position itself in the ‘page view’ properly.
Sharing code between desktop and mobile is a complete joke IMHO. If you need to do that then a responsive website is a better approach. You’re just going to end up with a bloated tangled mess if you try to have a native app and desktop app in the same codebase. Connecting to the desktop app DDP is fairly easy to do also.
In my experience the mobile development with React Native compared to Cordova is a huge improvement. Cordova (when I built 2 apps with it at least) had a lot of problems with the plugins actually working and constantly broke.
We would lose the flexibility of all the Cordova plugins – which have tremendous value
They have an adapter now that allows you to consume any Cordova plugins with this: https://github.com/axemclion/react-native-cordova-plugin
Also you could fork a Cordova plugin and manually retrofit it to the RN bridge.
6 Likes
Thanks @SkinnyGeek1010,
Definitely worth watching.
My concern in the immature ecosystem given it’s new, but that will likely evolve.
Exciting times!
1 Like
Hello, I noticed that I didn’t reply by @lai pointed to r direction that seemed to have helped. The error was along this line:
Error building DependencyGraph:
Error: Naming collision detected: /Users/samuelpurcell/Projects/…/node_modules/fbjs/flow/include/warning.js collides with /Users/…/Projects/…/node_modules/fbjs/lib/warning.js
Apparently it was naming collision between nested node_modules react, react-native dependencies. Frankly, I’m still a bit unease because there seemed to have been so many different recommendations about how to fix the problem. Nevertheless, thank your for the recommendation.
Also, I hope you all stick around this space for a while ( meteor + react + redux + react-native ), I’m considering astronomy, mantra, react-native, react-native-router-redux. Sounds promising.
Are you aware of any Atom packages to support react-native routing, schema, reactive model-objects?.
1 Like