Let's dive into a classic scenario involving portal/CMS widgets:
- It's uncertain whether or not AngularJS will be present on the page
- Any number of widgets may or may not exist on the page
- Each widget could belong to a specific family, with multiple families potentially overlapping on the same page
- Multiple instances of a single widget could appear on the page
- Different development teams will work on different widget families
The concept of a "family" entails a group of widgets that are connected by data or purpose, interacting and influencing each other's UI. This means multiple families might coexist on one page.
AngularJS typically guides developers towards having one module at the root level of the page, utilizing controllers for individual sections. However, this raises concerns about conflicting influences from teams working on separate families of widgets within the pageApp module.
A manual bootstrap approach appears necessary to target specific parts of the DOM or "partial view" with a designated module.
angular.element(document).ready(function() {
angular.module('myApp', []);
angular.bootstrap(document, ['myApp']);
});
...but there is apprehension regarding potential drawbacks as per the disclaimer
angular.bootstrap will not create modules on the fly. You must create any custom modules before passing them as parameters.
...and it seems that applying multiple modules to the same DOM element isn't feasible? Is that correct?
If assigning multiple modules to one root DOM element isn't possible, what would be the recommended approach?
A pub/sub model could handle intra-family/inter-family communication effectively.
But should every widget be considered a module? If so, would distinct module names need to be dynamically generated for multiple instances of the same widget (e.g., thing1, thing2)?
Not all widgets can serve as controllers, as this would require intermingled families to share the same module.
EDIT 1: (Example) Imagine a page featuring a list widget and a detailed widget relying on xhr-data. These widgets depend on each other but aren't confined to specific locations on the page. Clicking an item in the list alters the detail shown. Two additional widgets on the page have selectors that impact the displayed xhr-data quantity in another widget. Lastly, a standalone accordion widget is present. Widgets may be positioned in a way that doesn't distinctly encapsulate each family within a single HTML node.