jQuery $(document).ready(); declaring all the functions in it - mootools

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($){
});

Related

LitElement lifecycle: before first render

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

Basic DOJO 1.8: How to get a reference to a method?

I'm am pretty new to DOJO 1.8 and would like to know how I can call a function from outside a require-method? I try to implement a message-box which fades in and out.
I created the method:
require(["dojo/dom", "dojo/on", "dojo/domReady!" ], function(dom, on, ready) {
/*function which shows a msg-box on top of the page */
var showMsg = function(text) {
dom.byId("msgbox").innerHTML = text;
}
});
OK! IT works....but I no I would like to call it from somewhere else in my application:
showMsg("Item saved");
But that doesn't work: Uncaught ReferenceError: showMsg is not defined
How do I get that reference?
Thank you for your help!
AFX
As things stand you're declaring a local variable and so it's not visible elsewhere in the program.
You could make the variable global, for example
window.showMsg = function(text) {
dom.byId("msgbox").innerHTML = text;
}
The downside of this approach is that as you application gets bigger you end up with more and more global variables and that makes maintenance harder.
So Dojo offers ways to package chunks of reusable code and refer to them. You are already exploiting some of those capabilities when you use "require" - you're getting access to chunks of dojo. You can make your own code visible as reusable chunks in the same way.
This is quite a big topic, but you could start by reading this
Another thing you can do is to move the require inside the function.
Even if you have many such functions, while it's annoying to repeat, there is essentially no runtime penalty for requiring over and over. The only thing to watch for is that code inside the function becomes asynchronous, so instead of returning a value you have to use a callback or promise.
Alternatively, if you're only using this function from within some event handlers (I see dojo/on), you can set them up within the scope of this same require block.

How to extend a native mootools method

Is it possible to extend the addEvent function in mootools to do something and also calls the normal addEvent method? Or if someone has a better way to do what I need I'm all years.
I have different 'click' handlers depending on which page I'm on the site. Also, there might be more than one on each page. I want to have every click on the page execute a piece of code, besides doing whatever that click listener will do. Adding that two lines on each of the handlers, would be a PITA to say the least, so I thought about overriding the addEvent that every time I add a 'click' listener it will create a new function executing the code and then calling the function.
Any idea how I could do it?
Whereas this is not impossible, it's a questionable practice--changing mootools internal apis. Unless you are well versed with mootools and follow dev direction on github and know your change won't break future compatibility, I would recommend against it.
The way I see it, you have two routes:
make a new Element method via implement that does your logic. eg: Element.addMyEvent that does your thing, then calls the normal element.addEvent after. this is preferable and has no real adverse effects (see above)
change the prototype directly. means you don't get to refactor any code and it will just work. this can mean others that get to work with your code will have difficulties following it as well as difficulties tracing/troubleshooting- think, somebody who knows mootools and the standard addEvent behaviour won't even think to check the prototypes if they get problems.
mootools 2.0 coming will likely INVALIDATE method 2 above if mootools moves away from Element.prototype modification in favour of a wrapper (for compatibility with other frameworks). Go back to method 1 :)
I think solution 1 is better and obvious.
as for 2: http://jsfiddle.net/dimitar/aTukP/
(function() {
// setup a proxy via the Element prototype.
var oldProto = Element.prototype.addEvent;
// you really need [Element, Document, Window] but this is fine.
Element.prototype.addEvent = function(type, fn, internal){
console.log("added " + type, this); // add new logic here. 'this' == element.
oldProto.apply(this, arguments);
};
})();
document.id("foo").addEvent("click", function(e) {
e.stop();
console.log("clicked");
console.log(e);
});
it is that simple. keep in mind Element.events also should go to document and window. also, this won't change the Events class mixin, for that you need to refactor Events.addEvent instead.

How to dyamically adding Elements to Mootools Form.Validator?

Currently I am using Form.Validator from Mootools 1.2.5 and Mootools-More 1.2.5, but i am having a hard time validating an Element's input when dynamically injected into the DOM after ondomready. I was wonder if there's a way to attach Form.Validator's functionalities to the newly inject Elements?
UPDATE:
Using what #Dimitar suggested i was able to fix the issue. I use the build in function getFields to repopulate/attach events to the dynamic Elements. formValidatorObj.watchFields(formValidatorObj.getFields()); Hope this will help some Mootooler's in the future!
i am not a big -more users but looking at the source code on github, this seems like a good guess:
https://github.com/mootools/mootools-more/blob/master/Source/Forms/Form.Validator.js#L161
i guess you can pass any element - dynamically created or otherwise.
formValidatorObj.watchFields([someElsCollection]); // or from form.getElements or whatever.
// dynamically add a new field...
formValidatorObj.watchFields([new Element("input.required[value=John]").inject(formValidatorObj.element, "top")]);

what is the programmatic parlance for this phenomenon?

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.