search

angular-ui / AngularJS-StyleGuide

Example of scalable architecture for my NG-Conf 2014 talk
http://www.youtube.com/watch?v=Iw-3qgG_ipU
284 stars 53 forks source link

A 'involved' linter ? Even for 'architectural' aspects #31

Closed fabm22 closed 8 years ago

fabm22 commented 8 years ago

For example for the last advice :

Use the object to manage data state Instead of putting heavy load on view state flags that describe how things should look, use grammar that describes the verb-like state of the data or action itself. This can then be repurposed in multiple ways in in the view as to the visual representation, and is not tied to visual information. Instead of $scope.showSpinner or $scope.loading use task.uploading or project.saving which could be rendered as a spinner, form, panel, whatever. The point is the state flag is agnostic about the visual implementation.

Could we imagine a linter through regexps which would 'assert', check, that in a $stateProvider's $state declaration there would be a check for data entries (or/and _resolve_s ? Not sure I'm sure about whether one or other) with values suffixed with some typical keywords (possibly delcared in a whitelist), as there are not finally that many possibilites when you think about it ( rendering, editing, uploading, loading, saving, persisting )... We could even assume all $states regarding a feature (ie. = a module) would typically be declared in the same physical file, letting the checker find the _data_s/_resolve_s chain..

Not sure.. Is it looking too hard in it ? The idea would be to tend to something like a typical "blueprint" of the use of $states and architecture of an app through those.

ProLoser commented 8 years ago

I'm a little confused what you're suggesting. You can wrap $stateProvider.state in your own function and do whatever stuff you want (such as access controllers/views by some sort of convention) but I have been happy explicitly spelling out almost everything I put into my state definitions and have not really needed more 'automagic'.

Also, although you always start off with what seems like a basic implementation, you ALWAYS inevitably end up refactoring. Just try to get some reuse out of your templates and make your controllers edit/add agnostic and you should find there is very little non-dry code.