Don’t know why it hasn’t surfaced in the forum yet. But This looks like an interesting news
Looks great, but it’s failing within my React Native app:
UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 1579): UnableToResolveError: Unable to resolve module `./install-packages.js` from `/Users/me/Desktop/Entwicklung/app/app/node_modules/meteor-client.js`
@Urigo is the man to answer these questions. I too want to use meteor as a backend if I can with react native. The current setup has been working for @spencercarli who has written the only book available on meteor+react native. However, if npm installable meteor client is available, I’m down for using meteor as an api only.
Yeah, I hope I can replace meteor-react-native with it, would be interesting if we could use ground:db for offline caching
So in theory, we can make it use Next.js too?
Yeah this same approach should work with next.js!
Although, it would be interesting to make next.js itself work as a build plugin in Meteor, the same way it works with Webpack today.
@XTA I see you already posted the issue on the MCB repo(https://github.com/Urigo/meteor-client-bundler/issues/10), thank you for that.
@kaiyes you should be able to use MCB with React Native and it is an additional option to the regular Meteor way.
If you face issues, please also file an issue on the MCB repo.
I wanted to create a React Native example before the post but didn’t want to wait for it, would love to get help on that from someone from the community.
I made it work with Vue using official
vue-cli, so yes it’s possible. (Using Vue, not Next.js :P)
Sorry for double-posting.
I’m trying to make a POC of using this package with Nuxt.js (Next.js clone for Vue).
It works fine, until I try to actually
import 'client-bundle' to files rendered on the server, in which case I get
ReferenceError: document is not defined error. Well,
client-bundle name speaks for itself.
Did anybody manage to make it work with server-side generated page? Is there a workaround for it?
I can of course tell Webpack not to use this file in SSR mode, but then I’d basically have to render an empty page without Meteor content (while still having it loaded on the client which would result with “server and client content don’t match” issue).
I’m super busy now but as soon as I get some time, I wanna try it with react native. So many times I wished I could use ionic cli or other cli like onsen etc and use Meteor only for api !
Hi all looks really interesting, we’ve just started down the approach of
react-native-meteor-redux but it seems like jumping on the MCB bandwagon would be a better approach.
We’d then need the redux bit working… so I assume we’re just watching DDP connection as per https://hackernoon.com/getting-started-with-react-navigation-the-navigation-solution-for-react-native-ea3f4bd786a4
Any thoughts/direction welcome?
BTW, See this issue https://github.com/inProgress-team/react-native-meteor/issues/215
I think the intention of this blog post is definitely not to make other projects such as react-native-meteor feel less useful - a focused integration might be able to do better stuff than a generic solution across all platforms?
Normally yes, but Meteor has it’s own ecosystem, so why not use that in other JS apps too, especially when your backend is based on Meteor. Focussed solutions also need own maintainers, and I guess this is one of the main problems.
Now if only the
meteor-client wasn’t 3-4mb in /node-modules and 330k in production.
@XTA spot on.
Not to take away from the awesome work react-native-meteor & react-native-meteor-redux have done, but the longterm longevity of using a package is always a concern that would potentially sway me to the MDG approach.
Trying to get out heads around the diff between the packages / approaches
mdg is spot on the two most needed cases,
create-react-app based react apps and react native apps.
we were also thinking of using that
react-native-meteor package to get things rolling. However, depending on one single package kinda felt risky and express with all the other tools felt safer.
If mdg goes forward with this
meteor-client-bundler, this can be another source of triumph for meteor. It can hit the sweet spot between express and firebase
Ideally I’d see a potential here of making a light version of Meteor client, without Minimongo or Tracker and instead with the data from publications coming directly to a Redux/Mobx/Vuex store.
I actually really want to build something that will let you hook up a simple array to DDP - right now you have to load all of Minimongo even if you don’t care about using Mongo query syntax, which kinda sucks since stuff like accounts and hot code reload depends on DDP. This means you can’t have hot code reload right now without loading minimongo, but it’s a relatively simple fix just someone has to do it. (Note - this is a personal opinion not an official position)
well I did try to do a mongoless meteor app and failed because many packages bring mongo one way or another