<script src="https://cdn.firebase.com/js/client/2.0.6/firebase.js"></script>
<script>
var root_ref = new Firebase('https://jcatest.firebaseio.com')
function other_function() {
// many lines of code here...
var x = {}
x.x()
// many lines of code here...
}
function my_function(snap){
other_function()
}
root_ref.once('value', my_function)
</script>
If I stick the above code in an html file and open it with Chrome all I see in the console is
"Uncaught TypeError: undefined is not a function ... firebase:26"
In Firefox I see the actual error message:
"TypeError: x.x is not a function ... temp.html:8"
Why am I not seeing the proper error message in Chrome?
Is this a Chrome bug? A Firebase bug? Or am I doing something wrong?
It's a big problem for me because there's a lot of code in my callback and firebase is basically saying, "there's an error somewhere." Not very helpful.
This problem was reproducible on FirebaseJS version 2.0.6. With Firebase 2.2.2, errors and full stacktraces are reported correctly on both browsers.
In the Firebase web client, the Firebase.DataSnapshot object has no method value(), but there is a val() method, which is probably what you're looking for.
See the DataSnapshot docs for more information.
I suspect that the browser is not giving you the relevant error line because the error occurs in an anonymous function, but that's a guess.
If you wrap the callback in a zero ms setTimeout call you get the traceback. Not sure why this is necessary.
root_ref.once('value', function(){ setTimeout(my_function) })
Related
Summarize the problem:
When I merge a commit to Gitlab and run a pipeline, there is a script failure when trying to deploy. more specifically: WebpackError: ReferenceError: __WEBPACK_EXTERNAL_MODULE_firebase_app__ is not defined
-The goal of this post is to hopefully get a better understanding of what I am doing wrong here, as I am trying to follow the errors to find the solution on my own, but have not been successful thus far.
-The expected result is that, because the pipeline had previously worked up until this point, that it would continue to do so. The strange part about this pipeline failure is that I did not actually install any packages on the merge that caused the failure. I went ahead and updated packages and some previous errors went away (for instance, there was a failure involving the sharp library that has now gone away) but now firebase app has become the focus.
The only actual error I saw in the output was WebpackError: ReferenceError: __WEBPACK_EXTERNAL_MODULE_firebase_app__ is not defined followed by ERROR: Job failed: exit code 1
Describe what you've tried: as stated before, I initially thought if I just updated all dependencies, this would help get me a better idea of what was going wrong. I thought I was on the right track when I noticed more progress along the pipeline than before, and there was this issue error (node:260) [DEP_WEBPACK_EXTERNALS_FUNCTION_PARAMETERS] DeprecationWarning: The externals-function should be defined like ({context, request}, cb) => { ... } (Use `node --trace-deprecation ...` to show where the warning was created) so I followed the error message's advice and added curly brackets around context, request in my gatsby-node.js file. That error went away on the next pipeline attempt, but WebpackError: ReferenceError: __WEBPACK_EXTERNAL_MODULE_firebase_app__ is not defined remains
Show some code:
I believe the gatsby-node.js file is what is relevant here, so here it is:
exports.onCreateWebpackConfig = ({ stage, actions, getConfig }) => {
if (stage === 'build-html') {
actions.setWebpackConfig({
// Don't bundle modules that reference browser globals such as `window` and `IDBIndex` during SSR.
// See: https://github.com/gatsbyjs/gatsby/issues/17725
externals: getConfig().externals.concat(function ({ _context, request }, callback) {
// Exclude bundling firebase* and react-firebase*
// These are instead required at runtime.
if (/^#?(react-)?firebase(.*)/.test(request)) {
console.log('Excluding bundling of: ' + request);
return callback(null, 'umd ' + request);
}
callback();
}),
});
}
};
I can provide other details if needed, and would appreciate any advice that anyone has to offer. Thanks!
Downgraded Gatsby back to v2 (as well as all the relevant gatsby plugins) and the error went away
I cant figure out why my insert query code located in server/main.js is causing this: TypeError: callback is not a function error message.
The following code is located at: server/main.js
var businessCard = [{PostedDate: moment().add(0, "days").format('MM/DD/YYYY'), sentBy: currentUserId, recipientName: recipientName }];
Next line is the insert query:
Messages.insert({businessCard: businessCard}, {multi:true});
When I run the code, no inserts into the Messages collection are carried out, neither do I get any error messages in the browser console,
however when I check the terminal I see the following error message:
When I comment out the insert query, the error message disappears, leading me to think there is something wrong in how I have written this insert code.
Kindly help me figure out what am doing wrong here.
Looking forward to your help
The error is because you use multi: true option, insert method does not have this option.
I was looking through nest's example code, and in the javascript/smoke_alarm example they use alarm.on('change', function(snapshot) {...} instead of using alarm.on('child_changed', function(snapshot) {...}.
I don't see any documentation for 'change' in the firebase docs, and it raises an error when I use it:
Error: Query.on failed: First argument must be a valid event type: "value",
"child_added", "child_removed", "child_changed", or "child_moved".
Is this just a bug in the sample code, and it should really read: alarm.on('child_changed', function(snapshot) {...}? Or am I missing something?
Sorry about that, it is a typo. The sample code has now been updated.
Due to the nature of HTML5 Notifications, it currently works best in Safari, but I also modified the sample to log events in a for other browsers so you can focus on the Nest specific code.
I read a value from database, then based on that value, I read a second one. Here is the code:
mydb.db.get("store1", 1)
.then(function(result1) {
// Assume result1 is needed here.
// This second get() will cause error.
return mydb.db.get("store2", 1);
})
.then(function(result2) {
// Assume result2 is needed here.
});
The problem is, the second get() will cause this error (copied from console output in Chrome):
Uncaught TypeError: Cannot call method 'push' of undefined (in deferred.js:397)
If I remove the return clause, no error produced but I cannot get the result2.
I am using ydn.db-isw-core-qry.js (production) v0.8.12 with source map, IndexedDB database on Chrome 33.0.1750.149, Windows.
Is there something wrong with my code? Please help.
Thank you.
Here is test http://dev.yathit.com/test/issue_107.html as you described. No error. Please show your code that cause your error.
I'm having a doozie of a time trying to get a basic http test to work with vows.
I think I've followed the async example from vows http://vowsjs.org/#-writing-asynchronous-tests and substitued the appropriate calls, but I must be missing something.
The test code looks like this:
var http = require('http'),
vows = require('vows'),
assert = require('assert');
vows.describe("homepage").addBatch({
"Get the home page": {
topic: function() {
http.get({'host': "127.0.0.1", 'port': 5000, 'path': '/'}, this.callback);
},
'should respond with 200 OK': function(res) {
assert.equal(res.statusCode, 200);
}
}
}).export(module);
I get the following error when I try to run the test for this:
/Users/<home_folder>/node_modules/vows/lib/vows.js:80
rrored', { type: 'promise', error: err.stack || err.message || JSON.stringify(
^
TypeError: Converting circular structure to JSON
at Object.stringify (native)
at EventEmitter.<anonymous> (/Users/<home_folder>/node_modules/vows/lib/vows.js:80:90)
at EventEmitter.emit (events.js:64:17)
at /Users/<home_folder>/node_modules/vows/lib/vows/context.js:31:52
at ClientRequest.<anonymous> (/Users/<home_folder>/node_modules/vows/lib/vows/context.js:46:29)
at ClientRequest.g (events.js:143:14)
at ClientRequest.emit (events.js:64:17)
at HTTPParser.onIncoming (http.js:1349:9)
at HTTPParser.onHeadersComplete (http.js:108:31)
at Socket.ondata (http.js:1226:22)
I can get a simple http example to work on it's own. I can get the vows example to work on it's own but I can't combine them for whatever reason. I'd really appreciate some help here. I've been trying to get this to work for a while now (including much googling).
UPDATE:
Apparently adding an error argument to the call back solves this problem, thanks to help from Alexis Sellier (creator of vows).
But I have no idea why. When writing out the http lib example on it's own no error argument is required. I can't find any documentation in vows to indicate why it's needed so I'm at a bit of a loss.
My new question is why is the error argument required when using the http lib in vows?
After checking vow's source code, I think I know why. Vows always ensure that when you call this.callback, the resulting receiver function's first argument is always an error object. Vows interpret the callbacks by these rules:
If the first argument of your originating callback is a boolean, use that to determine whether or not to append an error object to the receiving callback (e.g. path.exists(boolean) will emit callback(error, exists) instead)
If the first argument is an object, assume it's an error object and use that to determine whether to add the originating callback to the "error" or "success" list. The reason this list exists is to support promise based tests I guess?
While I can't confirm the above is correct, my experience is that vows' async style is made to support node-styled callbacks (e.g. err as the first arg), and 3rd party npm modules that don't conform to this standard will be hard to test.
Please don't take my answer as gospel, as this is my own experience. Another gotcha is when you have async operations inside the function that you want to test - unless you provide a callback, vows won't be able to handle it properly.
Personally, I think vows still make it hard to test async code. I wish it had some waitFor() or until() flow control functions though.
My suggestion? When dealing with async code, use Step. Don't let vows control your flow.
It is actually missing in the documentations which is still a bit short. But you can get a glimpse of it here in this page :
'when peeled *asynchronously*': {
topic: function (banana) {
banana.peel(this.callback);
},
'results in a `PeeledBanana`': function (err, result) {
assert.instanceOf (result, PeeledBanana);
}
}
As it was said by Morten Siebuhr and Ruben Tan, this is how vows works and that is why it works like that.