What's the purpose of async method in polymer? When should I use it?
Right now I'm using it like hm-this-bug-is-kinda-weird-maybe-async-will-fix-it-yep-id-did-yey. It does not give me any confidence in my code as I'm sprinkling async just when some timing bug shows up.
The answer is slightly different here depending on whether you're using Polymer 0.5 or 1.0. In 1.0, more operations are synchronous, so you may not see quite as much need for async (also, the async method works slightly differently in 1.0).
Let's start with 0.5. Most of the cases have to do with the effects of changing properties. Properties used in data bindings or observers are observed for changes. When you change one of these
properties, any side-effects of that change take place asynchronously, with microtask timing. That means that the work happens after the current event handler returns, but before the next event is processed.
In other words, if I have a data binding like this:
<div id="output">{{someProperty}}</div>
Suppose I have the following code:
this.someProperty = "New Value";
console.log(this.$.output.textContent); // logs "Old Value"
This is where the asynchrony bites you. If you want the bound data to be updated, you need to give the data binding system a chance to work. If you move that console.log statement into an async, so it's executed at a later time, you get the response you expect:
this.async(function() {
console.log(this.$.output.textContent); // logs "New Value"
});
Most of the time, you don't need to poke at data bound DOM elements. But in the event that you do, or that you're waiting on the side effect of an observer, you probably want an async.
In Polymer 1.0, data binding and single-property observers are synchronous. Multi-property observers and some DOM operations are async.
(While the APIs are different from JavaScript, this Dart article about the event loop is the best one I've found to describe the event loop and microtask queue: https://www.dartlang.org/articles/event-loop/)
Related
When working on a SolidJS project you might start seeing the following warning message in your JS console:
computations created outside a `createRoot` or `render` will never be disposed
There are some information available on this in SolidJS' Github repository issues. But after reading them I was still not quite sure what this was all about and whether my code was really doing something wrong.
I managed to track down where it came from and find a fix for it based on the documentation. So I'm providing the explanation and the solution for those Googling this warning message.
In essence this is a warning about a possibility of a memory leak due to a reactive computation being created without the proper context which would dispose of it when no longer needed.
A proper context is created a couple of different ways. Here are the ones I know about:
By using the render function.
By using the createRoot function. Under the hood render uses this.
By using the createContext function.
The first is by far the most common way, because each app has at least one render function call to get the whole show started.
So what makes the code go "out of context"?
Probably the most common way is via async calls. The context creation with its dependency tree happens only when the synchronous portion of the code finishes running. This includes all the export default function in your modules and the main app function.
But code that runs at a later time because of a setTimeout or by being in an async function will be outside of this context and any reactive computations created will not be tracked and might stick around without being garbage collected.
An example
Let's say you have a data input screen and have a Save button on it that makes an API call to your server to save the data. And you want to provide a feedback to the user whether the operation succeeded or not, with a nice HTML formatted message.
[msg,setMsg] = createSignal(<></>)
async function saveForm(){
...
setMsg(<p>Saving your data.<i>Please stand by...</i></p>)
const result=await callApi('updateUser',formData)
if(result.ok){
setMsg(<p>Your changes were <b>successfully</b> saved!</p> )
} else {
setMsg(<p>There was a problem saving your data! <br>Error: </p><pre>{result.error}</pre> )
}
}
...
<div>
...
<button onClick={saveForm} >Save</button>
{msg()}
</div>
This will produce the above mentioned warning when the API call returns an error, but not the other times. Why?
The reason for this is that SolidJS considers the code inserts inside JSX to be reactive, ie: need to be watched and re-evaluated. So inserting the error message from the API call creates a reactive computation.
The solution
I found the solution at the very end of the SolidJS doc. It's a special JSX modifier: /*#once*/
It can be used at the beginning of a curly brace expression and it tells the SolidJS compiler to explicitly not to make this a reactive expression. In other words: it will evaluated once and only once when the DOM nodes are created from the JSX.
In the above example here's how to use it:
setMsg(<p>There was a problem saving your data! <br>Error: </p><pre>{/*#once*/ result.error}</pre> )
After this there will be no more warning messages :)
In my case, I had an input and when that input changed I re-created an SVG drawing. Because the SVG creation was an expensive operation, I added a debounce in the createEffect function which ran when the input changed. debounce is a technique to defer the processing until the input stops changing for at least X amount of time. It involved running the SVG generation code inside the setTimeout function, thus being outside of the main context. Using the /*#once*/ modifier everywhere where I inserted an expression in the generated JSX has fixed the problem.
Sometimes I'm coding in a wrong way my polymer 1.0 web app and stuff stops to work properly. Like setting data to some custom element and then immediately trying to read some data out of it (that depends on the data just set) (because I don't know better). Sometimes this doesn't work. Most of the time this.async will help me out, but sometimes it will not. However, setTimeout has never ever failed me in these kind of situations. Most of the time calling setTimeout without providing wait time will work just as well.
For a long time I thought that this.async(function(){...}) is the same as setTimeout(function(){...}). Because sometimes code inside this.async will fail to see changes in custom element's data while code inside setTimeout will not.
Are these two methods are implemented in different way?
this.async adds your function to the start of the event queue, while setTimeout adds it to the end. If you use setTimeout other functions may have been executed before your function is called, causing the changes that you can see in your data.
From the documentation of this.async:
If no wait time is specified, runs tasks with microtask timing (after the current method finishes, but before the next event from the event queue is processed)
setTimeout on the other hand will add your function to the end of the queue as is described in the section "Adding Messages" of this article.
Calling setTimeout will add a message to the queue after the time passed as second argument. If there is no other message in the queue, the message is processed right away; however, if there are messages, the setTimeout message will have to wait for other messages to be processed. For that reason the second argument indicates a minimum time and not a guaranteed time
I've been writing some functional tests in Mocha, changing items and then checking if the changes propagated correctly. Currently, I'm using window timeouts to give Polymer time to update elements, but this feels like a hack. The developer guide outlines a few different observation hooks, but I'm not sure which one I should call.
The one that sounds the closest is a recommendation to attach an async call to a propertyChanged event. However, many items use propertyChanged, will attaching an async task to a propertyChanged event reliably call the async task after the element's methods attached to the original propertyChanged have been called?
Bonus points for information on whether the given solution is forward compatible with Polymer 1.0 (or .8/.9).
I was looking in the wrong place, the right place is the async portion of Polymer's testing how-to. The right function to use is flush(callback), which will "trigger a flush of any pending events and observations, ensuring that notification callbacks are dispatched after they have been processed."
Their documentation globs tests together, I prefer individual elements for each test-suite and each test. This is especially helpful when debugging functional tests as the changes are preserved and it's easier to setup break points:
before(function(done){
nonMatchingEl.search = "";
flush(done);
});
test('updates the "pre" property', function() {
assert.equal(nonMatchingEl.pre, 'prematch-hello-postmatchhello');
});
//test two ...
I just discovered nested functions in AS3 (yeah, late to the party) and am using them in a Flex project. I've always disliked having to use separate functions for essentially modal operations with eventListeners– adds clutter to code and separates operation logic, as well as not being able to easily reference local variables.
The example below for a user selecting a directory seems to work very well and is nice an compact but I am wondering if there are any issues I am not aware of with this approach. Also, with a non-modal operation (e.g. asynchronous like using a Loader), is it possible to use nested functions?
private var rootDirectory:File;
protected function rootBtn_clickHandler(event:MouseEvent):void
{
var tmp:File = File.desktopDirectory;
tmp.browseForDirectory("Set Project Folder");
tmp.addEventListener(Event.SELECT, onUserSelect);
tmp.addEventListener(Event.CANCEL, onUserCancel);
function onUserSelect(event:Event):void
{
tmp.removeEventListener(Event.SELECT, onUserSelect);
tmp.removeEventListener(Event.CANCEL, onUserCancel);
rootDirectory = event.target as File;
}
function onUserCancel(event:Event):void
{
tmp.removeEventListener(Event.SELECT, onUserSelect);
tmp.removeEventListener(Event.CANCEL, onUserCancel);
trace("user canceled");
}
}
There can be some caveats when using anonymous or nested functions.
The first and most important is garbage collection:
In your example, the only thing keeping your tmp object from being garbage collected is the SELECT and CANCEL listeners themselves. Since you are not setting the weak flag to true, this shouldn't be a problem, however, if you we're using the weak flag (tmp.addEventListener(Event.SELECT, onUserSelect,false,0,true)) then there is a decent change the tmp object would get garbage collected before the user SELECTS or CANCELS a file.
Also, it's imperative that you remove every listener that you attached in this way. You are doing that in your onUserCancel method, so it should be fine, but if you were not, then you would have a memory leak on your hands as every time your click handler ran, another instance of tmp would be created but it would never get garbage collected because of the listeners attached to it.
So to summarize, most people stay away from anonymous/nested methods in AS3 (and I generally/usually recommend that to people) because it's easy to create memory leaks or have your closures garbage collected by accident. There also may or not be performance differences, but I have never ran tests in that regard.
I'm new to programming and I've been checking a lot of game coding tutorials. I've noticed that on most of them they use custom events to trigger methods instead of calling a method directly.
What's the reasoning behind this practice? Why aren't they just calling the method?
For example:
We have two objects: A and B. A has method A.methodA() that B needs to use when X condition is triggered.
Why implement:
B dispatches an event to A that tells A to run A.methodA()
Instead of:
B uses A.methodA()
The main reason is separation of interests. When using events, class A doesn't need to know about the existence of class B (and vice versa).
Some benefits to this are:
Much easier unit testing (you can test Class A without class B)
Less chance of breaking your code when you change class A or B
Less references to other classes in your code, which reduces the potential for memory leaks
Cleaner code
More flexible/reusable code (a bunch of other classes could all listen/respond to the event without any additional code in the your dispatcher)
Typically in bigger applications using events will help abstract everything. When you have 15+ classes and they're all ditpatching events to a controller, it's a lot easier to figure out what's going on than reading through all different parts of the code to trace functions. Using callbacks begins to create spaghetti code.
However, direct function calls are going to be executed faster than events.
Personally, I use custom events simply for the ease of use. I can have one class dispatch an event when something happens (say an animation finishes or an error occurs in a download) and any number of other classes run any number of other functions based on that event. In addition, I code for reusability. The goal of each class is complete independence so that it can run in any project without needing other packages. So rather than have one class call a method of another class, I dispatch an event from the first class that the second class listens for and then run that method. Then when I need that first class for another project, I can just copy/paste it without having to modify it and without losing any functionality.
EDIT:
Also, it's worth noting that sometimes people do what you describe to get around having to pass in event arguments.
Say you have a button on the stage and you need to be able to click it, but you also need to be able to manually call that method. Some people don't realize you can pass in a null event and have only the single method. Or you can set it as a null default argument, see below:
private function onClickHandler( e:MouseEvent = null ):void{
//as long as you never reference "e" within this method, this method can be used both for MouseEvent listeners and manually calling it elsewhere in the code
}
That technique can help avoid having an event handler that only calls another method and nothing else. At this point in my programming, every single AS3 event handler I write sets the event argument to null by default. It just makes things easier later on.
You might want to read this.
And also note using the callback method allows you to pass parameters to it directly and not via a custom event model.
I built my own, very simplified, events dispatcher system. AS Event model is very powerful, but in 99% of situations you don't need that power. A simple callback with parameters fired as an event is more than enough. You can still retain the versatility from an event model, but don't need to write too many lines of code for, let's say, a simple button.
I can setup a simple event like this:
Buttonizer.autoButton(_buttQuit, this, "onPress");
public function onPressQuit(c:Sprite) {
// Execution goes here
}
You can build your own event model, it will make life simpler, and your code much more concise.