[OPEN-ILS-DEV] Web Client fixes and AngularJS Best Practices

Galen Charlton gmc at equinoxinitiative.org
Fri Jun 2 14:53:08 EDT 2017


Hi,

On Fri, Jun 2, 2017 at 1:48 PM, Boyer, Jason A <JBoyer at library.in.gov> wrote:
> To avoid being surprised by this there is a semi-official best practice of
> always having a '.' in your ng-model directives (mentioned in the above
> link). ([] also works because a JS array is an instance of an Array object)
> So the above example would work fine if it were <div ng-if="showme"><input
> type="checkbox" ng-model="uiState.enabled"/></div> instead.

Thanks for the clear description of the problem and its solution.

> SO, rather than fix these on a case by case basis I thought I'd do two
> things: 1, ask if there are strong opinions for / against wrapping ALL
> variables used in an ng-model in an enclosing object like uiState or
> similar, and 2, ask for some help in either transitioning everything over to
> that OR at least fixing all of this list of 72 that are contained within a
> directive that creates a child scope (it's not just ng-if!).

I don't think we can avoid looking at them on a case-by-case basis
(e.g., there are a few instances of ng-model="ngModel" that I don't
think can just be wrapped, but I do agree that we should avoid passing
primitives in via ng-model and that we should make an effort to get
rid of that pattern.

I suggest that you open a metabug in LP for this, include the results
of a current grep of ones that should be looked at, and do a pass to
see if you find ones that have user-visible consequences, as those
should be prioritized.

I note that the -B flag to grep (e.g., git grep -B3 -P
'ng-model="[a-zA-Z_]+"' ) can help identify cases where ng-if or other
scope-creating directives are in play.

Regards,

Galen
-- 
Galen Charlton
Infrastructure and Added Services Manager
Equinox Open Library Initiative
phone:  1-877-OPEN-ILS (673-6457)
email:  gmc at equinoxInitiative.org
web:  https://equinoxInitiative.org
direct: +1 770-709-5581
cell:   +1 404-984-4366


More information about the Open-ils-dev mailing list