"AngularJS for the front end allows someone who sucks at front end work to be able to produce some pretty useful interfaces". That's actually a nice way to explain its success, for better and for worst. Spot on, IMO.
>Enter problem two. What happens when my project has heaps of controllers/services etc… I now have directories that could have a lot of files and none of them are particularly easy to find.
My team uses Angular 1.4.7 for a very large project (hundreds of JS files, dozens of views/controllers/services). We have in our JS folder a services folder, controllers, directives, etc. No subfolders except in our directives folder which has some directives which are only applicable to a specific area of the application. Services by convention are just the name of the topic at hand, no "service" suffix (i.e. alert.js, user.js). We have had no issues as far as file navigation goes. I grant that convenience to our development environment. We run a primarily .NET stack and leverage Visual Studio 2015 so the "CTRL + comma" keyboard shortcut makes it very easy to work with these relatively large folders. My main point being I think the development environment plays a very large role in whether structure A or structure B will be more optimal for your team. If a CLI were going to be our means of navigation, this structure would be much more challenging to work with and I don't have a good suggestion for that circumstance.
Both in our Angular and React codebases, we group things by functionality. Ideally, we should be able to take a folder (and its subfolders) and make them a separate npm-package. In the past, we have actually done so successfully, and can share and reuse these modules through our internal npm (Nexus).
We've adopted this style guide at my work-place. I created a few AngularJS apps before running into this great resource and every thing it proposes matches my experiences and intuition from poking and prodding the library.
What would you name the controller in the code in that case? It's annoying to have mismatch between a file's content and the name, and having all controllers in the app be named "controller" makes debugging hard.
From back-end to front-end, my experience both from my own work and other's code is that file names and classes or objects should match. FooController defined by FooController.js or FooController.java or whatever your language and extensions might be.
would all be in different folders, one for controllers, one for services one for directives etc. if you have multiple tabs open in your ide like Webstorm you'd only see foo.js three times over, if you did not prefix it, and be hard pressed to know which is which at first glance.
With that said Angular 1 is dead long live Angular 2 :)
Yes, you should have separate folders for controllers directives etc, when you are grouping by features, under the feature. Otherwise good luck telling where everything is, when you have something beyond a trivial app...
I'm not suggesting putting all components in component folder and all services in services folder.
We have something far beyond a trivial app, and still never have folders for controllers etc. If a feature becomes big enough that this is needed, e.g. more than a few components, they are split up and grouped in several subfolders.
That is why they are called style guides and are opinions. No need to go telling someone they are wrong simply because you do not see the benefit to it...
I hope "somebody" forks Angular 1. The 2 way binding (ng-model) makes CRUD apps very simple to write, even if digest/watch type operations are somewhat slow. As far as I can tell, the ng-model feature is OUT of Angular 2, and some kind of React style event communication must be set up instead.
I don't know React yet, but Angular 2 sounds like they are chasing the same design goals: be efficient at gluing huge mounds of similar crap to a never ending page (e.g. - a la Facebook). I am more interested in quickly grinding out code for huge CRUD forms with a large number of distinct fields.
Yes both are ways to deal with single page applications...
2 way data-binding is still in Angular2, as well as oneWay Binding to the input and one way binding from output. I've heard others make the claim ng-model and 2 way binding are gone, which is wrong.
https://egghead.io/lessons/angular-2-using-ng-model-for-two-...
There are giant performance benefits on the horizon with Angular2 in terms of server side rendering with Angular Universal and state management with ngrx/store.
In Angular2 http is handled as an observable, no longer a promise, so there is a difference in syntax but that falls in line with ES7 format
Thanks for the update. As far as I could piece together (admittedly dubious connections), ngModel was re-implemented in the Jan 2016 release of Angular 2??? ("Angular 2.0.1 beta" from a Stack Overflow discussion assumed to mean 2.0.0-beta.1 on https://code.angularjs.org/)
Sounds like somebody beat some sense into the Angular 2 team - "don't remove the single feature that differentiates your library and makes prototyping an app easy"
Now if I can only find examples in good old Javascript, instead of fugly, Java-esque, Typescript.
Re: types/Typescript - loved this quote:
"Better type-checks interestingly found only just a few bugs"
Rant for another day: insisting on static typing, but ignoring the mayhem caused by operators and operator precedence (to say nothing of user created operators)
Two way binding is back in, and almost all perf benchmarks out there of Angular 2 is much faster than React. It also avoids some of the internal flaws present in current React with the coupling of the DOM layer in the library.
The two way binding works by automatically updating, but also allowing you to hook into the outputs through a template convention (if bound via [(foo)], one can define a fooChange handler to hook into updates).
> When almost every class has the same prefix. IE, when a user clicks on the button, a SmurfAccountView passes a SmurfAccountDTO to the SmurfAccountController. The SmurfID is used to fetch a SmurfOrderHistory which is passed to the SmurfHistoryMatch before forwarding to either SmurfHistoryReviewView or SmurfHistoryReportingView. If a SmurfErrorEvent occurs it is logged by SmurfErrorLogger to ${app}/smurf/log/smurf/smurflog.log
No, that isn't redundant, and it isn't a "tooling" problem. There are too many places where having 52 "controller.js" files in a project could be a problem, beyond the editor/IDE. And I can't speak for everyone, but I don't like folder names in my tabs. Also, while in the simplistic examples, the folder name always matches the file names, it doesn't have to (see the John Papa style guide example).
I'm working on an Angular app with a Java backend, so much of the directory structure is dictated by Maven. Also, for what it's worth, we don't have a "single page app" (with multiple controllers or whatever). We have a "small number of pages app". This allows for limiting the scope of what is done in each page a bit. Also, while we are not constantly reloading pages like the legacy app this replaces, we occasionally load a new page, which hopefully deals with any resource leaks our imperfect code may have had.
That said, within the source directory for client side web files, we have the following:
* html/ - app pages (a small number of files) are within this directory.
-- html/help/ - sundry help pages put together by analysts are stored here.
* css/ - probably overkill, but the main css file is here, and, so far, an alternate "skin" for a subsystem of the app.
* js/ - empty in the source, but we do concatenate js files and place them in this spot in the final deployment package (.war file)
-- js/<<app name>>/ - in house scripts. There is a (short-ish) controller script for each page, and perhaps 6 to 10 shared utility scripts. The utility scripts tend to be somewhat long, rather than having hundreds of files, which really bothers me. E.g. - "tags.js" has the directives ("tag libraries", although there are a few custom attributes as well); rest.js is a wrapper around $http and some error / message handling code that does communication with the server.
I can't stand the directory structure, which I attribute to JEE historically, that has hundreds (thousands?) of files, and grossly redundant "MaryHartman/MaryHartman" / "Smurf" / "Bat" naming style (directory bat contains BatMobile.src; BatPhone.src; BatBelt.src; BatShit.src and so on)
Also, much of what is in the utility files are just single functions (within a namespace object), rather than classes. Currying goes a long way to inject dependencies into a chunk of code, rather than making a bunch of one-trick-pony (single action method) classes.
Perhaps you're just trying to make a joke - but what's so odd about it? He means that he's been paid to do it for 6-7 years, and suggests that he was doing it unpaid (hobby, school) for longer.
In all our new projects we've started using redux with a smart + dumb component architecture and have had some great success. Redux makes keeping track of everything that's going on in large apps much easier. It also allows for only needing a few "smart" / container components that actually know about redux and global application state that then pass down only what's needed to simpler / "dumb" components. We like this approach so much we've even built out various starter projects.
Link to angular 2 project: https://github.com/rangle/angular2-redux-starter
Link to angular 1 project: https://github.com/rangle/angular-redux-starter
I go a minor step further, and pull out the components/actions/reducer by feature... additionally I'll separate out api into a separate file, for interactions with outside pieces (cors/xhr, etc), this way action creators don't have the logic for xhr requests (fetch or axios), and it's pretty clean... I use redux-thunk and redux-actions too.
Even for angular, it's a pretty nice workflow... I really don't care as much for angular as react. When the workflow is mostly the same, the quirkiness of angular (1 & 2) just stand out more imho.
This way features can be N layers deep, a given feature may not have all of those pieces, some may be data only, some may have actions that are called from other features... in the end, the data/controls etc are closer to the feature that binds them. Api is to abstract any foreign system integration (api calls), where actions (action creators) may use it, and the reducers manage the result... Redux workflow, variance on structure.
Tends to work pretty well that way. Actions/reducers may listen/dispatch those defined under other features... again, it's the shape of the data and application that defines these features and their structure.
35 comments
[ 3.1 ms ] story [ 35.2 ms ] threadMy team uses Angular 1.4.7 for a very large project (hundreds of JS files, dozens of views/controllers/services). We have in our JS folder a services folder, controllers, directives, etc. No subfolders except in our directives folder which has some directives which are only applicable to a specific area of the application. Services by convention are just the name of the topic at hand, no "service" suffix (i.e. alert.js, user.js). We have had no issues as far as file navigation goes. I grant that convenience to our development environment. We run a primarily .NET stack and leverage Visual Studio 2015 so the "CTRL + comma" keyboard shortcut makes it very easy to work with these relatively large folders. My main point being I think the development environment plays a very large role in whether structure A or structure B will be more optimal for your team. If a CLI were going to be our means of navigation, this structure would be much more challenging to work with and I don't have a good suggestion for that circumstance.
https://github.com/johnpapa/angular-styleguide/blob/master/a...
I sense a weakness in someone's editor/IDE. Personally I'd call it controller.js and expect my tools to not make that problemmatic
foo.service.js
foo.directive.js
would all be in different folders, one for controllers, one for services one for directives etc. if you have multiple tabs open in your ide like Webstorm you'd only see foo.js three times over, if you did not prefix it, and be hard pressed to know which is which at first glance.
With that said Angular 1 is dead long live Angular 2 :)
I'm not suggesting putting all components in component folder and all services in services folder.
https://egghead.io/lessons/angular-2-organizing-angular-2-pr...
I hope "somebody" forks Angular 1. The 2 way binding (ng-model) makes CRUD apps very simple to write, even if digest/watch type operations are somewhat slow. As far as I can tell, the ng-model feature is OUT of Angular 2, and some kind of React style event communication must be set up instead.
I don't know React yet, but Angular 2 sounds like they are chasing the same design goals: be efficient at gluing huge mounds of similar crap to a never ending page (e.g. - a la Facebook). I am more interested in quickly grinding out code for huge CRUD forms with a large number of distinct fields.
2 way data-binding is still in Angular2, as well as oneWay Binding to the input and one way binding from output. I've heard others make the claim ng-model and 2 way binding are gone, which is wrong. https://egghead.io/lessons/angular-2-using-ng-model-for-two-...
There are giant performance benefits on the horizon with Angular2 in terms of server side rendering with Angular Universal and state management with ngrx/store.
In Angular2 http is handled as an observable, no longer a promise, so there is a difference in syntax but that falls in line with ES7 format
Sounds like somebody beat some sense into the Angular 2 team - "don't remove the single feature that differentiates your library and makes prototyping an app easy"
Now if I can only find examples in good old Javascript, instead of fugly, Java-esque, Typescript.
Re: types/Typescript - loved this quote:
"Better type-checks interestingly found only just a few bugs"
https://jaxenter.com/angularjs-interview-angular-2-typescrip...
Rant for another day: insisting on static typing, but ignoring the mayhem caused by operators and operator precedence (to say nothing of user created operators)
The two way binding works by automatically updating, but also allowing you to hook into the outputs through a template convention (if bound via [(foo)], one can define a fooChange handler to hook into updates).
Me neither.
> When almost every class has the same prefix. IE, when a user clicks on the button, a SmurfAccountView passes a SmurfAccountDTO to the SmurfAccountController. The SmurfID is used to fetch a SmurfOrderHistory which is passed to the SmurfHistoryMatch before forwarding to either SmurfHistoryReviewView or SmurfHistoryReportingView. If a SmurfErrorEvent occurs it is logged by SmurfErrorLogger to ${app}/smurf/log/smurf/smurflog.log
That said, within the source directory for client side web files, we have the following:
* html/ - app pages (a small number of files) are within this directory.
-- html/help/ - sundry help pages put together by analysts are stored here.
* css/ - probably overkill, but the main css file is here, and, so far, an alternate "skin" for a subsystem of the app.
* js/ - empty in the source, but we do concatenate js files and place them in this spot in the final deployment package (.war file)
-- js/lib/ - 3rd party library scripts (e.g. - jQuery, Angular, moment, Ramda ...)
-- js/<<app name>>/ - in house scripts. There is a (short-ish) controller script for each page, and perhaps 6 to 10 shared utility scripts. The utility scripts tend to be somewhat long, rather than having hundreds of files, which really bothers me. E.g. - "tags.js" has the directives ("tag libraries", although there are a few custom attributes as well); rest.js is a wrapper around $http and some error / message handling code that does communication with the server.
I can't stand the directory structure, which I attribute to JEE historically, that has hundreds (thousands?) of files, and grossly redundant "MaryHartman/MaryHartman" / "Smurf" / "Bat" naming style (directory bat contains BatMobile.src; BatPhone.src; BatBelt.src; BatShit.src and so on)
Also, much of what is in the utility files are just single functions (within a namespace object), rather than classes. Currying goes a long way to inject dependencies into a chunk of code, rather than making a bunch of one-trick-pony (single action method) classes.
This is an odd statement to me. If you are in tech, do you count how many years you've been programming professionally?
I can't, and honestly I don't know if I'm programming professionally in my daily job.
Even for angular, it's a pretty nice workflow... I really don't care as much for angular as react. When the workflow is mostly the same, the quirkiness of angular (1 & 2) just stand out more imho.
Tends to work pretty well that way. Actions/reducers may listen/dispatch those defined under other features... again, it's the shape of the data and application that defines these features and their structure.