I was drawn to the idea of a "VanillaJS" approach mentioned by http://customelements.io/ for https://github.com/webcomponents/element-boilerplate . This drew me to http://www.polymer-project.org/platform/custom-elements.html (since I would like to do everything I can in JavaScript rather than use <link/> to do imports).
However, it seems that, contrary to the spirit of VanillaJS and polyfills, they seem to require their own custom "WebComponentsReady" event. (To me a polyfill is something which completely follows a standard or proposed standard, and lets you merely remove a script tag or load when it is fully supported and not need to change any other code.)
(Mozilla's x-tag (which is also not clear on whether it can be used purely as a polyfill or whether one requires the xtag global) uses a "DOMComponentsLoaded" event which I am not clear is standard.)
Neither event is mentioned at http://www.w3.org/TR/custom-elements/
Any way to work with these to use a standard event or avoid these otherwise without polling?
UPDATE
I see from http://lists.w3.org/Archives/Public/public-webapps/2013JulSep/0697.html that the "WebComponentsReady" event was discussed as being a candidate for specification but had not (at least at that time) been added, so I guess this event may be the safest bet since Mozilla's x-tag does use it internally immediately before firing its own "DOMComponentsLoaded" event and it was at least discussed as a possible candidate for standardization. :)
Neither event is part of the standards. Both Polymer's WebComponentsReady and x-tag's DOMComponentsLoaded are fired for convenience. This is one of those things you'd have to do yourself without a sugaring library. I suspect x-tag's fires hooks into the WebComponentsReady event because it uses the same set of polyfills as Polymer.
BTW, one reason to use an HTML Import (<link rel="import">) to load components is that you get aload` event. That could be one signal the component is ready.
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
What invalidateProperties(), invalidateSize() and invalidateDisplayList() methods are did when extending a component in adobe flex/air ?.
And why these are necessary?
As per the documentation, these functions signal flex/flash to call another function before updating and rendering the display list. This "other function" seems to be for validation (and possibly altering the values if they're incorrect). So by calling an invalidate function, you force a recalculation. Or, in other words, a redraw. This removes any left over graphical artifacts.
That's my explanation via the documentation. Perhaps someone with more experience can build upon my answer.
All these components are based upon the RENDER event so no matter how many changes they go through (ex: x, y, width, etc ...) they are drawn only once per frame. But to get the RENDER event to trigger for each component a stage.invalidate() must be called and parsed on a per component basis. All the component invalidate methods allow you to force a redrawing of the component by skying the RENDER event step or in other cases by starting the RENDER event workflow.
I'm currently deciding between two different approaches for generating HTML with event handlers. I know both approaches are viable (I've seen both used before), but I'm unclear on their respective advantages, and since I'll be stuck with whichever one I pick I was hoping someone might be able to clarify those advantages for me.
Here's a simplistic example to explain the idea (although my real world cases will of course be more complex). Let's say we want to have a button that alerts "Hello Bob". The first approach is to use our view logic to generate the HTML, and then rely on a separate, high-level event handler:
$('body').append('<button class="nameAlert" data-name="Bob">Click me</button>')
$('body').on('click .nameAlert', function(e) {
alert('Hello ' + $(e.target).data('name'));
})
The second approach is to build an element object, bind a handler to it, and then append it to the DOM, all at once:
var $button = $('<button>Click me</button');
var name = "Bob";
$button.on('click', function(e) {
alert('Hello ' + name);
});
$('body').append($button);
There are some obvious advantages to the latter approach (eg. no writing data attributes, all the logic is one place) but I'm really curious about the non-obvious advantages (eg. the first version will perform better if we wind up with a lot of these buttons on the page). I'm especially interested in maintainability (that should be a programmer's first priority, right?).
Thanks in advance for any help.
I think what you are asking about is event delegation. Event delegation allows you to bind the event handler on a parent DOM element and handle events that occur within it. There are a number of benefits from this pattern, not the greatest of which is less repetitive code:
Efficiency. The browser does not have to attach event handlers to multiple dom elements.
Memory Leaks. It helps avoid memory leaks caused by dom elements being removed from the DOM that still have a javascript object referring to them. Since your parent element typically stays in the DOM as its children change, this doesn't happen.
Live binding. Event delegation will fire on any descendent node that matches the delegation selector, which means they can be added after the fact and still work.
I'm sure there are other benefits but those are some of the primary reasons for choosing event delegation.
I see that in an ide like FlashDevelop, when I add an event listener to certain objects, it'll auto-populate with the event strings that this object will dispatch (I'm assuming, anyway). I'd love to do this with my custom objects (esp. when it comes to sharing this code with co-workers), to clear up possible confusion as to what to listen for.
Does anyone know how to discern which events will be dispatched?
Thanks,
I don't think there is a way to link suggestions to a method call as strictly as exists with the inbuilt stuff like addEventListener(), but that shouldn't stop you from producing perfectly readable code for you and your colleagues (especially if you are using FlashDevelop).
For starters, using your own event class with static properties representing the event strings you can use will provide a useful code hint by default:
From here, you can add code comments that work with FlashDevelop to produce a very precise tooltip:
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($){
});