-
Notifications
You must be signed in to change notification settings - Fork 6.7k
Tab initial selection #747
Comments
@ajoslin I think I've fixed most of the bugs for 0.5.0 and just want to review datepicker changes before cutting the release. Would be awesome if you could have a look at this one - I had a quick look and it is still reproducible with the latest master. |
@bsr203 I also got the same problem in my project. And I fix it locally. Please check the diff of https://github.com/raykin/bootstrap/commit/97f6f64163a7e93120adba198f80fd882f29ac6d and update your local code. scope.$parent.$watch(getActive, function updateActive(value) {
scope.active = !!value;
});
scope.$watch('active', function(active) {
setActive(scope.$parent, active);
if (active) {
// .... the above watch are triggered by tabsetCtrl.addTab(scope, true);
// it finally trigger
angular.forEach(tabs, function(tab) {
tab.active = false;
}); my fix is add a check to stop the trigger when compile the tab directive. |
- Avoid re-initializing `tab.active` - `setActive` only when all `tab.active` are set up (on the next digest cycle) Before I go to explain, there are up to two expressions that indicate whether a tab is active: 1. `active` variable in the isolate scope of the tab directive 2. The expression from the active attribute (`attrs.active`) if it is set, I'll call this `getActive`, as that's the variable that refers to it. During initial linking (adding of tabs), the `active` variable in the tab's isolate scope tracks the active tab. When the first tab is added, it's `active` is set to true since there's no way to know if subsequent tabs are active since they haven't been added yet. As such, at this point, it is not meaningful to set assign the `getActive` with the value of `active`. At least not until all the tabs have been added. Hence, a good time would be to wait until the next $digest cycle. A watcher is called asynchronously after initialization even if there is no change on the expression's value. As such, we can leave that to the watcher for the `active` expression to initialize getActive by calling setActive during its initlization cycle. However, there is a chance (if the $digest cycles and planets align...) that the `active` variable gets initialized a second time using the `getActive` (in the watcher for `getActive`). Since we're already setting `active` to `getActive`, and the `active` variable should now be carrying the *truth*. Avoid this re-initialization. --- This fix is ugly because the logic for the two-way binding of `active` and the `getActive` is complex. Consider refactoring the implementation for maintaining the two-way binding (see ngModel for inspiration). Fixes angular-ui#747.
Closes #834, Fixes #747 - Avoid re-initializing `tab.active` - `setActive` only when all `tab.active` are set up (on the next digest cycle) Before I go to explain, there are up to two expressions that indicate whether a tab is active: 1. `active` variable in the isolate scope of the tab directive 2. The expression from the active attribute (`attrs.active`) if it is set, I'll call this `getActive`, as that's the variable that refers to it. During initial linking (adding of tabs), the `active` variable in the tab's isolate scope tracks the active tab. When the first tab is added, it's `active` is set to true since there's no way to know if subsequent tabs are active since they haven't been added yet. As such, at this point, it is not meaningful to set assign the `getActive` with the value of `active`. At least not until all the tabs have been added. Hence, a good time would be to wait until the next $digest cycle. A watcher is called asynchronously after initialization even if there is no change on the expression's value. As such, we can leave that to the watcher for the `active` expression to initialize getActive by calling setActive during its initlization cycle. However, there is a chance (if the $digest cycles and planets align...) that the `active` variable gets initialized a second time using the `getActive` (in the watcher for `getActive`). Since we're already setting `active` to `getActive`, and the `active` variable should now be carrying the *truth*. Avoid this re-initialization.
Watch the allowClear attribute for changes
Please find the plnkr
http://plnkr.co/edit/RCVFji2Upl4VRAoiAcZE?p=preview
I do my setting as (all static tabs)
But, something overrides it, and the first tab become selected by default.
The text was updated successfully, but these errors were encountered: