At this point I don’t see why it’s so important for there to be tight Meteor integration unless you want Tracker and minimongo so badly. Just use the DDP client Npm package and be done with it. There’s a whole bunch of great libraries for handling data and optimistic updates already. There should be nothing stopping you from building an RN app that communicates with Meteor.
1 Like
Isn’t the dynamic updating the biggest advantage?
@martijnwalraven Would it be possible to use the new download mechanism to grab the latest react native bundle and serve it locally?
1 Like
@batist: We might be able to reuse parts of the new download mechanism for React Native, but right now it is implemented as a Cordova plugin and tied to the needs of web apps (it serves files through an embedded HTTP server / request interception mechanism).
The main advantages of the plugin are incremental updates and tight integration with our build tool, but those seem less important with React Native and might actually be a disadvantage (having to use our build tool would mean you couldn’t take advantage of React Native’s packager or react-native-webpack-server).
1 Like
Products like AppHub will allow you to push JS code to the client without re-uploading to the app stores. Like Cordova, if any native code is changed then re-uploading to the appstore is required.
Now that GraphQL is the future delivery system for data, integrating the rest of the browser meteor JS code is a pretty low priority since node-ddp-client, ddp-login, and vanilla graphql handle all you need. I think someone also open-sourced a wrapper for node-ddp-client that gives you a meteor.js like API.
If you need minimongo with a local collection, Pete hunt open-sourced one that works with RN.
2 Likes
Would it be to much to ask you to elaborate on “GraphQL being the future delivery” and how does that impact meteor js via react native
Sure! I think that’ll help solidify the opinions bouncing around my head too 
TL;DR If you boil it down it comes down to the problem of old native app versions that are not upgraded that break as the backend changes due to a different response or query. GraphQL solves this problem very elegantly.
MDG is working on a reactive layer for GraphQL called Apollo. For more complicated apps this will be the preferred approach because of it’s flexibility and scalability.
Pub/Sub and Livequery will still continue to work in the browser but getting that to work in React Native as well will take a lot of work for little for very little benefit (basically people who have already learned livequery won’t have to relearn GraphQL).
This nice NPM package react-native-meteor fills the gap between Meteor in the browser and node-ddp-client (which is a bit verbose honestly). It basically gives you the ability to login, call methods, and subscribe to reactive-data.
Ok back to GraphQL. So today in React Native if you want to get non-reactive data you can:
- use AJAX calls to a Meteor serverside router
- call
Meteor.callwith a DDP client like react-native-meteor - use Kadira’s GraphQL Meteor package (includes Meteor auth)
In this case (non-reactive data fetching), AJAX is backend independent but doesn’t offer Meteor auth integration and suffers from version constraints from older native apps. Meteor.call also has this version constraint issue.
The GraphQL package has built in Meteor auth support and doesn’t suffer from the old app version problems (due to deprecation of fields). You can have clients many versions behind and still work perfectly. It was first conceived to fix this problem with mobile APIs at Facebook and then moved to other apps later. This is the main reason why I think it’s a no-brainer to choose for mobile apps.
However, there is an elephant in the room. Reactivity. If your app needs reactive data then you have a few options. You can long-poll the GraphQL request every X secs/mins to refresh data and then eventually swap out any minimal changes when Apollo is done.
If you really need reactivity that is so frequent that long polling is untenable then you can use the previously mentioned react-native-meteor module to subscribe to data and then cache the data.
Regardless of if it’s reactive or not, any one of those methods will have a response callback with data that needs to get inserted somewhere to update the view. It could be Reacts own setState, Redux, minimongo-cache, etc… This is process is very very similar to making an AJAX request and storing in a local minimongo collection with vanilla Meteor.
Hope this helps!
3 Likes
Hello
I have been toying around with Meteor, React, React Native, for a few weeks now and I think Meteor and React Native are brilliant technologies. I have been exploring how to get Meteor to be friends with React Native and I stumbled across this post, it has been an interesting read. Thanks!
My mind is not made up on a few things. I have been wondering - and these questions maybe a little naive or philosophical - why should MDG involve itself with the React Native ecosystem in the first place?
Suppose - I am not interested in building a ‘universal’ app - an app that works on web, tablet and mobile browsers and is also packaged as for Android and iOS devices. Suppose - I want to have an app that works on the web, tablet and mobile browsers. Along with this I also want to have native iOS and Android apps.
Meteor is exceptional in solving the first use-case. It is probably the best ‘stack’ right now and will be for the foreseeable future. It is good with the second use case too but eventually, I think, and personally hope, that developers will move away from universal (single code for mobile and web) apps as mobile tech evolves (which I think is evolving at a faster rate than browsers). I stand in favour of native apps. I think this will be a trend in the future.
If I have to code separately for mobile and web, perhaps using similar technologies (like React and React Native), I have to have two different ways of ‘doing things’ for mobile and web. This includes how I ‘talk’ to a datasource.
Meteor’s pubsub model is exceptional and solves the problem for the web very elegantly. The ‘feeling’ of ease you get while playing around with data in Meteor is not yet there in React Native.
Would it not be a better idea for Meteor MDG to enable ‘mobile apps’ (built with React Native) to ‘interact’ with the data that ‘web apps’ (built with Meteor) creates? The idea is that data is just data, it does not matter where it comes from or who interacts with it. Native and Web applications interact with the same data source.
It would be very appealing to have something by Meteor MDG that enables this for React Native.
Best
/P
PS: On the side: I envision a ‘super-stack’ not too far into the future, with the same goal as Meteor (super easy app JS dev) but where one can develop for web and natively for mobile simultaneously and side by side in JS with great ease. Something like ‘Meteor Web+Native’. Wherein one uses the same code for the server but writes two different codes for two different fronts. All of it in JS. I think Meteor should be closer friends with React and React Native than it is with Cordova.
I develop for mobile (native apps) and web side by side but the ‘mobile front’ is just a user of a RESTful API endpoint, the codes are kept separately, I have to manage packages separately, etc, etc, - et al. - the usual. The ‘mobile front’ is like the proverbial third wheel. A ‘super-stack’ of Meteor and React Native would be the way to go if I was MDG.
@arunoda “has anyone tried integrating React Native app into Meteor’s build process”
I did but there were numerous collisions and I did not have the patience to work through it. The ideal was to use the same code base for the server and use two ‘fronts’. So I had thee folders for three code types, ‘client’, ‘server’, ‘mobile’; there were two index files (index.mobile.jsx and index.web.jsx). It was a trivial test, a simple hello world app, but even then I could not tamper very well with the Meteor build process (it was because I didn’t know how to). But I believe that it is possible, although in a very convoluted way (for now).
See my previous post about the idea of a ‘super stack’. If MDG is indeed thinking going down that line than I believe that it would need to re-think and re-work it’s core philosophy and under-the-hood stuff a little bit.
1 Like
Well, actually I think http://www.phoenixframework.org/ is the bestest.
See the idea of Channels. http://www.phoenixframework.org/docs/channels
Channels are a really exciting and powerful part of Phoenix that allow us to easily add soft-realtime features to our applications. Channels are based on a simple idea - sending and receiving messages. Senders broadcast messages about topics. Receivers subscribe to topics so that they can get those messages. Senders and receivers can switch roles on the same topic at any time.
Since Elixir is based on message passing, you may wonder why we need this extra mechanism to send and receive messages. With Channels, neither senders nor receivers have to be Elixir processes. They can be anything that we can teach to communicate over a Channel - a JavaScript client, an iOS app, another Phoenix application, our watch.
1 Like
Yes, I’m following it closely along with quit a few others. From what I understand, MDG is working on Apollo, a reactive graphQL data level, which should work well RN. Meanwhile others are using RN Frontend that interact with meteor data via DDP.
This repo highlights the a solid approach
This show cases the approach:
So does this:
Next you’ll have to settle on a good routing / navigation system, these two seem promising
And my leaning
Hope this helps
2 Likes
@lai can you point to some of those DDP packages? I’m aware of stuff like react-native-meteor and node-ddp-client.
I would imagine that manual DDP integration requires a lot of boilerplate. User accounts, pub/sub, especially storing data. Mini-mongo was an incredible reactive data store for the client… Without it, we need to write that code manually.
This is a really informative post, thanks a lot for sharing!
1 Like
The packages that you listed are the ones I was talking about.
1 Like