lately I have a pretty significant problem with ng-view and ng-if.Suppose there is a dropdown with two elements (element one and element two).The two elements change a property on rootScope.
I have two more items at another location (div-container, container one and two containers). These are displayed by ng-show - container one at element one and container at element two.
As soon as I click the one element one time and the property of the rootScope changes and then I reload the page, the two containers are alternately displayed without that I do something.
I have several watchers, seveleral ng-cloaks and use the routing using ng-view. I would also like to mention that the application is relatively large. Most often, the problem occurs on Android, presumably on iOS.
As soon as I click the one element one time and the property of the
rootScope changes and then I reload the page, the two containers are
alternately displayed without that I do something.
Did you mean the other two containers just show up for a second and then disappear? If that is the case then I think the condition you are providing inside ng-show is true at the loading time so they appear for a while before the condition changes and then they disappear.
You have to make sure the condition for ng-show is initially false.
Related
I have a dropdown element directive to display in essence a styled dropdown list with additional capabilities.
My dropdown controller has a function called openDropdownItems that get's executed when the list should be displayed.
Then I also have another attribute directive called setInViewWhen that provides an expression when the element should be scrolled into view when condition is true.
<x set-in-view-when="something.item === selectedItem">
This is just an example of some X element with my attribute directive applied.
The thing is that I would like my dropdown list items (LIs namely) to have this directive on them so when user navigates over them using a keyboard, it would automatically scroll them in view when they get passed visible viewport. Whether these items are displayed within a scrollable container or as a whole in a list longer than the browser viewport isn't really relevant.
The main idea is for scrolling to follow dropdown list selection. Whether that should scroll the main window.
The problem
I can make my setInViewWhen directive completely independent but that means that I would have to search for the closest scrollable container whenever condition changes on an item. This seems to be quite a bit of processing that I would like to avoid to repeat (I need to traverse the DOM upwards, checking each node's calculated stylesheet property OverflowY + some additional checks.
This basically seems redundant because whenever I get the closest scrolling ancestor all sibling elements with the same directive could reuse the calculation result.
Question 1
How can I share this knowledge between sibling directives? If I was to fire an event I could not know whether receivers are siblings or not without any additional processing.
Question 2
Instead of checking for scrollable container every time when my directive's condition becomes true I could theoretically change dropdown parent's openDropdownItems to first complete it's original execution an then also execute the scrollability check and use the result of it along with my directive's condition.
I can gain access to dropdown's controller in my directive via directive requires property and adjust it in the post-link phase.
But this also means that I couldn't use my directive outside of dropdown which I would like to as it is a generally usable directive I could attach on several elements in my app to scroll elements into view under certain conditions.
What would you suggest how to do this?
To sum up the comments:
For Question 1, there is no direct way for sibling directives to communicate with each other. I usually create a wrapper parent directive to relay the messages.
As per the comments, the condition something.item === selectedItem introduces a watch; for a list of select items this can be many watches and detrimental to performance. Even if it doesn't occur now, it is a trap and someone may be lured into using this for a long list of items in the future. I would rather have a single watch in the parent of the <li>s and add the "scroll into view" logic there.
With the previous point in mind, you could still have a standalone setInViewWhen directive (seems useful) and have the controller of your X-select replacement directive share code with it. E.g.:
a service containing the common functionality,
an angular value containing a base class (Typescript or JS) and have the controller of both the setInViewWhen and X directives extend from it
or any other solution that is convenient for your case
Related to Question 2: The children could require their parent and change a method in it (this technique is even endorsed by Angular, see ng-model and custom controls where they override ngModel.$render() by replacing it). If you do that however, there would be many children changing the method of the parent, which could lead to a mess.
Issue: I have an accessibility issue that I am struggling with. I have an angular web application. A page loading spinner/indicator is shown when content is loading. And when the page content has loaded the spinner is hidden. This "div" is never removed from DOM.
Content of the loading div are not read (by NVDAor jaws) when the loading div is shown.
<div class='loading' aria-live='polite' aria-label='Do not refresh the page' tabindex="-1">Do not refresh the page</div>
I wouldn't like to change the structure of the application but work around using 'aria tags' to resolve this, just wondering if I will have to do anything more to make aria-live work?
Updated (27/July/2016)
Further clarification: I am not removing the content from DOM but using css to show/hide content (display: none to display: block and vice versa)
aria-live triggers screen readers when an element with aria-live (or text within an element with aria-live) is added or removed from the DOM. In contrast, when you unhide a hidden element, neither elements nor text are added or removed from the DOM, so the element's aria-live property doesn’t come into play.
To get screen readers to announce “Do not refresh the page”, either of these options should do the trick:
You can create the <div class='loading' aria-live='polite'> element and its text content from scratch and then add that element to the DOM.
Or you can start with an empty <div class='loading' aria-live='polite'> element and then populate its text content.
A few other tidbits:
As long as the text inside the element is what you want to be read aloud, you can omit the element’s aria-label='Do not refresh the page' attribute.
For icing on the cake, it can’t hurt to include a role attribute on the div that has aria-live. If you’re not sure which role to use, go with role="status"—that’s a pretty safe bet.
When or if the page is at a state where you no longer need to display "Do not refresh the page”, be sure to reverse the steps above. (That is, if you went with the first option and you added the whole element to the DOM, remove that entire element from the DOM. Or if you went with the second option and you populated the element’s text content, clear out the element’s text content.)
There are several issues with dynamically added or shown/hidden live-region.
Firstly a quote from MDN - ARIA live regions:
Simply including an aria-live attribute or a specialized live region role (such as role="alert") in the initial markup as it's loaded will have no effect.
Dynamically adding an element with an aria-live attribute or specialized role to the document also won't result in any announcement by assistive technologies (as, at that point, the browser/assistive technologies are not aware of the live region yet, so cannot monitor it for changes).
Always make sure that the live region is present in the document first, and only then dynamically add/change any content.
From my personal experience, even if a live regoin exists in the DOM on page load if you use show/hide then NVDA also has a bug which requires a small delay before a text update in a live region after it was shown initially. Apparently because the region didn't exist when the first text was added, so this isn't an "update". Regarding the timeout, you'd need to set it to something greater than the browser's refresh tick. I use 100ms. Disclaimer: I am strongly against such workarounds to make up for the issues with screen readers or browsers but it might be useful for someone in some cases.
I'm using Angular 2 - RC3.
My problem is, I have an item which is shown or hidden using a *ngIf.
When the item is getting shown or hidden I want to apply an animation.
I'am able to apply an animation when the item first shows simply by adding a class. But the problem is when it's getting removed, the item gets removed from the screen before the animation can start/finish.
I know you can overcome this by setting a timer to delay removing action so that the animation can finish. But I don't want to put timers everywhere I need this functionality.
Is there an easier way in Angular to achieve this?
I don't want to use JQuery is either.
Use [hidden] directive on your element, as it does not prevent the element from rendering like *ngIf does.
[hidden] mean it takes up space in your DOM document but it's display is set to : none !important.
*ngIf on the other hand removes the element from the DOM completly
Parts of a view of my Angular app are not rendered correctly - sometimes.
The behaviour is very strange, because this happens only sometimes and for certain items only.
My app consists of a service, a controller and a view. The service communicates with a backend and provides data for the controller. The controller is watching for certain data. With data-binding the values are shown in the view.
In general the shown values are correctly - I can see it in the logs. But sometimes when the a value has changed, not all depended view elements get updated - but some of them.
I mean a DIV shows the text of a certain value with ng-bind.
Moreover another DIV is visible or hidden with ng-if and depends on the same value of the same controller.
Sometimes I have the behaviour that the visibility of the button is switch correctly but the text of the other DIV does not (shows the old text).
It switches only if I scroll the view (or touch it on mobile device). Is this the next digest cycle maybe?
Otherwhile everything is rendered complete correctly!
I have already tried it with a directive and without one, with the 'controllerAs' syntax and without, with Angular 1.2 and 1.3 - but everytime the same result.
Has anyone further ideas to this behaviour?
Can this be a rendering problem?
Question: Is there a bug in angular-strap? Or do I misunderstand how Angular works, and this is expected?
I've created a plunker to demonstrate the behavior.
What I want:
I want to show a different tooltip for each item in an ng-repeat.
Behavior I'm seeing:
Under certain conditions, the tooltip content is not properly inserted into the content template. Thus you only see the template, and not the content template or content itself.
Conditions:
When the page is first loaded, the tooltips work as expected.
When an item is added to the ng-repeat, its tooltip does not populate the template's content section.
If the page starts off with zero items in the ng-repeat, the tooltip in the first item added will work as expected. Items added after that will exhibit the problem.
Regardless of how many items the ng-repeat starts with, any removal of any item from it will make all items added in the future not have working tooltips.
Thoughts: If I boil it down, the "first load" works fine. After that, it doesn't. I'd guess that what happens is that there's a compilation step happening after the first round of adding items into ng-repeat. At that point, the angular-strap tooltip code sees the directive attributes, and sets up those tooltips and the content template. Subsequent changes to the ng-repeat are missed by angular-strap (even though I can see in the console that the call from bs-popover=tooltip(item) does actually run each time the ng-repeat list is updated). But I'm still stumped and wondering if this is behavior I can get around.
How do I allow dynamic tooltips in items added to an ng-repeat?
This seems to work in _popover.html
<div class="popover-content">{{content}}</div>
That is using {{ }} instead of ng-bind...works very odd.
Upon further investigation... Its probably happening somewhere around here:
https://github.com/mgcrea/angular-strap/blob/master/src/tooltip/tooltip.js#L83
Though I don't know where/how/what yet.
Update
So the bug (in Angular-Strap) is with caching your template. Initial retrieval (via http) works fine. But it caches them as an array, and upon retrieval from cache (subsequent additions) it gets an array. Which doesn't have a .data property so your template is empty, and your ng-bind is removed..