question about directives

[boneskull]

By chance I wound up subscribed to this repo, so I finally clicked on the GitHub mails to see what it was.

Seems like an idea that should replace just about every "AngularJS seed" project out there. Makes me wish I could just npm unpublish generator-angular-* --force. Anyway, question:

A lot of people will create what I refer to as 'one-off' directives. They should usually just be sub-states. If you create directives that are specific to your app's business logic, and aren't focused on purely UI visual implementation (regardless of data, application, etc) then you are too tightly coupling your business logic to your view. You are making it more difficult to quickly refactor your view or view structure. You have to track down where business logic is being executed or modified in multiple places. > You start keeping track of data state and lifecycle and implementing things like events and streams because your view lifecycle isn't consistent with your data lifecycle.
Instead, 0 business logic in views. Rendering logic in views only. Publicly, reusable, agnostic, unopinionated, highly versatile/reusable view logic.

If you're keeping all of your business logic where it should be, what is the problem with one-off directives? I tend to use them simply to get isolated scopes (and deter developers from using the scope hierarchy) and completely eschew .controller() controllers altogether.

If you're buying what I'm selling here, perhaps changing this line:

If you can't open-source your directives, they probably shouldn't exist

To something like:

Keep your godawful business logic out of directives too

Granted, many directives I write do get open-sourced, but others are app-specific, biz-logic-less one-offs which just control a handful of widgets. Technically reusable, but nobody would want them.

[boneskull]

@ProLoser Honestly, this is great work. Bravo!

[ProLoser]

@boneskull actually I'm hoping the rest of the team can bring this in line with like more reasonable guidelines as I tried to mostly be inflammatory lol.

Anywho, yeah the whole 'no directives' is a bit extreme, but I feel one of the big problems with Angular today is people do not design around composability. I have, however, joined teams that have a god-awful number of directives, and it's kind of a mess since you're diving through layer after layer of directives, and it becomes impossible to track down the source of data.

[boneskull]

I have, however, joined teams that have a god-awful number of directives

This can happen for sure. Perhaps convention could be helpful here.

[ProLoser]

I realize this is a year old, but what I had really been pushing for all that time ago was composeable directives vs configureable ones. A lot of people will create mega-directives that are super specific in implementation nature, and then they add more and more options. They then do this ad nauseam and it's very annoying.

Think about it like Bootstrap, instead of making widgets that are highly specific to their implementation, they give you basic building blocks that can be composed together in larger, more complex structures. The negative side is it takes a little longer to bootstrap your app because of the initial extra lines of code. The positive side is refactoring is ridiculously easier (especially when you start remembering most of the structures off the top of your head) and they are heavily reusable and versatile, meaning you're very rarely sunsetting sections of code.

I prefer to have people write more HTML using smaller, more reusable directives (and placing a lot of implementation-specific details into the HTML view layout itself) rather than having these big mega-directives. Most of the time a big mega-directive was simply a template that contained a bunch of composeable directives in a specific arrangement. But this view template could have just as easily been a state view (which now adds it to the router's state lifecycle and navigation). With ng2, the stage has changed a little though.