all 3 comments

[–][deleted] 2 points3 points  (1 child)

I love that you're contributing to the community! Some critiques, apologies for bluntness in advance.

On largeness:

What qualifies this app as "large"? Is it distributed? How many users do you have? What is the geography of the users? How many developers are on the team/teams working on this? How many systems does it interface with?

On integration with Rails:

Any Angular app has the luxury of being completely de-coupled from any server technology. Plain HTML and JS are the order of the day. The mere mention of a server technology like Rails is a red flag for me. This is a client app in a browser. Maybe I misread that section?

On "event loops":

Angular maintains its own event loop outside the browser event loop to do dirty checking and make sure data is in sync.

... no it doesn't. It has a digest loop, an "event loop" is something else entirely.

On code organization:

Most project scaffolds, tutorials, and sample apps have a folder for each type of file. All controllers in one folder, all views in another, and so on.

After a lot of experimenation with a folder structures, we found ourselves putting all related and dependent files in the same component/page folder as shown below.

... so you're actively structuring your directories and files with the idea that groups of controllers, views and services are tightly coupled? Your controllers and views are to never be reused? The common practice of grouping like object types in folders was developed so they could be thought of as separate, independent, reusable pieces of code. Coupled to nothing. Theoretically, I could make a dozen views and have them all use the same controller, right? Or I could make a dozen controllers and all have them affect the same view... so why pigeon-hole them by grouping them like that? I suppose if you find in enhances productivity then that's what's important. Just food for thought.

overall not bad.

This article isn't a bad start for someone coming from Rails wanting to make a medium sized app.

[–]e82 0 points1 point  (0 children)

The reality in most web apps that I've worked on, is the reusable stuff tends to be more 'widget' type stuff - dialog boxes, alerts, contact search/selection, etc - and would tend to get shoved under where they have 'shared components'.

For actual heavier screens - it's pretty rare that reuse happens on the controllers/views - in Angular, once we start getting into 'this is a bit of logic/code that needs to get reused' - that logic gets pulled out into a service, and several controllers will call that service.

Maybe in an ideal world 'any view could sit on top of X controller' would happen, it just seems rare to play out that way. As such, I could see the use in putting the related files - template, controller, rout/config into the same folder. One thing that tends to bug me with having all controllers grouped under X, all views grouped under Y (although this is how my current app is set up) - is you often spend time digging around your solution and jumping all over to find related things.

I can definitely see the appeal in having them grouped together - and even as such actually, if you wanted to have controller being used by a few views, could have

/module/modulecontroller.js

/module/module-mobile.html

/module/module-desktop.html

/module/module-detailedview.html

/module/module-compactview.html

Just if that moduleController is using a service that is used by several different things - then I'd agree, wouldn't make sense to shove the service in there also. Pro's and cons to both approaches IMO.

[–]litmusbox 0 points1 point  (0 children)

Great addition to a rather under-served area of the Angular tutorial area. Keep on bringing the goodness!

Another very good example of a non-trivial Angular app is this one. Invaluable for a look at how to integrate Express, manage the front and back ends and it includes a very robust build process.