Proper way of using helpers?

[derek-fong]

I am trying to follow the helpers API example but when I try to do something like this in my controller

myModule.controller('MyCtrl', ['$scope', '$reactive', 'fruitFactory', function($scope, $reactive, fruitFactory) {
        $reactive(this).attach($scope);

        // Reactively get all `apples` from `fruitFactory`
        this.helpers({
            apples: () => fruitFactory.getAllApples()
         });
}]);

Client console keeps giving me this warnings:

defining 'apples' value helper, note that this feature will be deprecated in 1.4 in favor of using 'getReactively' - http://www.angular-meteor.com/api/1.3.1/get-reactively

overriding 'apples'

I have also tried using getReactively() but it does not seem to work properly so I am wondering what is the "proper" way of using helpers() / am I missing something when trying to use getReactively()?

[derek-fong]

Update:

Same code running on 1.3.4 perfectly however on 1.3.5 it shows the warnings (see screenshot below) as soon as the value of fruitFactory.getAllApples() changed and it eventually killed the browser.

[Tallyb]

what is the code in fruitFactory?

[jacobdr]

Design question: why do you want a scope variable on your helpers that isn't being used by meteor? 

Helpers are supposed to be a bridge from meteor collections to your application. 

The only times I think it is appropriate to put a scope variable inside of helpers is when you need to update a subscription or meteor collection query with a scope variable that is fluid. 

— Sent from mobile

On Sun, Jan 17, 2016 at 11:56 AM, Derek notifications@github.com wrote:

Update: Same code running on 1.3.4 perfectly however on 1.3.5 it shows the warnings (see screenshot below) as soon as the value of fruitFactory.getAllApples() changed and it eventually killed the browser.

Reply to this email directly or view it on GitHub: https://github.com/Urigo/angular-meteor/issues/1110#issuecomment-172351923

[derek-fong]

@Tallyb Below is the 'simplified' version of fruitFactory. For example getAllApples() returns result from FruitsCollection.find()

(function () {
    'use strict';

    angular
        .module('myApp.products')
        .factory('fruitFactory', fruitFactory);

    function fruitFactory() {
        return {
            getAllApples: getAllApples;
        }

        function getAllApples() {
            return FruitsCollection.find({type: 'apple'});
        }
    }
})();

@jacobdr I am trying to use apples in my view with ng-repeat.

Sorry this question might not make any sense as I am new to both angular and meteor. The codes that I have written might be incorrect therefore I would like to know how angular-meteor users use helpers() (or getReactively()) in a "proper" way.

[mgrivera]

Hi,

Well, the only thing that I can see differently in your code is that you are getting your mongo collection via an angular factory. I haven't seen, as yet, a sample or tutorial that uses a factory to get the mongo collection and I haven't used one myself. But it should be Ok, as it just returns the mongo collection to the helper function.

Aside from that, your code looks well and is the same as the one from the tutorial. In fact, if we omit the factory, it looks the same as the one in the tutorial:

$reactive(this).attach($scope);

// Reactively get all `apples` from `fruitFactory`
this.helpers({
     // apples: () => fruitFactory.getAllApples()
     apples: () =>  FruitsCollection.find({type: 'apple'} );
});

Helpers are a Meteor concept. They pass data to templates so users can see that data in the view. Helpers are reactive functions and mongo collections are reactive datasources by default. So, when you pass a mongo collection through a helper and the collection changes, the helper is rerun and the view is refreshed.

From what I can see, you don't need getReactively, because your mongo collections are already reactive. getReactively transform a simple value into a reactive datasource, so when you use it in a helper, it will rerun when that value changes. Look at the sample from the angular-meteor docs:

this.relevantId = 10;

  this.helpers({
    users: () => Users.find({ _id: this.getReactively('relevantId') })
  });

Each time this.relevantId changes, the helper will rerun (and the view will be refreshed).

Look at the definition of getREactively from the angular-meteor docs:

Use this method to get a context variable and watch it reactively, so each change of this variable causes the dependents (autorun, helper functions and subscriptions) to run again.

Bye ...

[Tallyb]

I am wondering if what @mgrivera wrote is accurate. I think that moving the helper call to a factory makes it no longer a reactive source, unless it is handled explicitly.

