Using Reactjs with Meteor and my component's setState() results in an error and only on the staging server, not on my local machine.
This is the error
Exception in delivering result of invoking 'banners.list': e#http://example.com/09d8a88b6d8e1e9a36c24cbe031f383a60bbb044.js?meteor_js_resource=true:196:27322
require<.node_modules.react.lib["ReactCompositeComponent.js"]</S._renderValidatedComponentWithoutOwnerOrContext#http://example.com/09d8a88b6d8e1e9a36c24cbe031f383a60bbb044.js?meteor_js_resource=true:61:7658
require<.node_modules.react.lib["ReactCompositeComponent.js"]</S._renderValidatedComponent#http://example.com/09d8a88b6d8e1e9a36c24cbe031f383a60bbb044.js?meteor_js_resource=true:61:7826
require<.node_modules.react.lib["ReactCompositeComponent.js"]</S.performInitialMount#http://example.com/09d8a88b6d8e1e9a36c24cbe031f383a60bbb044.js?meteor_js_resource=true:61:2297
require<.node_modules.react.lib["ReactCompositeComponent.js"]</S.mountComponent#http://example.com/09d8a88b6d8e1e9a36c24cbe031f383a60bbb044.js?meteor_js_resource=true:61:1553
require<.node_modules.react.lib["ReactReconciler.js"]</a.mountComponent#ht[…]
The code responsible for this error is
const that = this;
Meteor.call('banners.list', (err, data) => {
if (err) {
console.error(`Error fetching banner info with ${err.reason}`);
}
console.log(data)
that.setState({
isBannerPrepared: true,
banners: data,
});
});
Pretty basic. Once I remove the that.setState(), it works fine. data is not null.
why you would do this...this way?
as I know you can manipulate props in react from the meteor. Meteor updates the props and you in the react events update the state.
Related
Nuxt 3 has those amazing data fetching functions (ex.: useFetch), but I come out on a situation that I need to make request after the rendering time (ex.: calling from a button and send a search term).
As I far know, useFetch are not working on client-side, here is what I have trying to do
<template>
<button #click="goSearch()">Search</button>
</template>
setup() {
const goSearch = async () => {
const { data } = await useFetch('search', () => $fetch('/api/search'));
console.log(data.value);
};
return { goSearch };
},
}
Does nuxt3 offers a built in function to make http request on demand (client-side official http axios like)?
$fetch should work. The problem were a small bug that is now fixed. If you are experiencing this bug, just upgrade nuxt/ohmyfetch lib
npx nuxi upgrade --force
More here:
https://github.com/nuxt/framework/issues/2502#issuecomment-999783226
useFetch is the same as using $fetch, here why not simply use fetch already in your code ?
const { data } = await $fetch('/api/search' );
i think you code is simply no just youcan use useFetch even on client side but like that :
const { data } = await useFetch('/api/search')
I've been attempting to get to the bottom of issues with a Firebase function I'm using to update some aggregate data in Firestore. I set up a simple test bed and found that any attempt to access the data triggers the error:
> Error: Could not load the default credentials. Browse to https://cloud.google.com/docs/authentication/getting-started for more information.
> at GoogleAuth.getApplicationDefaultAsync (/Users/michael/Documents/htdocs/vue/mjf20/functions/node_modules/google-auth-library/build/src/auth/googleauth.js:160:19)
I've attempted to just copy the entire Firebase config into the initializeApp() function, but it still generates the same error. Here's the entire test code:
const functions = require('firebase-functions');
const admin = require('firebase-admin');
admin.initializeApp();
const db = admin.firestore();
exports.postCache = functions.https.onRequest((request, response) => {
console.log("Starting test function");
db.collection('myCollection').doc('myDoc').get()
.then(snap => {
if (!snap.exists) {
console.log('Document not found');
} else {
console.log(snap.data());
response.send(snap.data());
}
})
.catch(error => {
console.log('In catch block');
console.log(error);
response.send(error);
});
});
If I take out the db stuff, the function will work fine. As soon as I add even the simplest firestore request, it generates the error. I've seen this issue asked about before, but the situations seem different, and none of the solutions seems to work. I'm stumped.
The code is perfectly fine.
I have implemented it exactly on my testing project using this tutorial.
I have added your code to index.js and in my firestore I have added collection myCollection with myDoc with just one testing field and deployed using firebase deploy.
Everything works fine. You should focus on your environment and deployment steps to figure out what is the problem. This link that you have in the error is mentioning environment variables. Maybe a case as well.
I hope it will help!
I'm able to authorize the Firebase app from my existing Electron app using firebase.auth().signInWithCustomToken. The promise for this method resolves and I'm able to obtain the current authorized user with firebase.auth().currentUser.uid.
At this point I must technically be able to write to /users/<currentUser>. However calling the userRef.set() and userRef.update() methods does not update the database reference and fails silently (both the callback and the promise from these methods do not resolve and there is no error thrown).
What is strange is that the exact same code works in a different, newly created Electron app. My code looks like below:
const writeToFirebase = (customToken) => {
syncApp.auth().signInWithCustomToken(customToken).then(user => {
const userId = firebase.auth().currentUser.uid; // this is successfull
const userRef = firebase.database().ref("/users/" + userId);
userRef.set({data: data}, () => { //callback does not trigger });
userRef.update({data: data})
.then(() => {//promise does not resolve})
.catch(err) => {// promise is not rejected either! }
});
}
Any pointers on how to go about debugging this would be helpful.
I discovered the problem. It's unlikely anybody else would have the same issue, but if you do, take a look at the userAgent value in your browserWindow.loadURL in Electron.
Mine was set to an Android mobile device & Firebase was not setting/updating due to this reason. I presume the Firebase server reacts differently when it sees a mobile userAgent and I was using the Firebase JS SDK and not the Android SDK which caused the issue.
I am trying to create a Meteor app that stores content in a Meteor collection to be passed between the server and the client to display a success message after an asynchronous api call through the twit package.
However, I am running into an issue where when I update the collection on the server and the updates are not reflected on the client. My code is as follows:
/lib
Alerts = new Meteor.Collection("alerts");
/client
Template.suggestionForm.events({
"submit form": function (e) {
return Meteor.call('submitMessage', message);
}
});
Meteor.subscribe('alerts');
Meteor.startup(function() {
Tracker.autorun(function() {
console.log(Alerts.find());
})
});
/server
Fiber = Npm.require('fibers')
Twit = new TwitMaker({
consumer_key: '...',
consumer_secret: '...',
access_token: '...',
access_token_secret: '...'
});
Meteor.publish("alerts", function(){
Alerts.find();
});
Meteor.methods({
submitMessage: function(message) {
this.unblock();
Twit.post('statuses/update', { 'status': message }, function(err, data, response) {
Fiber(
Alerts.remove({});
Alerts.insert({response: err});
).run();
}));
}
});
When I submit the form the function calls just fine and updates the collection, however the Tracker.autorun() does not run. Any ideas why this is happening or how I can make the client listen for changes in collections would be super helpful. Thank you!
Remember to return the resulting cursor in the publish():
Meteor.publish("alerts", function(){
return Alerts.find();
});
Reference: http://docs.meteor.com/#/full/meteor_publish
Publish functions can return a Collection.Cursor, in which case Meteor will publish that cursor's documents to each subscribed client. You can also return an array of Collection.Cursors, in which case Meteor will publish all of the cursors.
and
Alternatively, a publish function can directly control its published record set by calling the functions added (to add a new document to the published record set), changed (to change or clear some fields on a document already in the published record set), and removed (to remove documents from the published record set). These methods are provided by this in your publish function.
If a publish function does not return a cursor or array of cursors, it is assumed to be using the low-level added/changed/removed interface, and it must also call ready once the initial record set is complete.
I am just starting to build a new Meteor app. The only thing I have done so far is add one Collection. It will start, run fine for about 5 minutes, and then give me the error message "Failed to receive keepalive! Exiting."
What is failing to receive keepalive from what? I assume this has something to do with Mongo since that is the only thing I have added. Googling the error message turns up nothing except Meteor sites that are just showing this error message instead of the their app.
My MongoDB collection already had data in it that was not created by Meteor and it is over 4GB if that makes any difference.
This is the complete app.
pitches_sum = new Meteor.Collection( 'pitches_sum' );
if (Meteor.is_client) {
Template.hello.greeting = function () {
return "Welcome to my site.";
};
Template.hello.events = {
'click input' : function () {
// template data, if any, is available in 'this'
if (typeof console !== 'undefined')
console.log("You pressed the button");
}
};
}
if (Meteor.is_server) {
Meteor.startup(function () {
console.log( '**asdf**' );
});
}
If I comment out the pitches_sum = new Meteor.Collection( 'pitches_sum' ); line, then I don't think I will get the error message any more.
This was being caused by my large data set and autopublish. Since autopublish was on, Meteor was trying to send the whole 4GB collection down to the client. Trying to process all the data prevented the client from responding to the server's keep alive pings. Or something to that effect.
Removing autopublish with meteor remove autopublish and then writing my own publish and subscribe functions fixed the problem.