Is there any kind of javascript error that is not handled by onerror in an ember(-cli) application? In other terms, is there any need to add a handler to window.onerror?
In my tests I could not come up with any error that would no be handled by Ember's onerror. Syntax errors didn't get past ember-cli's build process.
EmberJS does an excellent job of containing errors that happen within its boundaries. Errors caused by your Ember code should all get funneled into the Ember-specific handler.
However, browser JavaScript is a complicated beast. Any JavaScript errors that happen outside of Ember would not be captured internally and may only be exposed by the global window.onerror. Some examples of these could include:
Unbounded callbacks into native functions like setTimeout and addEventListener
Non-ember JavaScript libraries and integrations, such as Stripe, Twitter, or Advertisements
Browser-extension script that can interact with the DOM in unpredictable ways.
To get a complete picture of what is happening with your visitors, you should probably attach to both Ember.onerror and window.onerror and send the reports back to your logs. Even if you are not actively developing, browser changes can cause sudden bugs to appear in your application. Like this webkit bug that caused ember to throw errors. There are good options to record errors automatically from Ember apps, like TrackJS.
Disclosure: I am one of the founding developers of TrackJS, so I've debugged a lot of errors :)
In my experience, I would not advise implementing a window.onerror, unless you have a strong reason to do so and you know what you may be doing.
To my knowledge all of Ember's onerror methods piggy-back on to window.onerror and overriding it has potential to override/disable all the error in your app.
Case in point, I had an experience recently where i noticed that all my js errors stopped logging to console altogether. The reason was that another developer in my team had bootstrapped into my index.html to inject a <script> tag which utilized window.onerror for some error reporting script. The result was that overriding window litterally disabled all of ember's onerror becuase they work in a bubbling fashion.
I think if you do want to override window.onerror you need to ensure that it always returns false so that it does not prevent default error handling on the browser.
See: https://developer.mozilla.org/en-US/docs/Web/API/GlobalEventHandlers/onerror
I hope that helps clarify to some degree.
Ember has a built in error event you can use in your routes
actions: {
error(error, transition) {
if (error && error.status === 400) {
//handle error
}
}
}
More Info: https://guides.emberjs.com/v2.0.0/routing/loading-and-error-substates/
Related
I am having a problem with route-level actions that occur asynchronously occasionally not getting handled.
In my Ember app I sometimes receive the error:
Nothing handled the action 'X'. If you did handle the action, this error
can be caused by returning true from an action handler in a controller,
causing the action to bubble.
Where X is the name of some action. The problem is not that the action is bubbling or that the handler is not defined, because it works almost all the time.
The problem, rather, relates to to fact the this.send('X') is called in a promise callback, e.g., after saving a model:
model.save().then(() => {
this.send('X');
});
If the save encounters some network congestion or a delay on my server then the user might have navigated to another route by the time the promise is resolved. And that route might not have an action X defined (or worse perhaps it's the wrong action of the same name).
Is using actions here a fundamental design flaw?
If so, this would seem to severely limit the utility of actions, because they couldn't be used in any asynchronous context.
Or is there some way that transitions out of a route can delayed until any pending async stuff is resolved? (though this might create it's own undesirable symptoms)
IMHO there is not a design flaw in the case you have described. This is the nature of the promises. The same thing can happen within components and there might occur some errors related with trying to set properties on destroyed Ember components. There is a great addon I use to handle such cases: Ember Concurrency
If you take a look at this addon; you will see that there are similar cases explained, which are very similar to the one you have described. I would suggest benefiting from a popular, already heavily used library like this one instead of trying to tackle it by your own. My best regards.
For the simplicity of coding, I would suggest to move such actions to Application Controller and inject it wherever needed.
Application Controller can be injected as
import Ember from 'ember';
export default Ember.Controller.extend({
appController: Ember.inject.controller('application')
});
To use it in Template:
<button {{action 'X' target=appController}}> Login </button>
To invoke it from your code
this.get('appController').send('X');
You can also use Service to achieve this.
You can use isDestroyed guard check before calling send. But I would encourage you to use ember-concurrency addon for this use case. If you can go through How to do you check for isDestroyed? discussion forum, you will get the idea.
I am running into quite some peculiar behavior. The thing is I understand the deprecation warning, however, it should not be happening as an 'observes', IMHO, does not use a getter, so, setting a property should not cause the deprecation.
I am using Ember 2.2.0 and Ember-Cli 1.13.8. Everything is structured in Components and, if need be, Services (global singletons). Here's a simplified version of my code. I should maybe make a JSFiddle and try to reproduce it, but I figured someone might spot the error directly.
Parent component template:
{{my-component model=service.currentModel changed=changed}}
my-component.js:
watchChanged: function() {
this.set('model', this.get('some_internal_value')); //this throws deprecation, even though it should not
this.get('parentView').send('resetChanged'); // reset changed in the parent
}.observes('changed', 'some_internal_value')
I went with the debugger and watchChanged is called EXACTLY ONCE, in spite of this fact, the deprecation warning is thrown. The code works perfectly, save for the deprecation warning. Any ideas?
My workaround is to do the set as a task in the 'afterRender' queue, but this isn't a solution for the issues that I am experiencing.
What is the "ember-way" in this case? Is it a bug or a lack of understanding on my side?
Edit: cross-posted it here.
Edit x1: There are no didInsertElement/willInsertElement hooks implemented in the parent, nor in the child. I assume that the service querying is somehow causing it... but I do not have enough experience with services to say for sure.
I can't see enough of the {{my-component}} code to say for sure, but my guess is that either changed or some_internal_value, or one of their dependencies, are being updated as part of a rendering lifecycle hook. Commonly this is willRender or didInsertElement. Check for those in your component, try commenting them out temporarily to test.
Sometimes an afterRender is necessary, but you should definitely avoid it as much as possible.
When using the Emberfire (Firebase) adapter, I'm getting various errors that indicate the tests are not waiting for data operations to complete.
eg: Error: Assertion Failed: You can only unload a record which is not inFlight. when I try to create, check, and then delete a record
Also:
FIREBASE WARNING: Exception was thrown by user callback. Error: Called stop() outside of a test context at Object.extend.stop (http://localhost:4200/assets/test-support.js:3000:10) at exports.default._emberTestingAdaptersAdapter.default.extend.asyncStart
These errors do not occur while manually navigating through my app, nor when using the standard ember data adapter.
What is causing these errors and how do I avoid them?
Edit: although the symptoms are a bit different (no error thrown), it sounds like this problem may have the same root cause as the errors I've been seeing.
tl;dr
To work around the issue, I've been using a custom test waiter. You can install it with ember install ember-cli-test-model-waiter (works with Ember v2.0+)
Longer answer:
The root cause of these problems is that the ember testing system doesn't know how to handle Firebase's asynchronicity. With most adapters, this isn't a problem, because the testing system instruments AJAX calls and ensures they have completed before proceeding, but this doesn't work with Firebase's websockets communication.
So although these errors don't occur when interacting manually, I believe they technically could if it were possible to click fast enough.
These problems are known to occur with ember-pouch and will likely also occur with other non-AJAX adapters (eg. localstorage adapters (1, 2), or any other websockets-based adapter. It may occur with the fixture adapter, but that may return results immediately and so not trigger this problem). It also happens with other asynchronous processes, like liquid-fire animations (fixed in a similar way)
The custom test waiter I mentioned in the tl;dr works by waiting for all models to resolve before proceeding with the test, and so should work with all of these non-AJAX adapters.
For more background on how ember's testing deals with asynchronicity under the hood, Cory Forsyth has a helpful blog post, and this gist gives another more flexible solution approach but that requires more manual book-keeping.
I have a model (DS.Model) with a few computed properties and it has a custom adapter that extends DS.Adapter. Nothing asynchronous that I know of is going on here, but in my qUnit test I get the error pasted below. It is fixed if I wrap my assertion in an Ember.run() block. Does anyone know why?
Error: Assertion Failed: You have turned on testing mode, which disabled the run-loop's autorun. You will need to wrap any code with asynchronous side-effects in a run at new Error (native)
Inspect your ember application with the inspector browser plugin, and look in the promises tab.
You'll see there are a large number of promises there, even for an app with minimal code.
This isn't much of an answer, but looking at the promises tab should show that ember handles asyncrony without us necessarily knowing about it.
In ember's blog post about 1.12 release, mentions an example using application.deferReadiness inside an instance initializer. However, it doesn't seem to be working. The first parameter to the initialize function doesn't have a deferReadiness method. Any ideas?
I think it's reasonable to post #tomdale explanation here as an answer.
#tomdale: "It's not possible to defer app readiness in an instance initializer, since by definition instance initializers are only run after the app has finished booting.
Sidebar on the semantics of application booting: "App readiness" (as in, deferReadiness() and advanceReadiness()) refers to whether all of the code for the application has loaded. Once all of the code has loaded, a new instance is created, which is your application.
To restate, the lifecycle of an Ember application running in the browser is:
Ember loads.
You create an Ember.Application instance global (e.g.
App).
At this point, none of your classes have been loaded yet.
As your JavaScript file is evaluated, you register classes on the
application (e.g. App.MyController = Ember.Controller.extend(…);)
Ember waits for DOM ready to ensure that all of your JavaScript
included via <script> tags has loaded.
Initializers are run.
If you need to lazily load code or wait for additional setup, you can call deferReadiness().
Once everything is loaded, you can call advanceReadiness().
At this point, we say that the Application is
ready; in other words, we have told Ember that all of the classes
(components, routes, controllers, etc.) that make up the app are
loaded.
A new instance of the application is created, and instance
initializers are run.
Routing starts and the UI is rendered to the
screen.
If you want to delay showing the UI because there is some runtime setup you need to do (for example, you want to open a WebSocket before the app starts running), the correct solution is to use the beforeModel/model/afterModel hooks in the ApplicationRoute. All of these hooks allow you to return a promise that will prevent child routes from being evaluated until they resolve.
Using deferReadiness() in an initializer is an unfortunate hack that many people have come to rely on. I call it a hack because, unlike the model promise chain in the router, it breaks things like error and loading substates. By blocking rendering in initializers, IMO you are creating a worse experience for users because they will not see a loading or error substate if the promise is slow or rejects, and most of the code I've seen doesn't have any error handling code at all. This leads to apps that can break with just a blank white screen and no indication to the user that something bad has happened."
See also discussion: https://github.com/emberjs/ember.js/issues/11247