How does reactivity work? check out this explanation: https://www.discovermeteor.com/blog/reactivity-basics-meteors-magic-demystified/

To summarize we need 2 parts: the reactive source (the dog) and the reactive context (the owner)

In the example below we have in fact 2 reactive sources and 2 reactive contexts. $scope.helpers({ users: () => Users.find({ _id: $scope.getReactively('relevantId') }) }); [note: I have changed this to $scope for clarity. could be "this" or "vm". ]

Direction A: Reactive source = collection. Reactive context = $scope.users Every time a change occurs in the users cursor (=queried data), $scope.users will be updated. Direction B: Reactive source = $scope.relevantId Reactive context = users cursor. Every time the value changes in $scope.relevantId, the cursor will be updated (and as a result the $scope.users will be updated as a result of direction A).

$scope is made reactive by default, but another variable (this, vm) must be explicitly made reactive by using $reactive(this).attach($scope); This is why I am wondering if to make your factory reactive you need to explicitly define it as such or make a special transformation (similar to the angular.copy when working with other data sources, e.g. $http).

[Tallyb]

Having written all above, I am trying to look into the actual need of using a service for querying a collection. Being myself a great fan of John Papa style guide, I specifically I looked into the section about separating data services: https://github.com/johnpapa/angular-styleguide#style-y060: Refactor logic for making data operations and interacting with data to a factory. Make data services responsible for XHR calls, local storage, stashing in memory, or any other data operations.

Why?: The controller's responsibility is for the presentation and gathering of information for the view. It should not care how it gets the data, just that it knows who to ask for it. Separating the data services moves the logic on how to get it to the data service, and lets the controller be simpler and more focused on the view.

Why?: This makes it easier to test (mock or real) the data calls when testing a controller that uses a data service.

Why?: Data service implementation may have very specific code to handle the data repository. This may include headers, how to talk to the data, or other services such as $http. Separating the logic into a data service encapsulates this logic in a single place hiding the implementation from the outside consumers (perhaps a controller), also making it easier to change the implementation.

Do you think the whys above are still relevant when working with Meteor collection?

[burock]

Hi, Is my case the same I wonder. I try below code:

        $scope.helpers({
            numberOfFlats: () => { 
                return Counts.get('numberOfFlats'); },
            flats: () => {
                return Flats.find({});
            },
            flat : () => {
                return Flats.findOne($scope.getReactively('currentFlatId'));
            }
        });

and i receive these warnings:

defining 'numberOfFlats' value helper, note that this feature will be deprecated in 1.4 in favor of using 'getReactively' - http://www.angular-meteor.com/api/1.3.1/get-reactively
defining 'flats' value helper, note that this feature will be deprecated in 1.4 in favor of using 'getReactively' - http://www.angular-meteor.com/api/1.3.1/get-reactively
defining 'flat' value helper, note that this feature will be deprecated in 1.4 in favor of using 'getReactively' - http://www.angular-meteor.com/api/1.3.1/get-reactively

[Tallyb]

Regarding having services as reactive, I think @netanelgilad answered it on the meteor forum:

You could actually use the $reactive service to do something like this:

$reactive(MyService).helpers({ myParty : () => Parties.findOne(partyId) }); We made the $reactive service so that you can get the reactivity features into any context, and not just those of $scope or a controller.

[DmitryEfimenko]

+1. Getting warnings in the console. I don't think @mgrivera answered the question posted by OP (you'll get warnings just like all of us).

I think @Urigo should quickly clarify the question: What's the correct way of declaring Meteor collections in the angular app so that you don't get a warnings?

[derek-fong]

Sorry for the late reply guys I have been busy at work.

@Tallyb +1 for John Papa style guide :+1: The reason I am using factories is because (I think) the controllers' job is really to control the presentation and gathering of information for the view and it could be easier to present the flow if the implementation details is put into factories, especially when I have multiple views in a module that could share some common logic with a factory and that could also keep my code DRY. My code used to work perfectly on 1.3.4 but as soon as I updated to 1.3.5 my app fails and if you take a look at my screenshot from my previous comment you can see it threw 7000+ warnings after one single click in my app and eventually crashed, which make me think have I adopted a bad design pattern which is no longer supported?

