0

I remember reading back that tables are bad, there should be separation between logic, style, and data. And this allows website to be maintained and easy to update.

However, with angular logic part and html part is completely mixed everything is interconnected. And if you want to understand what's happening then you have to follow JavaScript file and html file to figure out how it all works.

I understand for small things it's very useful but for things that aren't just widgets, how is it a good practice. Maybe I am missing something?

Muhammad Umer
  • 17,263
  • 19
  • 97
  • 168
  • It's the way that angular separates the _kind_ of logic being done into different pieces. View logic goes in controllers. Server/data logic goes into services/providers. Miscellaneous logic can end up in directives. – ryanyuyu Jun 30 '15 at 18:23
  • Doesn't it get converted into mess the bigger the application is – Muhammad Umer Jun 30 '15 at 18:25
  • Not really. Just make sure that your controllers and directives are well-encapsulated and have a single responsibility. Then you'll avoid code bloat and be able to find everything. – ryanyuyu Jun 30 '15 at 18:31

2 Answers2

1

Not a programming question, but I feel it warrants a response nonetheless.

Angular can be used for good, loosely-coupled & individually testable code, or bad, tightly-coupled hard-to-test-in-isolation code. There's nothing inherent to Angular that requires one or the other; it's up to the developer to architect things so only those parts that should depend on each other, do.

For example, controllers should be tightly coupled to their templates/views. However, they should not be tightly coupled to the business logic that populates the view in general; hence we have services to abstract that part away.

Also, reusable components should be made into directives & their code not repeated. This makes code more DRY, which results in more maintainable & testable code.

That said, the extent to which code needs to be abstracted depends on the size of the project, its expected lifecycle, deadlines, etc... But, there isn't anything inherent to Angular that results in poor separation of concerns, and plenty of constructs to facilitate it.

UPDATE

There's already a question on how to structure large Angular applications which provides advice on how to implement some of the above in practice.

There's also a style & best practices guide provided by the Angular team with more practical advice (linked from the above question).

UPDATE 2

Right from the Angular unit-testing page, which summarizes the above in 2 sentences:

With great power comes great responsibility

Angular is written with testability in mind, but it still requires that you do the right thing. We tried to make the right thing easy, but if you ignore these guidelines you may end up with an untestable application.

Community
  • 1
  • 1
tavnab
  • 2,594
  • 1
  • 19
  • 26
0

(First of all a little dementi for the example you've provided: tables are not bad. They are only bad if one is using them achieve a layout affect rather than displaying tabular data (in what other markup would you like to show it?))

AngularJS concept of using html in more extensive way comes from realisation that modern webapps are something much more than "documents". The traditional HTML is best suited for documents - blog posts, articles, typical websites etc. When we're talking about apps, we think "widgets", a lot of dynamic logic and in that context using z html as some kind of basic scaffoldig (that we have to carefully look after to work "even if user has javascript off" which in many cases just doesn't make sense) becomes artificial and not very helpful.

Also, directives promote something called declarative programming, and it gives us more helpful separation: we can separate the intent from implementation.

Tomek Sułkowski
  • 7,081
  • 2
  • 17
  • 15