I am using AngularJS v1.2.16, got simple animations like fadeIn working with ng-show using the class conventions, but also want to fadeIn (or blink) a given div when a given object of the model changes (info of this object is display inside that div).
Note that my code uses $scope.$apply(); as the source of the change is not AngularJS.
$scope.someObject = newData; // Update of the model.
$scope.$apply(); // Force changes.
Maybe there is a way to force the animation before or after the apply or should this be done in a directive ? Finding information on this is quite confusing due to the changes that occurred on the animation system.
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.
I just recently started tinkering with AngularJs, so my question is fairly basic. For concreteness's sake, let me start with the minimal setting: a page with banner, body and footer. The goal is to make banner and footer stay at the top and bottem of the page (css position: fixed) and the body will fill in the rest.
If I were to use jQuery, I could set position: fixed for body, and listen to window's resize event to determine where I should put my body.
Presumably, I could do the same in AngularJs. But I've read many places that one shouldn't try to manipulate the layout from the code, since it's not in the philosophy of AngularJs. So, what's the best way to achieve this in the AngularJs way? Thanks.
Dynamic layout usually refers to a layout that changes depending upon the current route. Routing is how AngularJS associates a URL with a Controller and data. It becomes an important part of an app once you go beyond just 1 page.
Multiple Views
If you use something like ui-router (http://angular-ui.github.io/ui-router/) it allows you to define views that can have child views.
In your example, the header, body and footer would all be child views of a parent view. Each view would have it's own template, controller and data. When routing changes you can have just one or more of those view change, while the other views remain the same.
Binding Events
You can do all the same event bindings in AngularJS as you can in jQuery. The difference is the life-cycle of those bindings.
If you bind to the click event for a directive using the directive's element, then you don't have to worry about that binding when the directive is destroyed. AngularJS will remove the binding automatically.
When you bind to something like the window.resize event, then you have to be more careful.
link: function($scope, $el, $attrs) {
// this doesn't have to be unbind
$el.bind('click',function(e) {
// do stuff
});
// this has to be unbind on destroy
angular.element($window).bind('resize.mybinding',function(e) {
// do stuff
});
$scope.$on('$destroy',function(){
angular.element($window).unbind('resize.mybinding');
});
});
I've seen a lot of AngularJS source code bind to window.resize when it wasn't necessary. Only you know when it's needed, but sometimes you can get away with just using a watcher.
link: function($scope, $el, $attrs) {
$scope.$watchGroup(function(){
return [$window.innerWidth,$window,innerHeight];
},function(values){
// do stuff
});
});
The above does the same thing as binding. It executes a closure function when the size of the window changes, but the difference is that it's triggered only during digest and not by the window resize event. This can sometimes be more efficient for performance. As the resize is relative to only when the directive is digested.
A lot of AngularJS applications use JavaScript code to manage the layout of an application. How much JavaScript code you use, and why you do it that way is up to you, but keeping layout separated from the JavaScript side has a lot of advantages. It's better to let CSS handle it.
Bootstrap provides a nice plug-in called Affix that does just that.
<div id="banner" data-spy="affix">Fixed Banner</div>
<div>Body</div>
<div id="footer" data-spy="affix">Fixed Footer</div>
More on affix here for example:
http://www.tutorialrepublic.com/twitter-bootstrap-tutorial/bootstrap-affix.php
I am using a directive "slideable" which creates a slideout area and has a toggle. This code that was not written by me but it demonstrates a larger issue for me. When I changing views (most commonly /user/:id type), slideable is a directive used on the template. The directive searches for an element during its link function and binds a click event. The issue is that when I am changing routes and the new view ( same type but different id ) is being loaded the directive is re-binding to the old view. If I stop the browser in chrome during the link then I will see two ng-views on the dom and the issue is it binds to the one that is leaving.
I also have other issues that appear to be related to this phenomenon. Is it normal that the old view would still be on the dom while the new view is being formulated?? Why wouldnt the old-view be destroyed before the new one is rendered? How do I get around this issue in a directive like this?
Thanks.
I am looking to understand conceptually what is happening. I already modified the directive to select the latest view and to appropriately search and bind to the correct element. But I am a bit perplexed as to why there would be a state where both co-exist on the dom.
One definitive reason why the old HTML fragment is briefly present along with the new one is to support animation of transitions from the old to the new. Take a look at the ngView documentation and you'll see an example of an animated transition, and it'll be clear that this is not a bug or a design flaw.
Usually when someone has problems with binding to the right element or element's event, it's because they are selecting the element without limiting the scope of the selector to the HTML fragment being added or updated, or trying to target parts of the DOM outside of the directive. So that's the first place to check, that the directive is doing things right, but like I said we'll need code to check on that.
I am trying to get two multiselect widgets to stay in sync, but am only able to get the behaviour going in one direction.
One widget is on the main page, and the other one is in an angular ui-bootstrap modal. Both multiselect widgets are created using a custom directive. Each instance of the directive is bound to a different controller (MainCtrl and ModalCtrl). The "selected" attribute of each instance of the directive is bound to a scoped variable in their respective controller, which is in turn bound to the same getter method in the Model (getSelectedFilters).
If I change the selection on the widget on the main page, the change is reflected in the widget in the modal panel. However, if I change the selection in the modal panel, the change isn't reflected in the widget on the main page even if the Model has been properly updated (the button "Show currently selected" will show the correct selection even though the widget doesn't). I don't understand the difference at all.
Here is a stripped down plnkr illustrating my problem.
http://plnkr.co/edit/nC5bkGFE4LkYZsaxdjL7?p=preview
I am entirely new to Angular, and would appreciate any input as to why my directive on the main page isn't being updated properly when the data in the model changes.
Version 7 of the plnkr was what I had initially posted.
Basically, calling $apply on $scope.selected whenever the value was changed was not enough to notify the other directive of the change. I also had to setup a $watch:
$scope.$watch('selected', function(newVal, oldVal) {
select2.val(newVal).select2(options);
});
I am now completely unclear as to why the select2 directive in the modal was updating at all without a $watch when I was modifying the select2 directive on the main page. I would love if someone could explain what was going on there! To anyone who might know, go back to version 7 to see what I mean.
The setting
I have Backbone.Marionette.ItemView which renders some content. When the content is rendered I'd like to apply a jQuery plugin which turns part of the view into a container with a scrollbar.
The scrollbar is implemented completely in javascript and upon initialization it has to check the height of the scroll-container as well as that of the content inside the container.
If the content is higher then the container, a scrollbar should be enabled.
The problem
While this all sounds simple, I've ran into a strange problem:
If I initialize my scrollbar plugin directly in the onRender callback it seems to think the .scroll-container element has a height 0 and maxHeight of 0.
If I wrap the initialization code inside a 0ms timeout though, everything works as it should, the .scroll-container element's height property is returned by jQuery correctly and the scrollbar plugin works great.
The code
onRender: function() {
var that = this;
setTimeout(function() {
that.onLayout();
var $scrollContainer = that.$el.find('.scroll-container'),
scrollPane = new ScrollPane($scrollContainer, {
maxHeightProperty: 'maxHeight',
scrollUpButton: false,
scrollDownButton: false
});
}, 0);
},
The question
I'm assuming the problem occurs because the browser didn't finish actually rendering the newly inserted html when the onRender callback is executed.
Is this assumption correct? And if so, is my solution of using a 0ms timeout reliable under normal circumstances?
Since the plugin in question depends on the DOM, onRender won't do what you need. This callback kicks off after the view has been rendered, but there is no guarantee that the view's el has been added to the DOM yet. In fact, you are safe assuming the opposite - that it has not been added yet.
If you're using a Marionette Region to show the view, you can implement an onShow method in your view. This method gets called by the region, after the region has added the view to the DOM. It was implemented specifically to handle this situation.
For a little more info on this, and on working with jQuery plugins in general, see this blog post: http://lostechies.com/derickbailey/2012/02/20/using-jquery-plugins-and-ui-controls-with-backbone/