@DmitryEfimenko I have ended up reverted back to 1.3.4 to keep my app running until someone could clarify what is the correct way to do it.

As I mentioned previously, I am very new to both Angular and Meteor and I would really want to explore how people develop things with these amazing tools :)

[Tallyb]

@DerekFong1004 After looking at all the recent issues, I am quite worried about moving to 1.3.5, Will probably wait for 1.3.6.... Good to know that your pattern worked in 1.3.4. I will consider adopting it.

[veeramarni]

I'm getting same warnings even in 1.3.4.

[DmitryEfimenko]

For what it worth, I'll show how I managed to get rid of warning messages. The message says that helpers({...}) will be deprecated in 1.4, so here is a way to write code without helpers. Example in TypeScript:

class MyCtrl {
    static $inject = ['$scope', '$reactive'];

    apples;

    constructor($scope, $reactive){
        $reactive(this).attach($scope);

        let subApples = this.subscribe('apples');

        this.autorun(()=>{
            if (subApples.ready()) {
                this.apples = FruitsCollection.find({type: 'apple'}).fetch();
            }
        });
    }
}

myModule.controller('MyCtrl', MyCtrl)

Not sure if that's the right way to do it, but it gets rid of warnings.

[atoftegaard]

It's the same damn drill after every minor update. Spending hours on debugging, cause some breaking change was introduced. This project is way too unstable. Testing before releasing? No? Anyone?

[Deadly0]

@atoftegaard 100% agree, a lot of critical issues in 1.3 which block developing and still no fixes.

[dotansimha]

Looks like there are a few misunderstandings here. Let’s start with @DerekFong1004 problem because that’s what the issue is about.

So let’s understand what helpers possible values are: You can create a Function helper, by providing a Cursor, or function, inside the return value of the helper method, for example:

   this.helpers({
      myHelper: () { 
          return SomeCollection.find(); // Returns Mongo.Cursor object
      }
    });

It does not matter if you return a cursor directly or if you get the cursor from another service/factory or any other logic you use, the only thing that important is that you return a Mongo.Cursor object. (@Tallyb) If you see the warning about the deprecation notice, this means that the return value of your method inside the factory does not return Mongo.Cursor object.

You can return a value, and this option is deprecated, so in case you return a value (string, boolean, number, array, object) - you will also get the deprecation notice.

This logic moved to this.getReactively method, and you can provide any value to get reactively, also arrays, functions or any other value you want.

So in order to create a simple one (For example, for a Number primitive), please take a look at this example in step 12 of the tutorial: (12.3 uses getReactively) http://www.angular-meteor.com/tutorials/socially/angular1/search-sort-pagination-and-reactive-vars

You can also provide a function if you want to provide an advanced logic, like providing a function in $scope.$watch, it will run in each $digest cycle and invalidates the Tracker computation, which will case the helper that contain that value to run again and update it’s value.

I followed some of you code examples in this issue and I did not saw things that should not work, the only weird thing is the warning regarding the value helper, while you return a Cusor from your service. I suggest you to get it’s value inside the helper, and before returning it, try to console log the result of instanceof, for example:

this.helpers({
            apples: function() { 
                    let collection = fruitFactory.getAllApples();
        console.log(collection instanceof Mongo.Cursor);

            return collection;
            }
         });

If the printed value of false, it means that something wrong with your fruitFactory factory and with your getAllApples method, because it should return an instance of Mongo.Cursor object.

Also, can you provide a git repo with the actual code you try to run, so we can also run in locally?

Thanks.

And @burock, please read the above in order to understand the difference between the value helpers and the functions helpers, and please provide a live example if you still in trouble.

@DmitryEfimenko - the code you wrote it similar to the code that implements helpers, so you are right, but there are also some special cases that helpers handles.. so I think it’s the best to use the helpers method…

[derek-fong]

@dotansimha Thanks for the detail - I had a read on the example code and in Step 12.18: Add the helper and update the parties subscription:

...
      this.helpers({
        parties: () => {
          return Parties.find({}, { sort : this.getReactively('sort') });
        },
        partiesCount: () => {
          return Counts.get('numberOfParties');
        }
      });
