0

I'm new to Angular and I guess this question may already have a fair few comments however I'd like to know what experienced Angular developers find the best practice on how to handle:

  • Passing data between pages (assuming each page has its own controller).

So the 3 ways I can see:

1 - In the URL parameters (I don't prefer this - doesnt give great flexibility, also in my opinion doesn't look so good)

2 - Create a service (e.g. as described here AngularJS - Passing data between pages)

3 - Using parent '$scope'

Thanks.

Community
  • 1
  • 1
userMod2
  • 8,312
  • 13
  • 63
  • 115

4 Answers4

1

Most of the time you will want to use FACTORY because it has:

  • ability to use other services (have dependencies)
  • service initialization
  • delayed/lazy initialization

Factory example (Fiddle)

<div ng-app="myApp">

    <div ng-controller="FirstCtrl">
        <input type="text" ng-model="Data.FirstName"><!-- Input entered here -->
        <br>Input is : <strong>{{Data.FirstName}}</strong><!-- Successfully updates here -->
    </div>
    <hr>
    <div ng-controller="SecondCtrl">
        Input should also be here: {{Data.FirstName}}<!-- How do I automatically updated it here? -->
    </div>

</div>

var myApp = angular.module('myApp', []);

myApp.factory('Data', function(){
   return { FirstName: '' };
});

myApp.controller('FirstCtrl', function( $scope, Data ){
   $scope.Data = Data;
});

myApp.controller('SecondCtrl', function( $scope, Data ){
   $scope.Data = Data;
});

Using $broadcast

You can also use $broadcast to pass data from the high tier of your controller to the end.(Example: jsFiddle)

que1326
  • 2,227
  • 4
  • 41
  • 58
0

No 2 is the most preferable way as I always use that in my projects

Coder John
  • 776
  • 4
  • 7
0

2 - Create a service (e.g. as described here AngularJS - Passing data between pages)

This is the most Angular-ish way and as you've pointed out, is recommended by their docs.

But there are a few things to ponder, much of which is dependent on a) your development experience and b) what development paradigms you're used to. As a bit of background, I came from a very Java-ish background (I was a Flex/Actionscript developer for nearly 10 years). Many of the typical Java-esque development paradigms do not manifest themselves clearly in Angular. Angular seems to me to come from a more Ruby-like paradigm. This is exemplified in many of their APIs and usage recommendations.

One thing I've found out is that rolling your own solution to bypass some of the things that may be distasteful to your development proclivities is often more work in the long run. I can give you about 6-7 examples (in the comments if you wish) in which my inexperience in using Angular and my hardheadedness in being an experienced developer ended up with me finally refactoring to be more Angular.

So to recap, in the case of construct-to-construct communication, I'd go with option #2. I'd elect for an event bus as a secondary option only if the recommended option doesn't suit your needs.

jusopi
  • 6,791
  • 2
  • 33
  • 44
  • Thanks - I'm also from a Java background so like you at lot is new to me. As you say, will avoid swimming against the stream in this case :-) – userMod2 Mar 17 '16 at 15:59
  • I've been using ng1.x for about 1.5-2 years now. I've learned to swallow a few bitter pills but once you realize that most of the Ruby vs Java is really just looking at the same problem from a different angle, things tend to be more palpable (& palatable). For instance things like Restangular/$ngResource are basically services to provide you a **rich** model, whereas in Java-land we like our models very plain (if not just regular ol' hashes). Routes are another thing I've not used in Flex, had to get used to it, now I see the logic. Constructor injection is yet another example. I love attr DI – jusopi Mar 17 '16 at 16:37
0

It depends on what the data you are passing is for.

If there is some data that determines that state of your controller and should be linkable by users, e.g. you have a page that displays a blog article and it needs an ID to get the article info from a database, then that id should be a url parameter e.g. /blog/:id.

If you need some data that belongs to the parent controller, e.g. you have a blog article page and a child part of that page is an author panel that needs to get some information from the blog object itself, then you could access that via the parent $scope, however you should note that this tightly couples the author panel to the blog article controller, and it is almost always a better idea to create a directive and pass the blog object in to the directive isolate scope.

If you have some global data, e.g. a logged in user has a language setting which needs to be accessed by all pages, then you should use a service.

If you need some data that is to do with an event, e.g. a user clicks something and a directive somewhere else needs to know about it, then you can use $emit or $broadcast

Mike Jerred
  • 9,551
  • 5
  • 22
  • 42
  • Say for input from a search field - I like to avoid URL parameters as I 'like the look' of a clear Url field. Is there any performance hit of creating a service for such a simple thing of passing search terms from one page to the show results page? – userMod2 Mar 17 '16 at 16:00
  • There would not be a performance hit, but it might lead you code more towards spaghetti land :) If you are using ui-router than when you transition from the searching page to the results page you can pass parameters that don't show in the URL. (Note that if the search terms are not in the URL then a user cannot save a link to a search they have done though). – Mike Jerred Mar 17 '16 at 16:06
  • Ah yes, agreed, I just thought of that. I feel its good to allow a user to save a search. – userMod2 Mar 17 '16 at 16:29