-
Notifications
You must be signed in to change notification settings - Fork 27.3k
ng-cloak should also protect against unhandled page initialization errors #8329
Description
AngularJS page load display and error handling is not sufficiently robust because it shows the page load template syntax to the end user on any page initialization error. This appears as a catastrophic error to the end user since all data placeholders using the angle bracket syntax are displayed to the user which destroys the visual appearance of the page. With a small change to when ng-cloak is removed, the AngularJS team could make their templating much more robust by default for developers, QA teams, development managers, and end users.
I'm opening this issue as follow-up issue to issue #2927 to request that that the AngularJS team reconsider that this issue is a higher severity issue. The current implementation makes AngularJS implementations appear to be fragile and error-prone for developers and end users because of the exposure of templating angle bracket syntax on errors by default. Other frameworks don't have this problem. The default should be to not show the angle bracket syntax but the current implementation default of AngularJS is to show the angle bracket client-side templating syntax.
Safe, professional looking error handling defaults are better
I'm requesting that ng-cloak protect against unexpected page initialization errors in addition to page load flicker problems. High quality frameworks should default to 'safe' default behavior. It is harder for me to convince my fellow developers to use AngularJS when they see page failures in AngularJS that make the whole page display look like a fragmented template rather than a well-controlled application. My fellow developers say they don't want to use AngularJS client-side templates because the errors look uglier to the user than other development approaches and frameworks. QA is asking why errors look worse this year in our application because they see the angle bracket syntax sometimes. We get new developers learning AngularJS on our team who haven't learned the workarounds to ng-cloak yet.
Currently even if a developer does everything suggested by the ng-cloak directive documentation such as enclosing their page in ng-cloak and adding the ng-cloak css to ensure that their page is cloaked until page initialization, any unhandled page initialization errors defeat the purpose of their use of ng-cloak and the angle-bracket syntax is displayed to the end user anyway. Developers want ng-cloak to protect their app from displaying the template angle brackets to the end user. To the end user this looks like a completely catastrophic error.
Compile phase ng-cloak removal is too early
Couldn't AngularJS's default be to honor ng-cloak even in the case of page initialization failure so that the page display does not look completely out of control to the end user?
Removing ng-cloak during the compile step is currently really early in the process. This is too early. Couldn't AngularJS wait until later to remove ng-cloak?
ng-cloak's current behavior is described as an AngularJS pitfall
While there are workarounds to the problem, they're listed as pitfalls of AngularJS where the default AngularJS behavior is not good enough: developers must learn the workarounds to have a quality display. Following is an example talking AngularJS pitfalls and about how developers need to learn to workaround the current AngularJS behavior of ng-cloak and angle-bracket syntax:
http://branchandbound.net/blog/web/2013/08/some-angularjs-pitfalls/
Developers can't use ng-cloak so they resort to other directives
In the following StackOverflow discussion, developers must resort to using other directives such as ng-hide because current ng-cloak behavior isn't good enough:
http://stackoverflow.com/questions/19476880/ng-cloak-directive-gets-removed-too-early
They're using tricks like setting ng-hide and ng-show='true' at the same time so that the section won't be displayed until the AngularJS link phase. They are using other tricks like ng-if, ng-include, ng-view as a workarounds as well because ng-cloak just isn't doing what it is really needed for. Developers use ng-cloak to protect against showing the angle-bracket syntax yet the current implementation of ng-cloak allows the angle-brackets to leak through to the end users. Compile phase is just too early to be removing ng-cloak.