...

If helpers expects a return of Mongo.Cursor object then why partiesCount returns a value?

Also, from the reactiveContext API reference,

angular.module('myApp', []).controller('MyCtrl', ['$scope', '$reactive', function($scope, $reactive)
{
  let reactiveContext = $reactive(this).attach($scope);

  reactiveContext.helpers({
    myName: 'Dotan'
  });

  // This will print your actual value, and you can use it also in your view!
  console.log(this.myName);
}]);

[doronsever]

It's really too bad that you are doing these kind of changes on a 'patch' level upgrade... This is a very big change(And a breaking one) and should had been noticed before...

Any way, i'm trying to fix the 'deprecated' notice but not succeeded so far... The code below still makes this notice.

    this.agreementID = $state.params.agreementID;
    this.helpers({
        assetAgreement: () => {
            return AssetAgreement.find({_id: this.getReactively('agreementID')});
        }
    });

Even though AssetAgreement.find({_id: this.getReactively('agreementID')}) returns a cursor and not a value(console log it)

Also, Before that change, i was able to chain helpers(meaning helper2 value is based on helper 1 value). But now it's gone mad and the value is keep updating

   this.agreementID = $state.params.agreementID;
   this.helpers({
     assetAgreement: () => {
       console.log(AssetAgreement.find({_id: this.getReactively('agreementID')}))
       return AssetAgreement.find({_id: this.getReactively('agreementID')});
     },
     realAssets: () => {
       if (this.assetAgreement.length)
         return RealAssets.find({'_id': this.getReactively('assetAgreement[0].assetID')}); 
     },
     additionalUserDetails: () => {
       if (this.realAssets != undefined && this.realAssets.length)
         return UsersDetails.find({'owner': this.getReactively('realAssets[0].owner')});
     }
   });

Please note that and chrome this works but on FF doesn't... So what is the new best way to accomplish that?

[DmitryEfimenko]

@dotansimha I can confirm that returning am instance of Mongo.Cursor gives warning. Is it possible we are on some old unfixed version?

[nunof07]

Returning a cursor also gives the warning for me.

But what about the following examples, that don't return cursors, but were also easily done with helpers. If this is going to be deprecated, how should it be done instead?

      this.helpers({
        party: () => {
          return Parties.findOne({_id: $stateParams.partyId});
        },
        partiesCount: () => {
          return Counts.get('numberOfParties');
        },
        isLoggedIn: () => {
          return Meteor.userId() !== null;
        },
        currentUserId: () => {
          return Meteor.userId();
        }
      });

None of these return a cursor, but we need another way to do this.

[dotansimha]

@nunof07 @DmitryEfimenko Can you please provide your .meteor/versions file?

[nunof07]

@dotansimha here is the complete file I'm using in an app.

