What is the difference between Meteor.autorun and Tracker.autorun?
are they just aliases?
is one deprecated?
is there any instance where one is preferable to the other?
I'm well aware of the difference in using this.autorun in template lifecycle callbacks, but have seen these two used interchangeably and just want to be sure I haven't missed a trick.
Well, it can easily be found out with the identity operator.
This will be false because it is not the same function:
(function() {} === function() {})
Let's try with the two autorun :
(Meteor.autorun === Tracker.autorun)
This returns true. So yes it's only a pure alias.
However, only Tracker.autorun is documented. I suspect some kind of old API left for compatibility...
Let's check some Meteor code on GitHub!
File : deprecated.js
Meteor.autorun = Tracker.autorun;
This is in deprecated.js, it says some things about //Deprecated functions and some backward compatibility with Meteor 0.5.4. It seems pretty clear which one you should use.
You can find some other old timers in there, such as Deps...
Try to run Meteor.autorun(); in the console, it throws the following error Uncaught Error: Tracker.autorun requires a function argument like you were trying to run Tracker.autorun();
Related
I am currently working on fixing some BestPractice-Warnings on a bigger project. There i have a few instances where forms are called and are awaited before doing more stuff, this is mostly some dialogs. To await form the following code is used very often:
Object formRun;
//declare args and stuf...
formRun = classfactory.formRunClass(args);
formRun.init();
//call methods on formRun (display,run,etc...)
formRun.wait();
The problem i am facing now is that 'wait()' seems to be deprecated and i don't get how to replace or fix this. I have seen that some devs declared the form as 'Object' to get rid of this warning (didn't work by the way, this will still be detected), but this is a late-bound-call which should also be avoided...
Has anyone else had this issue ? i tried calling this method using the system.reflection namespace but this doesn't look right and is also much more code in x++ than should be needed for such a simple task.
TLDR
I think this is a false positive from the best practice checks. To get rid of the best practice warnings, you can add them to the list of suppressed best practices or add a best practice suppression in code.
Details
In Deprecated APIs (June 2017) it says for the wait method of Object:
Overview
Used to block and wait for an interaction/operation and notify to
unblock.
Reason for deprecation
These calls are deprecated for all objects except formRun and it’s
derivatives.
Migration notes
Calls to these APIs from formRun or it’s derivatives are allowed.
Calls to these APIs from any other object should be removed.
When you do a metadata search for code:"formRun.wait()", you will also get a lot of results (more than 1000 on version 8.0). This is further indication that the method is not deprecated for FormRun.
That said, you may want to take a look at the following link which mentions a formRun.lifecycleHelper() to which event handlers can be added. I haven't personally tried this so far, but it may be applicable to your case.
FormRun.wait, Box and ChangeCompany - a poor cocktail
Every time I refresh the page I receive the following console warning for every single helper that is returning something to template from collection. I know the reason is because the subscription is not ready yet, but what is the solution?
Exception in template helper: TypeError: Cannot read property 'x' of undefined.
I'm already using if(collection.find({}) !== undefined) , but this makes my codes so messy, there must be a way to fix this issue. then I tried guards and still not 100% solved.
In addition to Brendan's answer, using Blaze you can check if the subscriptions for the template is ready using
this.subscriptionsReady()
Which checks all the subscriptions scoped to the template with
this.subscribe()
in your onCreated or onRendered blocks
Meteor.subscribe returns a handle with a reactive method called .ready(). You can use that in your helper to only return the mongo cursor once it's ready.
Edit: docs
Upgrading AngleSharp from 0.9.6 to 0.9.9 I have this line of code no longer compiling:
return configuration.With(LoaderService(new[] { requester }));
It complains that LoaderService does not exist in the current context. So what happened to LoaderService? Is there a replacement? Does it still exist but just somewhere else?
Good question. Sorry for being late to the party, but even though you may have solved your problem someone else is having a hard time figuring it out.
LoaderService was essentially just a helper to create a loader. But having a service for anything creating a little thing would be overkill and not scale much. Also AngleSharp.Core would need to define all these. So, instead a generic mechanism was introduced, which allows registering such "creator services" via Func<IBrowsingContext, TService>.
However, to solve your piece of code I guess the following line would do the trick:
return configuration.WithDefaultLoader(requesters: requester);
This registers the default loader creator services (one for documents, one for resources inside documents) with the default options (options involve some middleware etc.).
Under the hood (besides some other things) the following is happening:
// just one example, config.Filter is created based on the passed in options
return configuration.With<IDocumentLoader>(ctx => new DocumentLoader(ctx, config.Filter));
my app was using deaunius:promise package for promises, now it is deprecated, and I have to translate all my promises to the syntax of okfrow:promise package, I was trying to understand how to create meteor Promises with that package and how to translate my current Promises to the new package but Im not sure how to do it in the proper way, it is quite different for me...
This is one example of a promise I used to write with deanius:promise
Meteor.promise('sendSubmission', null, submission)
.then( (result) ->
FlashMessages.sendSuccess "Successfully Finished the Test"
Router.go 'submissionView', _id: result.submissionId
).catch (error) ->
FlashMessages.sendError error.reason
Router.go 'takeTest', slug: currentTest.slug
How to write the above promise using okgrow:promise package? the examples they provide are not helpful at all for me. Thanks for your help
my app was using deaunius:promise package for promises, now it is deprecated
That wording seems to be unfortunate. Instead of being "deprecated", I'd have said "moved" - nothing really changed but the repository; it's still maintained by the same contributor. The code is just a fork, much of it is probably still the same.
I have to translate all my promises to the syntax of okfrow:promise package
No. The API has not changed a bit. All you would need to do is update the name of your dependency.
I have a short piece of code, like so, to update the name in my user's profile:
Meteor.users.update({_id: Meteor.userId()}, {$set:{"profile.name": name}});
When I'm working locally, I can use Meteor.userId or Meteor.userId() without issue. However, when I deploy to Modulus, I run into issues. If I don't have the operator on it, it will do the initial $set, but no more. If I user the operators, it behaves as I would expect.
Why is this? I assume that I shouldn't have been using this without the operator to begin with, but is there a reason why it worked at all?
Have a look in the documentation
The function Meteor.userId() is available "Anywhere but publish functions"
The variable this.userId is available "Anywhere" (which explicitly is also called out for the Server side Publish function).
I have had the same issue with Meteor.userId() when trying to get a unit testing with mocha to work.
A simple fix is to go to tasks.js and replace Meteor.userId() with this.userId which
is to use the this context of the function.