I would like to ask if there's any significant difference/performance issue for detecting using the following two methods:
Let's say we're testing for 3d transforms.
Using the new function that Modernizr 3 offers:
Modernizr.on('csstransforms3d', function(result) {
if (result) {
element.className = 'myFirstClass';
}
else {
element.className = 'mySecondClass';
}
});
And with the standard way:
if (Modernizr.csstransforms3d) {
element.className = 'myFirstClass';
} else {
element.className = 'mySecondClass'
}
The Modernizr.on function is only (or mainly) for asynchronous detects and deferred actions. See the full explanation and example by #stucox for more details.
csstransforms3d is not async, and available right away. There would be no reason to be using the on event callback method for it. The function is rather inefficient with setTimeout() calls which aren't good for performance.
Only use on for deferred events on async detects.
They aren't really comparable because depending on the situation, one will always be better suited than the other. Performance isn't really the issue.
The standard way, checking Boolean values in a Dictionary is an extremely fast operation. If you have a function that gets executed in reaction to some user interaction, this will be the best way to get feature info. For example:
$('#showVideo').on('click', function() {
if (Modernizr.video) {
// load HTML5 video
}
else {
// load Flash video
}
});
Similarly, listening to JS events is very efficient. What the new event-based model in Modernizr allows is for you to react to the Modernizr tests completing. This is great if your site needs to make changes ASAP when feature detection data is available. For example:
Modernizr.on('draganddrop', function(result) {
if (!result) {
alert('This site requires Drag and Drop. Please update your browser.')
}
});
Previously you had to watch for DOM updates on the <body> and check the classes in order to get this information.
Related
Currently, I record my voice with this simple code in Angular Component
speechToText() {
const {webkitSpeechRecognition}: IWindow = <IWindow>window;
const recognition = new webkitSpeechRecognition();
recognition.lang = 'en-US';
recognition.continuous = true;
recognition.interimResults = true;
recognition.onresult = event => {
for (let i = event.resultIndex; i < event.results.length; ++i) {
this.interim_transcript = event.results[i][0].transcript;
}
};
recognition.onerror = event => {
console.log('Error occured', event);
};
recognition.start();
}
}
And in my HTML I have the value bind to the interim result
<textarea #description mdInput rows="5" placeholder="Short Story" name="description" [value]="interim_transcript"></textarea>
The problem, however, is that I can see the text being put into the textarea only after I click on the textarea or outside of it to trigger dom update. How to make it update textarea as soon as I begin saying words giving this live text update, same way as here https://www.google.com/intl/en/chrome/demos/speech.html
This happens because Angular is not aware of the update to interim_transcript since it happens outside of what the Zone is aware of.
I see two immediate ways to fix it:
Run the interim_transcript update in a zone.run call. See NgZone in the docs.
Make interim_transcript an Observable. Actually a Subject, but the point is that it needs to be observable.
I'd recommend the latter, and it basically involves this:
When you define interim_transcript, define it like this: interim_transcript: new Subject<string>()
When you update it in the onresult callback, replace
this.interim_transcript = event.results[i][0].transcript;
with
this.interim_transcript.next(event.results[i][0].transcript);
Change the value binding in your template, replace:
[value]="interim_transcript"
with
[value]="interim_transcript | async"
Observables are an incredibly powerful concept that can make your code more easy to reason about (even though it seems very odd at first). It can boost your performance significantly when you start using the OnPush change detection mechanism. Finally, however cheesy it sounds, can change the way you think about your programs, to a data stream mind model instead of state updates. This will likely sound confusing and weird, but I strongly recommend looking into it, I'm sure it will pay off.
Here are a few good resources to get started:
Using Observable from Rangle.io.
Understand and Utilize the Async Pipe in Angular 2 from Brian Troncone
I am upgrading some older react component I inherited (v0.10.0) to work with the latest version of react (v0.14.8).
The following scenario stopped working:
// within a react component
onClick: function() {
// DO SOMETHING
}
getDefaultProps: function () {
return {
someProp: 'prop',
onClick: this.onClick
}
}
This is easily resolved moving the code into an anonymous function, like the following:
getDefaultProps: function () {
return {
someProp: 'prop',
onClick: function() {
//DO SOMETHING
}
}
}
My question is: why has the visibility of 'this' changed at that level and what's the best way to refactor this code? And what if I had-to/wanted-to use 'this' at that level?
Any help appreciated, as a disclaimer I am a react super-beginner!
The result of getDefaultProps() is shared across all instances of a component. That means that the result can't rely on any particular instance of the component. The reason it changed is likely because of the performance benefit from caching, although I can't say for sure.
As for refactoring the code, I'm not sure there's a silver-bullet here. From my perspective what you currently have seems like an anti-pattern. Props are meant to be passed in by consumers that have no knowledge of the inner workings of the component, so it seems odd that a default value for a prop would depend on the inner workings. Without knowing exactly what you're doing, I would say your best bet is to just use null as the default value for the prop, then check the value at runtime when you do have access to the this context.
handleSomeAction() {
if (!this.props.onClick) {
// DO SOMETHING
}
}
I've been reading up on web components and am pretty intrigued by the nascent spec. Does anyone know if there is any support for 2-way data binding in the DOM, without having to use Polymer? An example would be appreciated.
Object.observe is a potential new way to do databinding in javascript. This feature is scheduled for Ecmascript 7(javascript), but some browsers currently support it, check here. Also check out this html5rocks article on object.observe
No, data binding isn't part of the Web Components spec.
You can of course implement data binding yourself using native JavaScript event listeners, and possibly the Proxy object, but it's probably best not to re-invent the wheel: if you want data binding, choose one of the many JavaScript frameworks out there which supports that. Polymer, React, Angular, and Vue are some recent examples of such libraries.
I've been playing around with this over the last few days. You can create a StateObserver class, and extend your web components from that. A minimal implementation looks something like this:
// create a base class to handle state
class StateObserver extends HTMLElement {
constructor () {
super()
StateObserver.instances.push(this)
}
stateUpdate (update) {
StateObserver.lastState = StateObserver.state
StateObserver.state = update
StateObserver.instances.forEach((i) => {
if (!i.onStateUpdate) return
i.onStateUpdate(update, StateObserver.lastState)
})
}
}
StateObserver.instances = []
StateObserver.state = {}
StateObserver.lastState = {}
// create a web component which will react to state changes
class CustomReactive extends StateObserver {
onStateUpdate (state, lastState) {
if (state.someProp === lastState.someProp) return
this.innerHTML = `input is: ${state.someProp}`
}
}
customElements.define('custom-reactive', CustomReactive)
class CustomObserved extends StateObserver {
connectedCallback () {
this.querySelector('input').addEventListener('input', (e) => {
this.stateUpdate({ someProp: e.target.value })
})
}
}
customElements.define('custom-observed', CustomObserved)
<custom-observed>
<input>
</custom-observed>
<br />
<custom-reactive></custom-reactive>
fiddle here
I like this approach because it occurs directly between precisely those elements you want to communicate with, no dom traversal to find data- properties or whatever.
One way: $0.model = {data}; setter on $0 assigns $0.data, responding to the update, and the other way: $1.dispatchEvent(new CustomEvent('example', {detail: $1.data, cancelable: true, composed: true, bubbles: true})); with $0.addEventListenever('example', handler) gives 2 way data binding. The data object is the same, shared on 2 elements, events and setters allow responding to updates. To intercept updates to an object a Proxy works model = new Proxy(data, {set: function(data, key, value){ data[key] = value; ...respond... return true; }}) or other techniques. This addresses simple scenarios. You might also consider looking at and reading the source for Redux, it provides conventions that seem relatively popular. As Ajedi32 mentions reinventing the wheel for more complex scenarios is not so practical, unless it's an academic interest.
I'm trying to use the placeholder="xxx" attribute in my web application, and I don't want to have a special visual for IE9. Can people throw out some good suggestions for achieving this functionality in IE9?
I've found a couple links on here but none of the suggested scripts were sufficient... and the answers were from mid-2011, so I figured maybe there is a better solution out there. Perhaps with a widely-adopted jQuery plugin? I do not want to use anything that requires intrusive code such as requiring a certain css class or something.
Thanks.
EDIT - I also need this to work for password input fields.
// the below snippet should work, but isn't.
$(document).ready(function() {
initPlaceholders()();
}
function initPlaceholders() {
$.support.placeholder = false;
var test = document.createElement('input');
if ('placeholder' in test) {
$.support.placeholder = true;
return function() { }
} else {
return function() {
$(function() {
var active = document.activeElement;
$('form').delegate(':text, :password', 'focus', function() {
var _placeholder = $(this).attr('placeholder'),
_val = $(this).val();
if (_placeholder != '' && _val == _placeholder) {
$(this).val('').removeClass('hasPlaceholder');
}
}).delegate(':text, :password', 'blur', function() {
var _placeholder = $(this).attr('placeholder'),
_val = $(this).val();
if (_placeholder != '' && (_val == '' || _val == _placeholder)) {
$(this).val(_placeholder).addClass('hasPlaceholder');
}
}).submit(function() {
$(this).find('.hasPlaceholder').each(function() { $(this).val(''); });
});
$(':text, :password').blur();
$(active).focus();
});
}
}
}
We just researched the same thing. We decided on reusing this gist, by Aaron McCall, after making some minor changes. The main advantage is that it's simple, easy to understand code:
Remove the kernel and setup_placeholders parts. Just call it immediately in an anonymous function.
Add var before test.
For browsers that support placeholder, it simply falls back to that. It also handles new input elements (note the use of delegate) in existing forms. But does not handle dynamic new form elements. It could probably be modified to do so with jQuery.on.
If you don't like this one, you can use one of the ones here. However, some of them are overcomplicated, or have questionable design decisions like setTimeout for detecting new elements.
Note that it needs to use two pairs of parens, since you're calling an anonymous function, then calling the returned function (this could be factored out differently):
(function () {
// ...
})()();
I wrote a jquery plugin a while back that adds the placeholder support to any browser that does not support it and does nothing in those that do.
Placeholder Plugin
Here's a jQuery plugin that works with password fields as well. It's not as tiny as the code suggested by Matthew but it has a few more fixes in it. I've used this successfully together with H5Validate as well.
http://webcloud.se/code/jQuery-Placeholder/
I see that Lifehacker is able to change the url while using AJAX to update part of the page. I guess that can be implemented using HTML5 or history.js plugin, but I guess lifehacker is using neither.
Does any one has a clue on how they do it?
I am new to AJAX and just managed to update part of the page using Ajax.
Thank you #Robin Anderson for a detailed step by step algo. I tried it and it is working fine. However, before I can test it on production, I would like to run by you the code that I have. Did I do everything right?
<script type="text/javascript">
var httpRequest;
var globalurl;
function makeRequest(url) {
globalurl = url;
/* my custom script that retrieves original page without formatting (just data, no templates) */
finalurl = '/content.php?fname=' + url ;
if(window.XMLHttpRequest){httpRequest=new XMLHttpRequest}else if(window.ActiveXObject){try{httpRequest=new ActiveXObject("Msxml2.XMLHTTP")}catch(e){try{httpRequest=new ActiveXObject("Microsoft.XMLHTTP")}catch(e){}}}
/* if no html5 support, just load the page without ajax*/
if (!(httpRequest && window.history && window.history.pushState)) {
document.href = url;
return false;
}
httpRequest.onreadystatechange = alertContents;
alert(finalurl); /* to make sure, content is being retrieved from ajax */
httpRequest.open('GET', finalurl);
httpRequest.send();
}
/* for support to back button and forward button in browser */
window.onpopstate = function(event) {
if (event.state !== null) {
document.getElementById("ajright").innerHTML = event.state.data;
} else {
document.location.href = globalurl;
return false;
};
};
/* display content in div */
function alertContents() {
if (httpRequest.readyState === 4) {
if (httpRequest.status === 200) {
var stateObj = { data: httpRequest.responseText};
history.pushState(stateObj, "", globalurl);
document.getElementById("ajright").innerHTML = httpRequest.responseText;
} else {
alert('There was a problem with the request.');
}
}
}
</script>
PS: I do not know how to paste code in comment, so I added it here.
It is not an requirement to have the markup as HTML5 in order to use the history API in the browser even if it is an HTML5 feature.
One really quick and simple implementation of making all page transistions load with AJAX is:
Hook up all links except where rel="external" exist to the function "ChangePage"
When ChangePage is triggered, check if history API is supported in the browser.
If history API isn't supported, do either push a hashtag or make a normal full page load as fallback.
If history API is supported:
Prevent the normal link behaviour.
Push the new URL to the browser history.
Make a AJAX request to the new URL and fetch its content.
Look for your content div (or similar element) in the response, take the HTML from that and replace the HTML of the corresponding element on the current page with the new one.
This will be easy to implement, easy to manage caches and work well with Google's robots, the downside is that is isn't that "optimized" and it will be some overhead on the responses (compared to a more complex solution) when you change pages.
Will also have backward compatibility, so old browsers or "non javascript visitors" will just get normal page loads.
Interesting links on the subject
History API Compatibility in different browsers
Mozillas documentation of the History API
Edit:
Another thing worth mentioning is that you shouldn't use this together with ASP .Net Web Forms applications, will probably screw up the postback handling.
Code addition:
I have put together a small demo of this functionality which you can find here.
It simply uses HTML, Javascript (jQuery) and a tiny bit of CSS, I would probably recommend you to test it before using it. But I have checked it some in Chrome and it seems to work decent.
Some testing I would recommend is:
Test in the good browsers, Chrome and Firefox.
Test it in a legacy browser such as IE7
Test it without Javascript enabled (just install Noscript or similar to Chrome/Firefox)
Here is the javascript I used to achieve this, you can find the full source in the demo above.
/*
The arguments are:
url: The url to pull new content from
doPushState: If a new state should be pushed to the browser, true on links and false on normal state changes such as forward and back.
*/
function changePage(url, doPushState, defaultEvent)
{
if (!history.pushState) { //Compatability check
return true; //pushState isn't supported, fallback to normal page load
}
if (defaultEvent != null) {
defaultEvent.preventDefault(); //Someone passed in a default event, stop it from executing
}
if (doPushState) { //If we are supposed to push the state or not
var stateObj = { type: "custom" };
history.pushState(stateObj, "Title", url); //Push the new state to the browser
}
//Make a GET request to the url which was passed in
$.get(url, function(response) {
var newContent = $(response).find(".content"); //Find the content section of the response
var contentWrapper = $("#content-wrapper"); //Find the content-wrapper where we are supposed to change the content.
var oldContent = contentWrapper.find(".content"); //Find the old content which we should replace.
oldContent.fadeOut(300, function() { //Make a pretty fade out of the old content
oldContent.remove(); //Remove it once it is done
contentWrapper.append(newContent.hide()); //Add our new content, hidden
newContent.fadeIn(300); //Fade it in!
});
});
}
//We hook up our events in here
$(function() {
$(".generated").html(new Date().getTime()); //This is just to present that it's actually working.
//Bind all links to use our changePage function except rel="external"
$("a[rel!='external']").live("click", function (e) {
changePage($(this).attr("href"), true, e);
});
//Bind "popstate", it is the browsers back and forward
window.onpopstate = function (e) {
if (e.state != null) {
changePage(document.location, false, null);
}
}
});
The DOCTYPE has no effect on which features the page can use.
They probably use the HTML5 History API directly.