accounts-base@1.2.2
accounts-password@1.1.4
aldeed:collection2@2.8.0
aldeed:collection2-core@1.0.0
aldeed:schema-deny@1.0.1
aldeed:schema-index@1.0.1
aldeed:simple-schema@1.5.3
amplify@1.0.0
angular@1.3.5
angular-meteor-data@0.1.0
angular-templates@0.0.3
angular:angular@1.4.8
angular:angular-messages@1.4.8
angularui:angular-ui-router@0.2.15
anti:i18n@0.4.3
autoupdate@1.2.4
babel-compiler@5.8.24_1
babel-runtime@0.1.4
base64@1.0.4
benjamine:jsondiffpatch@0.1.38_1
binary-heap@1.0.4
blaze@2.1.3
blaze-tools@1.0.4
boilerplate-generator@1.0.4
caching-compiler@1.0.0
caching-html-compiler@1.0.2
callback-hook@1.0.4
check@1.1.0
coffeescript@1.0.11
dburles:collection-helpers@1.0.4
dburles:mongo-collection-instances@0.3.4
ddp@1.2.2
ddp-client@1.2.1
ddp-common@1.2.2
ddp-rate-limiter@1.0.0
ddp-server@1.2.2
deps@1.0.9
diff-sequence@1.0.1
ecmascript@0.1.6
ecmascript-runtime@0.2.6
ejson@1.0.7
email@1.0.8
enforcer:angular-ui-bootstrap@1.0.3
es5-shim@4.1.14
fastclick@1.0.7
fourseven:scss@3.4.1
geojson-utils@1.0.4
hot-code-push@1.0.0
html-tools@1.0.5
htmljs@1.0.5
http@1.1.1
id-map@1.0.4
jquery@1.11.4
lai:collection-extensions@0.1.4
launch-screen@1.0.4
livedata@1.0.15
localstorage@1.0.5
logging@1.0.8
mdg:validated-method@1.0.1
mdg:validation-error@0.2.0
meteor@1.1.10
meteor-base@1.0.1
meteorhacks:inject-initial@1.0.3
minifiers@1.1.7
minimongo@1.0.10
mobile-experience@1.0.1
mobile-status-bar@1.0.6
mongo@1.1.3
mongo-id@1.0.1
nmccready:angular-simple-logger@0.1.7
npm-bcrypt@0.7.8_2
npm-mongo@1.4.39_1
observe-sequence@1.0.7
ordered-dict@1.0.4
pbastowski:angular-babel@1.0.9
peerlibrary:assert@0.2.5
peerlibrary:fiber-utils@0.6.0
peerlibrary:reactive-mongo@0.1.1
peerlibrary:reactive-publish@0.2.0
peerlibrary:server-autorun@0.5.2
promise@0.5.1
raix:eventemitter@0.1.3
random@1.0.5
rate-limit@1.0.0
reactive-dict@1.1.3
reactive-var@1.0.6
reload@1.1.4
retry@1.0.4
routepolicy@1.0.6
seba:minifiers-autoprefixer@0.0.1
service-configuration@1.0.5
session@1.1.1
sha@1.0.4
spacebars@1.0.7
spacebars-compiler@1.0.7
srp@1.0.4
templating@1.1.5
templating-tools@1.0.0
tmeasday:publish-counts@0.7.3
tracker@1.0.9
ui@1.0.8
underscore@1.0.4
url@1.0.5
useful:visitor@0.0.3
useful:visitor-client@0.0.3
useful:visitor-server@0.0.3
webapp@1.2.3
webapp-hashing@1.0.5

[sauliuni]

I have the same problem about the warnings. The only helper i use is:

$reactive(this).attach($scope);

        this.helpers({
            extraList: function () {
                return SomeModel.find();
            }
        });

Strangely i can work with the data provided by this function in Chrome/Safari, but it breaks in Firefox. Tried also to downgrade to 1.3.4, 1.3.2, 1.3.0: Same problem

.meteor/versions (will remove if bug is fixed)

aldeed:collection2@2.8.0
aldeed:collection2-core@1.0.0
aldeed:schema-deny@1.0.1
aldeed:schema-index@1.0.1
aldeed:simple-schema@1.5.3
angular@1.3.5
angular-meteor-data@0.1.0
angular-templates@0.0.3
angular:angular@1.4.8
angular:angular-animate@1.4.8
angular:angular-mocks@1.4.8
angular:angular-resource@1.4.8
angularui:angular-ui-router@0.2.15
autoupdate@1.2.4
babel-compiler@5.8.24_1
babel-runtime@0.1.4
base64@1.0.4
benjamine:jsondiffpatch@0.1.38_1
binary-heap@1.0.4
blaze@2.1.3
blaze-tools@1.0.4
boilerplate-generator@1.0.4
caching-compiler@1.0.0
caching-html-compiler@1.0.2
callback-hook@1.0.4
check@1.1.0
dburles:mongo-collection-instances@0.3.4
ddp@1.2.2
ddp-client@1.2.1
ddp-common@1.2.2
ddp-server@1.2.2
deps@1.0.9
diff-sequence@1.0.1
ecmascript@0.1.6
ecmascript-runtime@0.2.6
ejson@1.0.7
es5-shim@4.1.14
fastclick@1.0.7
fourseven:scss@3.4.1
geojson-utils@1.0.4
hot-code-push@1.0.0
html-tools@1.0.5
htmljs@1.0.5
http@1.1.1
id-map@1.0.4
jquery@1.11.4
lai:collection-extensions@0.1.4
launch-screen@1.0.4
livedata@1.0.15
logging@1.0.8
mdg:validation-error@0.2.0
meteor@1.1.10
meteor-base@1.0.1
minifiers@1.1.7
minimongo@1.0.10
mobile-experience@1.0.1
mobile-status-bar@1.0.6
mongo@1.1.3
mongo-id@1.0.1
mquandalle:bower@1.5.2_1
npm-mongo@1.4.39_1
observe-sequence@1.0.7
ordered-dict@1.0.4
pbastowski:angular-babel@1.0.9
promise@0.5.1
raix:eventemitter@0.1.3
random@1.0.5
reactive-dict@1.1.3
reactive-var@1.0.6
reload@1.1.4
retry@1.0.4
reywood:bootstrap3-sass@3.3.5_2
routepolicy@1.0.6
session@1.1.1
spacebars@1.0.7
spacebars-compiler@1.0.7
standard-minifiers@1.0.2
templating-tools@1.0.0
tracker@1.0.9
ui@1.0.8
underscore@1.0.4
url@1.0.5
webapp@1.2.3
webapp-hashing@1.0.5

