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