These are from the knockoutjs.com tutorials.
Can anyone explain what the "this" at the end of the fullName property does? Please mention the JS principle at work here so that I may read about further, thanks!
Why does the totalSurcharge property not need the "this" at the end?
The second argument to a ko.computed sets the value of this when the function to determine the computed's value (the first arg) is executed. In the fullName case, the function uses this.firstName and this.lastName. So, whenever it is called we want to make sure that this is indeed our viewmodel.
In the second case, a variable called self was created that points to the appropriate value of this. Then, self is used inside the computed's function rather than using this (which is dynamic). In the second case, self could have been put as the second argument and then this could have been used inside the function.
This is really a matter of style. In my opinion, the use of a variable like self has fallen out of style these days. In the end, it comes down to personal preference.
Here is another answer that discusses this in KO as well: Difference between knockout View Models declared as object literals vs functions
Good tutorial on this in JavaScript here: https://derickbailey.com/email-courses/masteringthis/
Related
Is there a way to execute a method exactly after the component has its properties available but before the first render?
I mean something between the class contructor() and firstUpdated().
It sounds trivial, maybe in fact I'm missing something trivial..
The element's constructor is called when the element is created, either through the HTML parser, or for example through document.createElement
The next callback is connectedCallback which is called when the DOM node is connected to the document. At this point, you have access to the element's light DOM. Make sure to call super.connectedCallback() before doing your own work, as the LitElement instance has some work to do here.
The next callback is shouldUpdate, which is an optional predicate that informs whether or not LitElement should run its render cycle. Useful if for example, you have a single observed data property and destructure deep properties of it in render. I've found that it's best to treat this one as a predicate, and not to add all sorts of lifecycle logic inside.
After that, update and render are called, then updated and firstUpdated. It's generally considered bad practice to perform side effects in render, and the occasions that you really need to override update are rare.
In your case, it sounds very much like you should do your work in connectedCallback, unless you are relying on LitElement's rendered shadow DOM, in which case, you might consider running your code in firstUpdated, then calling this.requestUpdate() to force a second update (or changing some observed property in firstUpdated)
More info: https://lit-element.polymer-project.org/guide/lifecycle
Where can I find a full API reference for PolymerElements?
For example, the description for PaperDialogBehavior says
Use the dialog-dismiss and dialog-confirm attributes on interactive controls to close the dialog. If the user dismisses the dialog with dialog-confirm, the closingReason will update to include confirmed: true.
But I can't find any further information anywhere about what closingReason actually is (a property? a parameter passed to some callback?) and how it "includes" confirmed: true.
Instead of wasting time on guessing how to do every single little thing when using Polymer, it would be nice to have an actual API reference. Is there one?
There isn't any further information. Documentation isn't well written and you have to find many things on your own. Just remember that everything in Polymer is about properties. So closingReson is property that you can access on paper-dialog (or any other elements using paperDialogBehavior).
This property contains object {confirmed: true|false}
Truly said, behaviors has extremely badly written documentations. It is very confusing. For example:
modal: boolean = false
If modal is true, this implies no-cancel-on-outside-click, no-cancel-on-esc-key and with-backdrop.
but none of those properties are specified in paperDialogBehavior, because it is inherited from iron-overlay-behavior. And these inheritences are not documented (mostly).
I can get my <iron-meta> instance to work properly when using a static value. But when I bind the value to a dynamic variable (using {{}}) it <iron-meta> no longer behaves as expected.
Does <iron-meta> support binding its value to dynamic variables?
<iron-meta id="meta" key="info" value="foo/bar"></iron-meta> // works
<iron-meta id="meta" key="info" value="{{str}}"></iron-meta> // fails
Previous work
This question is a refinement of this question in order to clarify that the ONLY thing causing the problem is the change from a static string value to a dynamic string value binding. I was getting a lot of other suggesting that had nothing to do with the change from static to dynamic so I thought it might be best to rewrite the question to clarify that. But the entire code context is contained in the links there if that would help.
Alternative solutions
There has been some recent chatter about using <iron-localstorage>. Perhaps that is the best way to go for dynamic binding essentially creating global variables?
Yes, <iron-meta> does support binding to variables, but perhaps not in the way you think.
Example: http://plnkr.co/edit/QdNepDrg9b3eCTWF6oRO?p=preview
I looked through your code here, here, and here but I'm not entirely clear what your expectations are. Hopefully my attached repro might shed some light. I see you have declaratively bound <iron-meta id="meta" key="route" xvalue="foo-bar" value="{{route}}"></iron-meta> which is fine - when route changes, iron-meta's key="route" will update accordingly.
However, be aware that in Polymer 1.0, <iron-meta> is in essence a one-way bind from parent to child in the sense that you set a meta key value dynamically by binding to a property; but to get that value, you'll have to get it imperatively via iron-meta's byKey() method.
<iron-meta> is just a simple monostate pattern implementation without an in-built path notification mechanism. What this means is value changes do not propagate upwards. Therefore, doing something like
<!-- this does not work like the way you think -->
<iron-meta id="meta" key="foo" value="{{bar}}">
in order to get the value of foo, or listen to changes to foo, does not work. This behaves more like a setter, where you set the value of foo based on your data-bound property bar.
From what I gather, it seems that you're trying to implement some sort of global variable functionality. A monostate implementation used to work in Polymer 0.5, but not in 1.0. Unfortunately, until Google endorses a "best-practice" pattern for this, suggestions till-date seems a bit speculative to me. You might find this (Polymer 1.0 Global Variables) helpful.
I have had success using <iron-signals> to communicate global information. I know there is a warning in the <iron-signals> documentation that discourages its use for related elements, but when broadcasting a shared resource it seems just the thing. For example:
// source element
var db = SomeDB.init();
this.fire('iron-signal', { name: 'database', data: db });
<-- sink element -->
<iron-signals on-iron-signal-database="dbChange"></iron-signals>
class SinkElement {
dbChange(e, detail) {
this.db = detail;
this.db.getSomeData();
}
}
Here is javascript code (jquery) for adding a row of images:
var tr = $('<tr>');
var td = '<td><img src="myimg.jpg"/></td>';
tr.append(td).append(td).append(td);
$('#mytable tbody tr:eq(0)').before(tr);
tr.empty(); //I really don't need this line...
Technically tr.empty() shouldn't have worked. It actually does the opposite of what I want. What is the techinical term for this behaviour - You've added tr to the DOM, but any jquery function calls to that object still works, where as you'd normally not expect it to work i.e. make changes to the DOM?
I think you have a case of a shared mutable object. You are modifying the object in one place and are surprised to see the changes visible in another place. It's not technically wrong; it's just what happens when you have multiple references to an object that can be modified.
If there is a particular term for this other than 'object reference', I don't know what it is. I'd suggest that your expectation:
any jquery function calls to that object still works, where as you'd normally not expect it to work i.e. make changes to the DOM?
should be adjusted - for object variables, one should expect that whichever particular reference a change is made through, all references see the updated object.
Explanation:
i have few objects and im declaring them inside $(document).ready(). WHY? because in thous objects i have many jquery methods $(..), obviously they can work outside too, but when i include mootool, then it stop working. i tried noConflict and some other things, nothing works, only if i change the $() to jQuery() or to $j().. and i dont want to change for my 20 files and more then 2000 lines for each file. anyway declaring my objects inside $(document).ready(). made them work just fine.
Now My Question is:
if i declare all these objects inside the $(document).ready() method, would it make my site slow? or would it make things slow from client side? thats the only concern in my mind.
I don't see how doing that would make your site slow. By declaring them within the $().ready you're simply restricting the scope of your declarations to that particular $().ready function, thus they won't be available from within the scopes of other ready functions on the same page - which should not really be a bother if your application is well-designed and you've stuck to one per page.
Oh, and your declarations certainly won't have been been parsed until the DOM is fully loaded, (as you know, $().ready only executes once the DOM has loaded), but that too should not be a problem as you're only utilizing them from within a ready function (at least I hope).
Do you really need two libraries? If it's just one or two little tidbits of functionality you are using from one of those libraries chances are you can mimic that behaviour using the one you're making the greatest use of. If you can possibly/feasibly do that it will make your life so much simpler.
Doing everything in jQuery.ready will not slow down your site.
As an alternative solution, you could replace $ with jQuery in all of your jQuery code, or you could wrap it in a function like this:
(function($) {
$('whatever').something();
})(jQuery);
This code makes a function that takes a paremeter called $, and calls that function with the jQuery object. The $ parameter will hide mootools' global $ object within the scope of the function, allowing you to write normal jQuery code inside the function.
Just declare
jQuery.noConflict before the document.ready request, then alias the jQuery method to $ within in the document.ready...
jQuery.noConflict();
jQuery(document).ready(function($){
});