[DmitryEfimenko]

@dotansimha here is my .meteor/versions file:

accounts-base@1.2.2
accounts-facebook@1.0.6
accounts-google@1.0.6
accounts-oauth@1.1.8
accounts-password@1.1.4
accounts-twitter@1.0.6
accounts-ui-unstyled@1.1.8
aldeed:collection2@2.8.0
aldeed:collection2-core@1.0.0
aldeed:schema-deny@1.0.1
aldeed:schema-index@1.0.1
aldeed:simple-schema@1.5.3
angular@1.3.5
angular-meteor-data@0.1.0
angular-templates@0.0.3
angular:angular@1.4.8
angular:angular-animate@1.4.8
angular:angular-aria@1.4.8
angular:angular-messages@1.4.8
angular:angular-sanitize@1.4.8
angular:angular-touch@1.4.8
angularui:angular-ui-router@0.2.15
angularutils:pagination@0.9.1_2
anti:fake@0.4.1
autoupdate@1.2.4
babel-compiler@5.8.24_1
babel-runtime@0.1.4
barbatus:ts-compilers@0.2.6
barbatus:typescript@0.1.5
base64@1.0.4
benjamine:jsondiffpatch@0.1.38_1
binary-heap@1.0.4
blaze@2.1.3
blaze-tools@1.0.4
boilerplate-generator@1.0.4
caching-compiler@1.0.0
caching-html-compiler@1.0.2
callback-hook@1.0.4
check@1.1.0
dataflows:typescript-utils@0.1.5
dburles:mongo-collection-instances@0.3.5
ddp@1.2.2
ddp-client@1.2.1
ddp-common@1.2.2
ddp-rate-limiter@1.0.0
ddp-server@1.2.2
deps@1.0.9
diff-sequence@1.0.1
dotansimha:angular-reactive-component@0.0.6
ecmascript@0.1.6
ecmascript-runtime@0.2.6
ejson@1.0.7
email@1.0.8
facebook@1.2.2
fastclick@1.0.7
fortawesome:fontawesome@4.5.0
fourseven:scss@3.4.1
geojson-utils@1.0.4
google@1.1.7
hot-code-push@1.0.0
html-tools@1.0.5
htmljs@1.0.5
http@1.1.1
id-map@1.0.4
jquery@1.11.4
lai:collection-extensions@0.2.1_1
launch-screen@1.0.4
less@2.5.1
livedata@1.0.15
localstorage@1.0.5
logging@1.0.8
mdg:validated-method@1.0.1
mdg:validation-error@0.3.0
meteor@1.1.10
meteor-base@1.0.1
meteorhacks:ssr@2.2.0
meteortypescript:compiler@3.0.1
minifiers@1.1.7
minimongo@1.0.10
mobile-experience@1.0.1
mobile-status-bar@1.0.6
mongo@1.1.3
mongo-id@1.0.1
netanelgilad:ng-infinite-scroll@1.2.0_1
npm-bcrypt@0.7.8_2
npm-mongo@1.4.39_1
oauth@1.1.6
oauth1@1.1.5
oauth2@1.1.5
observe-sequence@1.0.7
ordered-dict@1.0.4
pbastowski:angular-babel@1.0.9
pbastowski:angular2-now@1.1.6
promise@0.5.1
raix:eventemitter@0.1.3
random@1.0.5
rate-limit@1.0.0
reactive-dict@1.1.3
reactive-var@1.0.6
reload@1.1.4
retry@1.0.4
reywood:publish-composite@1.4.2
routepolicy@1.0.6
service-configuration@1.0.5
session@1.1.1
sha@1.0.4
spacebars@1.0.7
spacebars-compiler@1.0.7
srp@1.0.4
standard-minifiers@1.0.2
templating@1.1.5
templating-tools@1.0.0
tinque:angular-translate@2.7.0_2
tmeasday:publish-counts@0.7.3
tracker@1.0.9
twitter@1.1.5
ui@1.0.8
underscore@1.0.4
urigo:angular@0.10.2
url@1.0.5
webapp@1.2.3
webapp-hashing@1.0.5

