share data between templates(views) - Services or Query string

[Hastek]

I am an angular newbie. I am trying to pass a selected value from one view to the other while navigating using $location.path . I see two options;

1) pass it as part of the url : $location.path('/location/' + modes.searchType)

2) use a common service between the two controllers and save/retrieve the selected parameter using a service property/variable.

please help me suggesting which is the right/best practice. One thing I am assuming is the url option could be useful incase of caching..

[Tony pee]

There are a few options

1 If you want the state to be stored to history, or there on refresh, then use a url variable. 

2 If your state is specific to a purpose, then storing the value on a service is often the best way. Your other controller can share a reference to the service. 

3. If you are just looking for simple communication, then maybe look at events. You can use $rootScope.$emit and $rootScope.$on

4 Also, We have a service which is an 'eventChannel', which is basically an instance of an EventEmitter (look at nodejs). This means that you can dispatch events to other parts of your application and listen globally. I find this neater than using $rootScope.xxx for events

--
You received this message because you are subscribed to the Google Groups "AngularJS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to angular+u...@googlegroups.com.
To post to this group, send email to ang...@googlegroups.com.
Visit this group at http://groups.google.com/group/angular.
For more options, visit https://groups.google.com/d/optout.

--

Tony Polinelli

[Vivek Anand]

You can use a Singleton class 'TransientStore', which will keep the data in a map as {key, value} pair to share between two different controller.

First controller will generate the value and put it in this TransientStore against a key. Second controller will pop up the value from this store using the same key and remove it.

[Vivek Anand]

Tony, I would not recommend any service to store any data. Usually, service classes must be stateless. Please share, if you have any views.

[Hasan Ali]

Thanks  Tony and Vivek for your suggestions.

On Nov 18, 2014 1:33 PM, "Vivek Anand" <viv....@gmail.com> wrote:

Tony, I would not recommend any service to store any data. Usually, service classes must be stateless. Please share, if you have any views.

--
You received this message because you are subscribed to a topic in the Google Groups "AngularJS" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/angular/ygBUnIi30nc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to angular+u...@googlegroups.com.

[Tony pee]

Avi, yes, it can be good to keep services stateless. In the case of interoperating controllers however, this is not a useful reality. In our example, we have a conversation view with an options panel on the right, and a navigation on the left. If you select a conversation on the left then you need to load it, and store model information. the 'selected conversation' needs to be stored somewhere, as does all of the loaded conversation models. These are stored in a 'rooms' manager service. You are right that the state of this rooms manager could be linked to the url (if we wanted its state to persist between page refreshes), but that isnt required for us. So, the rooms manager stores the conversation state which is referenced by 3 controllers. In this way they can share state. 

--

You received this message because you are subscribed to the Google Groups "AngularJS" group.

To unsubscribe from this group and stop receiving emails from it, send an email to angular+u...@googlegroups.com.

To post to this group, send email to ang...@googlegroups.com.
Visit this group at http://groups.google.com/group/angular.
For more options, visit https://groups.google.com/d/optout.

--

Tony Polinelli

[Tony pee]

Sorry, not Avi (not sure where i got that) - Vivek

--

Tony Polinelli

[Tony pee]

Plus, i would recommend services to store most data - think of it as model data. 

--

Tony Polinelli