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.
Related
I'm building a synthesizer which has a piano-style keyboard UI input.
The keyboard note on/off events can happen quite frequently, these are used to update different parts of the UI and to trigger audio.
What is the frequency threshold which Redux can handle events? For example, if an event occurs 60 times per second which needs to update some aspect of the UI, how would one handle that using Redux patterns ?
I'm fine with doing this event-ing outside of Redux store entirely if Redux doesn't handle this use case.
Redux doesn't have any magic built into it, it's just an immutable state handler, so whatever javascript can do, redux can do.
What you want to take care of are dom operations, and in your case I'm assuming sound operations.
so your optimizations would be more on the react side, not redux.
if you want help with that, share your relevant react code here.
In general, the place to start optimizing react is shouldComponentUpdate
EDIT:
Here are some links I've found that might give some guidance / inspiration:
https://github.com/xjamundx/react-piano
https://github.com/DanielDeychakiwsky/react-piano
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 want to attach YUI modules synchronously.
Given the YUI modules are already on the page
When I run: console.log YUI().use('base').Base
Then I get `undefined`
However,
When I run: YUI().use('base', (Y) -> console.log Y.Base)
Then I eventually get the Y.Base ctor function
It looks like loader is attaching async as it works fine using the callback method. IIRC the first method is supposed to work too though. What am I missing?
If you're using YUI in a controlled environment like Node.js, then you should be able to use useSync configuration:
YUI({ useSync: true }).use('base').Base
But in a browser, or any other client runtime you should stick to the asynchronous nature of Y.use so loader can do its job of computing the proper list of modules to be attached based on the feature detections etc. Having the modules included manually in the pase is just not enough. Imagine the scrollview-base in IE, which requires an special module called scrollview-base-ie, unless you do detection when building the initial markup that includes that module only when running in IE, you will have a missing module. Again, stick to the asynchronous pattern when loading stuff.
YUI modules really want to be called through a Y object in a callback. If you know for sure that all the code you need is loaded on the page, you can attach them all synchronously with a use *. See https://github.com/evangoer/yui3-cookbook/blob/master/examples/loading/use_synchronous.html for an example.
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.
Are the any GIL-less LLVM-based languages, targeted mainly for JIT-execution which allows to reload PART of the code on the fly?
Like re-compile 1 class, and reload it without stopping the whole program.
Anyone tryed that?
Any chance on doing that with clang (surely, with great deal of developers caution, restriction and manual state handling)?
I think that this is a dynamite idea, and a feature that I would love to have! Have you given any thought to how you would like to interface with the feature?
obj1 = Foo()
compiler.Recompile(Foo, '/some/path/myapp/newsrc/foo.blah');
obj2 = Foo()
// Would this be True?
type(obj1) == type(obj2)
I assume that you expect existing instances to remain unchanged by the recompile?
This seems like it would be easier with functions, as long as they kept the same prototype, but doing it with classes seems like it would get messy.
Also, what to do about threading?
Thread.start(wait 1; bar();); // bar is a function
compiler.Recompile(bar, '/some/path/myapp/newsrc/bar.blah');
Lets say that in our thread we start calling "bar" during the recompile. Does the call block until the recompile is done and then call the new function? Does the old function still exist until the compile is complete? What if we have a function pointer, after the recompile, where does it point? To the original function or to the new one?
Does anyone have any thoughts on how this could be implemented in a strait forward way?
Hmm, can't think of anything off the top of my head. The only major product I can think of is JRebel, but that's for Java.
Apparently, it does not exist yet.