[dotansimha]

@nunof07 @DmitryEfimenko Hi, just verified and you are right. we have a little bug with the latest version. As I said before, your code looks fine.. we used the method that printed those deprecated warnings inside our code. Sorry for all the confusion.. For the moment, keep your code the same, your code is fine and the deprecated warning will be gone in the next version!

[DmitryEfimenko]

The question regarding returning Cursor is clarified. Thanks for that. Now it's only unclear what to do in the cases specified by @nunof07. Any pointers regarding that?

[berkaytheunicorn]

what about this ?

    $rootScope.helpers
        appInfo: ->
            return Settings.findOne {slug:slug}

I'm getting this

[Warning] defining 'appInfo' value helper, note that this feature will be deprecated in 1.4 in favor of using 'getReactively' - http://www.angular-meteor.com/api/1.3.1/get-reactively (angular-meteor-data.js, line 1784)

this returns object not a Cursor but still valid(proper) way to get data on Meteor right?

[jacobdr]

I think that it is as long as slug is reactive. 

If it is not reactive then there is no reason to do this in helpers -- just make a find one call outside of angular-meteor on the meteor collection in the Dom. 

To ensure slug is reactive, make your object {"slug": $scope.getReactively(slug)}, possibly using deep watch option. 

As always, a reproduction of these issues in a codepen/meteorpad helps, so that if you find a bug it can be reproduced / test case added / fixed. 

— Sent from mobile

On Fri, Feb 5, 2016 at 4:01 AM, Berkay Sargın notifications@github.com wrote:

what about this ?

  $rootScope.helpers
      appInfo: ->
          return Settings.findOne {slug:slug}

I'm getting this

[Warning] defining 'appInfo' value helper, note that this feature will be deprecated in 1.4 in favor of using 'getReactively' - http://www.angular-meteor.com/api/1.3.1/get-reactively (angular-meteor-data.js, line 1784)

this returns object not a Cursor but still valid(proper) way to get data on Meteor right?

Reply to this email directly or view it on GitHub: https://github.com/Urigo/angular-meteor/issues/1110#issuecomment-180258501

[Urigo]

@berkaey yes you are correct. The simple solution is to not use findOne but just use find with query for the one you want. or use getReactively.

[johnba2012]

@urigo Hi, If using find instead of findOne, is there a way to access the single row in the template without recourse to ng-repeat? Thanks

[kamilkisiela]

@johnba2012 Maybe just [0] ?

[DmitryEfimenko]

that's ugly if that's the way it'll be done to handle findOne

[nunof07]

There are other situations that are reactive but don't return a cursor.

this.helpers({
        partiesCount: () => {
          return Counts.get('numberOfParties');
        },
        isLoggedIn: () => {
          return Meteor.userId() !== null;
        },
        currentUserId: () => {
          return Meteor.userId();
        }
});

Alternatives for these?

[DmitryEfimenko]

I'll also throw in another use case.

How should I handle a situation when I need to modify array returned from collection after it came in based on the condition that is only known in the client code (the use of transform on the collection definition is not an option)?

It seems that using .forEach() on the cursor is wrong because it return void, therefore cannot be used in the helper().

Currently I do something described in the issue 1161, but that example does not use .helpers, and has its own issues.

