What is the best practice for calling autosubscribe client side in a Meteor app?
Should it always be in Meteor.startup?
If so, why?
If not, why?
If sometimes, why?
In summary, what is the best practice and what are the trade offs based on the options of putting autosubscribe in the meteor.startup versus not? I think this is very important at this time for application developers because it significantly affects our application design decisions.
Autosubscribe has been deprecated and I suspect you want to use autorun now,. It's documented at http://docs.meteor.com/#meteor_autorun
When you want to automatically update the subscription whenever the session variable changes.
Source: From the comment in the example at Meteor.autosubscribe.
From tests I have done it does seem that putting your autosubscribe in Meteor.startup is the safest solution if you need those collections to have some kind of data population or start populating before view rendering. I experienced similar issues that #matb33 has reported with empty data on load and placing autosubscribe in Meteor.startup on the client solved the problem.
Note that autosubscribe is now gone, and replaced with autorun.
Related
I have a (Iron) Router.onBeforeAction that is triggered more than once.
I know for sure that it is a reactivity source that has changed somehow.
How can I know what triggers reactivity ?
You can't always know, because Tracker.dependency can be abstracted away from your view, especially when using external modules / packages.
See: https://docs.meteor.com/api/tracker.html#tracker_dependency
You will have to look into the code of the packages on which you assume to be reactive (like ReactiveVar) and check at which point it calls dependency.changed.
I am developing a simple farming game backend using meteor.
So Server needs to check all players farm data and based on that for example increment
production:0
field each second if player has a farm.
What is the best way to do that ?
Should i use Meteor.setTimeout()
You should use Meteor.setTimeout if you don't manually want to bind fibers to the callback function.
Related issues:
What's going on with Meteor and Fibers/bindEnvironment()?
Meteor wrapAsync or bindEnvironment without standard callback signature
However, you can also use the native JS setTimeout but you will have to manually bind a fiber to the callback (if you aim to use for example Mongo) using Meteor.bindEnvironment or Meteor.wrapAsync.
Another interesting tool is Meteor.defer which is similar to Meteor.setTimeout(func, 0) and allows to execute code in the background. Beware of several layers of callbacks when mixing with Meteor.setTimeout.
Ans yet another tool when executing complex services in a method is this.unblock.
Applying these tools in an appropriate way will make your timer based update possible.
Although I started using Meteor extensively only recently, the name "Session" for a Session object in Meteor feels like a misnomer to me. It is very different from how it's conventionally used across the web and I don't understand why it's named that way. Is there a specific reason to this or is it possible to rename it to something more suitable?
A Session variable is a reactive data source which:
can be globally accessed anywhere in your client code
will survive a hot code push
will not survive a hard reload
I agree that the name is confusing because of the last point. To answer your question, yes you could name it something else if you really wanted to. For example:
client/lib/session.js
NotReallySession = Session;
Then elsewhere in your client code, you could do:
NotReallySession.set('answer', 42);
NotReallySession.get('answer');
However, I'm not sure what you really gain by doing this.
A more attractive solution would be to use a package like persistent-session which modifies the Session api to give you persistence across page refreshes by keeping values in localstorage.
Of particular interest may be the Session.setAuth function, which stores a persistent reactive value which is cleared on logout. In my view, this most closely aligns with the notion of "session" from other contexts.
First - I am having a hard time formulating this question, so please bear with me, and ask for clarification and I'll try to provide as much as I can. I am just starting to learn meteor, so be patient please.
I have several inputs that save immediately as people type on them. (with a slight 300 ms delay to not overload database).
Basically, on "keyup" it goes and saves. All that works fine. However, I'd like to add a visual indicator (say a green checkmark, or a tiny "saved") when the database actually stores what they typed.
Graphically:
[___________________]
[Typed something_____] (saved)
[___________________]
I am not sure how to go about this, but it's something common, that plenty of you have already done. If I didn't care about the database feedback, I'd just use JQuery, target a class beside the input and make the checkmark or word visible after a keyup, or add it to the DOM. Fairly straight forward.The only when I am sure it has been stored in Mongodb part confuses me.
Any help would be gladly appreciated.
Thank you
Addendum with code:
Template.dibs.events({
'keyup input.name': _.throttle(function(event) {
Dibs.update(this._id, {$set: {name: event.target.value}});
$(':focus + .glyphicon-ok').css('opacity',1);
}, 300),
Can you explain where/how you would add the code? (For spinner, or the words).
Coming from JQuery I did something that I know is not the right way. This is in the client portion (I know just demo code, and it's not secure) but I wanted to know the best way leveraging meteor to do it. I already have checkmarks stating it was saved in the page, but they are all hidden, this code just makes them visible on keyup for the field.
I read through the article, and didn't quite see how I'd go about doing the intermediate step (spinner or the like) then the finalized checkmark after code is saved. I've also being going through the new 1.0 tutorial (which is great) but I'm still missing the visual indicators. It's great that meteor updates the UI if it fails in the server to reflect that it didn't save, since I am assuming success, I don't think that tapping into the Meteor.Error makes sense. Should there not be a Meteor.Success or equivalent?
Again, I apologize for the long message, I'm trying to wrap my head around this, because the technology looks very promising
Welcome to Meteor! Meteor was in fact designed (among other things) to handle just this type of situation, via a mechanism called Latency Compensation. You can read more about it at Meteor.methods.
Calling a method on the server requires a round-trip over the network. It would be really frustrating if users had to wait a whole second to see their comment show up due to this delay. That's why Meteor has a feature called method stubs. If you define a method on the client with the same name as a server method, Meteor will run it to attempt to predict the outcome of the server method. When the code on the server actually finishes, the prediction generated on the client will be replaced with the actual outcome of the server method.
You can use Latency Compensation by defining a Meteor method to save the input text to the database, with a client stub that displays a spinner instead of "saved", and "saved" when its callback is called successfully.
Alternatively, you can call the update method on the collection directly, and add a callback on the client, which will be called with (error, numberOfDocsUpdated) after the server method returns.
Read more on when to use Meteor methods and when to use client-side operations.
As Dan has said, the Latency Comp takes care of needing to do this. Another way of doing this is in a template event. You can set a session variable on keyup with the contents of the text field and in the helper, set a flag that will render the checkmark when the session variable and current user input matches.
I'm building a Web Page that allows the user to pick a color and size. Once they have these selected I need to perform a lookup to see if inventory exists or not and update some UI elements based on this.
I was thinking that putting all the single product data into multidimensional JavaScript array (there is only 10-50 records for any page instance) and writing some client side routines around that, would be the way to go for two reasons. One because it keeps the UI fast and two it minimizes callbacks to the server. What i'm worried about with this solution is code smell.
As an alternative i'm thinking about using a more AJAX purist approach of using HTTP handlers and JSON, or perhaps a hybrid with a bit of both. My question is what are your thoughts as to the best solution to this problem using the ASP.Net 2.0 stack?
[Edit]
I also should mention that this page will be running in a SharePoint environment.
Assuming the data is static, I would vote option #1. Storing and retrieving data elements in a JavaScript array is relatively foolproof and entirely within your control. Calling back to the server introduces a lot of possible failure points. Besides, I think keeping the data in-memory within the page will require less code overall and be more readable to anyone with a more than rudimentary understanding of JavaScript.
i'm against Ajax for such tasks, and vote (and implemented) the first option.
As far as I understand, you won't create Code smells if the JS part is being written by your server-side.
From a user point-of-view, Ajax is an experience-killer for wireless browsing, since any little glitch or mis-service will fail or simply lengthen the interaction by factors of 20(!).
I've implemented even more records than yours in my site, and the users love it. Since some of my users use internet-caffee, or dubious hotel wifi, it wouldn't work otherwise.
Besides, Ajax makes your server-vs-client interaction code much more complex, IMO, which is the trickiest part in web programming.
I would go with your second option by far. As long as the AJAX call isn't performing a long running process for this case, it should be pretty fast.
The application I work on does lots with AJAX and HttpHandler, and our calls execute fast. Just ensure you are minimizing the size of your JSON returned in the response.
Go with your second option. If there are that few items involved, the AJAX call should perform fairly well. You'll keep your code off the client side, hopefully prevent any browser based issues that the client side scripting might have caused, and have a cleaner application.
EDIT
Also consider that client side script can be modified by the user. If there's no other validation occuring to the user's selection, this could allow them to configure a product that is out of stock.