4

This is an angularjs app. I have a service that handles the loading of content (ajax). While the service is getting the content, a number of things throughout the app hide, later showing again (depending on the content returned). They might have the same scope, different scope, whatever. They just need to hide while content is loading, and then show when it's done. Pretty normal stuff.

Right now, I have separate controllers watching a "loading" property of the service and using regular angular directives (ng-show, ng-hide, etc.) to show/hide. But this feels like overkill. I'd prefer to write a custom "loading" directive that injects the loading service and does the watching and showing/hiding.

My question is: Is what I want to do "bad"? The controller way, I end up boilerplating a bunch of code, maybe up to like 5 or 6 times, or even more as the app grows. The custom directive way, I write it once and use an attribute where I need it. Yeah - there's a dependency on that service, but that just doesn't feel like the end of the world that some people have made me start to think I should think it is.

For what it's worth, I feel like I've heard "separation of concerns" so many times I've become paralyzed by it. It leads me to overthink everything because I want to do things the right way, but it sure doesn't feel like I'm being very productive.

Improve this question
2
  • 2
    This is tangential, but separation of concerns and other "best practices" are designed to help make your app easer to change, reason about, and test. There are reasons for all of them, but don't fall into the trap of doing stuff just because someone told you to, or become paralyzed by fear of doing something "wrong." At the same time, don't dismiss something because it doesn't make sense at the time--be willing to learn why it's a recommended practice. There's a balance to be struck, and remember, the end goal is to make something cool and have fun doing it! Commented May 31, 2013 at 1:25
  • @BrandonTilley - There's the rub. I'm not yet familiar with it enough to know when what someone's told me is good, bad or somewhere in between. But I appreciate the tangential advice and your final sentence! Commented May 31, 2013 at 1:55

2 Answers 2

Reset to default
5

If I understood correctly, you have a bunch elements that should hidden when a particular service is loading data, and then be displayed again when the data is loaded, right?

In that case, events might be a good solution:

  • they can be global to the appliciation (which i think is what you are aksing for).
  • they allow for avoiding direct coupling between elements (also one of your concerns).

So, in your service, just broadcast events when stuff happens:

$rootScope.$broadcast('loading-data');
axajStuffOrWhatever(function() {
   $rootScope.$broadcast('data-loaded');
});

Then, wrap the show/hide behaviour in a directive that will listen to those events.

.directive('hideWhileLoadingData', function() {
  return {
    link: function(scope, el, attrs) {
      scope.$on('loading-data', function() {
        el.css('display', 'none');
      });
      scope.$on('data-ready', function() {
        el.css('display', 'block');
      });                
    }
  };  
});

Use the directive:

<div hide-while-loading-data>something</div>

The advantage of using events here, is that later on, they could be originated by a different service, or by multiple services, and the directive will not be affected by that as long as the events are the same.

For more complex behaviour, you could also parametrize the events and the directive, so different elements will react to different kind of stuff.

I've made an example of this.

Improve this answer
Sign up to request clarification or add additional context in comments.

3 Comments

Thanks for the thoughts. Originally, I was using that sort of "$broadcast/$on"setup. I even parameterized the events just as you described. The reason I'm not doing that now is simply that I'm in the process of learning all this, and wanted to try it both ways. :)
well if you reach a conclusion about which way is better, you can update your question with the pros and cons of what you have tried ;)
Indeed. But based on all the research I've done to this point, coupled with my utter lack of knowledge...it's going to be six vs. 1/2 dozen!
0

In my opinion all scopes which depend on this service should be children of one parent scope. If you have the parent scope responsible for talking with the service then any directive of any scope can access it via $parent on the $scope.

Improve this answer

1 Comment

From the docs: "Scopes are arranged in hierarchical structure which mimic the DOM structure of the application." So I definitely see what you're saying, but in some respects it also feels like this would be doing it backwards -- like arranging the DOM structure of my application to accommodate a hierarchy that you've described.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.