[Urigo]

We are releasing 1.3.6-beta.1 very soon and we will release an example for each use case mentioned in this issue and link it here

[Urigo]

angular@1.3.6-beta.1 was released that should fixed the original issue. @DerekFong1004 Please check to see if that works for you.

@burock about your scenario, here is how it should look:

  this.autorun(() => {
    this.numberOfFlats = Counts.get('numberOfFlats');
  });
  this.autorun(() => {
    this.flat = Flats.findOne($scope.getReactively('currentFlatId'));
  });
  $scope.helpers({
    flats: () => {
      return Flats.find({});
    },
  });

The reason I don't recommend value helpers and just Cursor helpers is because of handling nested reactive variables which is a pain in Meteor. take a look on that issue for more info - https://github.com/Urigo/angular-meteor/issues/955

so @DmitryEfimenko , your first code snippet is the way to go.

@doronsever can you test your scenario according to those examples and the beta and let me know if that fixed the issue for you?

@sauliuni your example should be working now.

@nunof07 as for your scenario:

  this.autorun(() => {
    this.party = Parties.findOne({_id: $stateParams.partyId});
  });
  this.autorun(() => {
    this.partiesCount = Counts.get('numberOfParties');
  });
  this.autorun(() => {
    this.isLoggedIn = Meteor.userId() !== null;
    this.currentUserId = Meteor.userId();
  });

@atoftegaard you are kind of right with your criticism and I accept it and take responsibility - 1.3.0 was a huge change and it should have been 2.0. But most of the noise was due to misunderstandings and small annoying bugs with warning messages just creating too much confusion. I've released 1.3.6 in beta so I could get more feedback before releasing that fix.

[DmitryEfimenko]

Awesome! Could someone quickly point a noob (me) to the docs on how to run a custom meteor build locally?

[Urigo]

@DmitryEfimenko you don't need to - just specify the version in your .meteor/packages file: like - angular@1.3.6-beta.1

[lokewate]

@Urigo Can someone please update the tutorial at http://www.angular-meteor.com/tutorials/socially so new comers to angular-meteor don't get unnecessarily confused. autorun should be explained and used instead of the non-cursor based helpers. Thanks!

[Urigo]

@lokewate yes, I hope to get to it really soon. first I want to make sure the beta works for everyone

[TWKDreamState]

Do we still need to manually call a digest (or use $q) for a Meteor.call?

On Sat, Feb 13, 2016 at 2:13 PM, Uri Goldshtein notifications@github.com wrote:

@lokewate https://github.com/lokewate yes, I hope to get to it really soon. first I want to make sure the beta works for everyone

— Reply to this email directly or view it on GitHub https://github.com/Urigo/angular-meteor/issues/1110#issuecomment-183675765 .

[Urigo]

@TWKDreamState no, you can use this.call - http://www.angular-meteor.com/api/1.3.6/call

[TWKDreamState]

@Urigo I'm getting a 'TypeError: this.call is not a function' error? I've possibly mucked up somewhere as I'm updating old code to the new syntax but it all looks OK to me?

[TWKDreamState]

@Urigo Sorry, my mistake - I used the following instead....

var vm = $reactive(this).attach($scope); vm.call....

I had it within a 'parent' function so guess this is needed.

[Urigo]

@TWKDreamState without doing var vm = it didn't work for you? can you provide a reproduction for that scenario? it suppose to work without that

[TWKDreamState]

@Urigo Because my code was a bit of a mess as I transitioned to the new syntax (a mixture of $scope and this) I rewrote it in component form in a directive and it now works without the var vm =.

[Urigo]

cool

[0xfbravo]

@Urigo Hello, i've updated my angular to 1.3.6-beta.1 and really solved my bunch of warnings! But now, i've got one Error. In my version, before upgrade, i was able to call directives from my app body like: `

`

Now, my directive gives me this error:

Error: scope.viewModel is not a function. (In 'scope.viewModel(this._vm)', 'scope.viewModel' is undefined)

Should I open a new Issue?

[DmitryEfimenko]

@insidemybrain That depends on your case. Does not look like the code you showed has anything to do with Meteor. I've been updating my app according to latest @Urigo's comment and so far all works fine.