I do miss using $in and some simple query syntax sometimes
check out this guy in youtube. using apollo, react-native, express. Using Apollo is as easy as using Meteor. https://www.youtube.com/channel/UC7R7bcH9-KEBDiGNP1mZnmw/videos
My issue with using Apollo for this first mobile app is that it will be communicating with the same MongoDB as an existing Meteor app. In this case, why not just use that app’s server to talk to the db? Why add Apollo to the mix when my main app doesn’t use it? I would be adding a level of abstraction for no good reason.
true that @aadams. For your use case now it doesn’t make any sense. I am however doing all my new apps with apollo & react native. Works great. There are some gotchas in integrating redux with apollo though.
Thank you so much for let us know.
I think it’s best to make your own thin API that will work with any data structures you currently need. Be it minimongo or simple arrays. If you’ve got the time, of course)
Do you find you need something custom beyond just using lodash?
Not exactly. I simply like to have a unified api to rule them all
It’s good buuuut yeah, you can’t use libraries which… sucks. badly. Also, another third-party getting my app’s code? nah thanks. it’s good to learn and that’s all I wouldnt recommend shipping to production with expo and if you prototype using expo’s features you will have to remove it when you want to ship it to production. So… I don’t recommend at all
Yup, I also got mixed feelings about Expo. At least, your first statement isn’t true. You can “eject” and continue working with a bare-bones React Native app. However, you would still be dependent on their libraries. Which is OK if it makes your life easier. BTW: Just found out that Expo is now also used for
create-react-native-app. So it seems to be “officially supported” by the React team at Facebook.
I’m looking into making a React Native mobile app myself…
I thought the same thing – you’re tied into their way of doing this, they control the pace of change/updates (if you want to stay current), and they control the “controls” and API for the most point. It’s opininated, so you’ll be in a “Meteor” situation. I think I’m “OK” with that if it adds a lot of value, as Meteor does.
I read that too – but it seems by going react-react-native-app, you only get a subset of Expo – you’ll have to allow Expo to create the app if you want the full suite of tools/controls/abilities.
Really? They’re adding new libraries every month. And most of the libraries are just ports of the most popular ones for the given functionality. For instance, their maps module is just airbnb’s maps. If you had to exit expo for some reason, you literally wouldn’t have to touch your map code.
And the only libraries you can’t use are ones the require react-native link… and again that’s only if expos SDK doesn’t already have it. Plus they’re making your expo app virtually identical to create-react-native-app, which is the defacto direction things are going. if you exit, you’re basically ending up with a CRNA.
This is one of the big issues with the programming community. They’d rather spend a month re-inventing the wheel because (1) “it would be good to know” or (2) you may hypothetically one day have to spend a couple weeks to change some underlying technology. Is anyone regretting not knowing how to run their own server system in their basement now that we have the cloud? Are people who never actually needed the fine grained control they planned for really glad they wasted their time “decoupling” to use 14 separate libraries? Is anyone who struggled through react-native 0.0.1 feeling like that time gave them a big ROI now?
Yes, maybe you don’t want to use expo. But first you should be quadruple checking that what your app needs are not do-able with expo. I honestly can’t think of many use cases where you need something outside of expo. From what I can see, the only very common thing missing at this point is a payment module which (1) you can get by with http instead of native and (2) is going to be included in the next release anyway. You can use any router you want. You have what you need for finger print scanning, barcode scanning, maps, file system, contacts system— and it’s all cross-platform out of the box. Maybe if somebody else is footing the bill, and they could care less about the cost, then yeah you can spend time cobbling all of these together and re-inventing the wheel, but I’m not sure how that’s a good business decision or a pleasurable developer experience.
For me, I’m not that interested in learning a bunch of stuff that is going to be abstracted in a month by things like create-react-native-app, expo, or some expo competitor. You have to pick and choose your “learning battles”. And ask yourself… in two months is this going to be abstracted away from what I need to be concerned about? Often the answer is yes. And I’m just not worried that the guys at Expo, who would run circles around your average react-native developer, are really that concerned about stealing the source code for you CRUD app.
Tbh, I feel like your post is the programming equivalent of fake news.
Expo SDK v20.0.0 is now available
just this month:
Improved loading screen, faster startup on Android
new cross platform modules just this month:
- Added a Camera API Reference. (see example of snapchat-like abilities)
- Added a SecureStore API Reference.
- Added a Payments API Reference.
- Added a Magnetometer API Reference.
5 more use cases you don’t have to cobble together yourself or worry about finding npm packages for android and ios… no more worrying about if some random internet guy is going to stop supporting your library.
and a new post on an example app
there is like 10 apps ready for you to learn from
always learn from the code than reading dumb stuff