Detecting if the user preference is light or dark color theme is pretty easy with the prefers-color-scheme CSS media feature, below code gives more details on the same.
User preferences can also vary by medium. For example, a user may prefer dark themes on a glowing screen, but light themes when printing (to save ink and/or because inked text on blank paper prints better than blank letterforms knocked out of an inked background). UAs are expected to take such variances into consideration so that prefers-color-scheme reflects preferences appropriate to the medium rather than preferences taken out of context.
We would normally track if a DOM element is visible in the viewport or not to understand user behaviour or to operate on the elment based on visibilty (animation, ajax calls etc).
We would normally apply a function like below to detect if an element is visible in the viewport:
// From the specconstobserver=newIntersectionObserver(changes=>{for(constchangeofchanges){console.log(change.time);// Timestamp when the change occurredconsole.log(change.rootBounds);// Unclipped area of rootconsole.log(change.boundingClientRect);// target.boundingClientRect()console.log(change.intersectionRect);// boundingClientRect, clipped by its containing block ancestors, and intersected with rootBoundsconsole.log(change.intersectionRatio);// Ratio of intersectionRect area to boundingClientRect areaconsole.log(change.target);// the Element target}},{});// Watch for intersection.observer.observe(target);// Stop watching.observer.unobserve(target);// Stop observing.observer.disconnect();
Say, if we were to observe this element, #catBox for visiblity, we would end up with:
Portals takes the best from SPA and MPA to provide users with a top level portal browsing context which can embedded in an HTML document.
A portal is similar to an iframe, in that it allows another browsing context to be embedded. However, the portal browsing context hosted by a portal is part of a separate unit of related browsing contexts. The user agent is thus free to use a separate event loop for the browsing contexts,even if they are same origin-domain.
At times we would want to communicate with the intial host and the portal and vice versa, it can be easily achived with the below:
In the host:
123456
constportal=document.querySelector('portal');portal.activate({data:{foo:"bar"}}).then(()=>{window.portalHost.onmessage=evn=>{console.log(e.data);// data from the portal}});
We can also get other information from the event:
123456789101112
{origin:evn.origin,data:evn.data,sourceIsPortalHost:evn.source===window.portalHost,gotUserActivation:!!evn.userActivation,userActivation:{isActive:evn.userActivation&&evn.userActivation.isActive,hasBeenActive:evn.userActivation&&evn.userActivation.hasBeenActive}};// ^ from WPT
In the portal:
123456
window.addEventListener('portalactivate',(evt)=>{letpredecessor=evt.adoptPredecessor();evt.datapredecessor.postMessage("data","*");// ^ predecessor would be an instanceof HTMLPortalElement});
With portal.activate we can basically pass the {data} to the portal on activation and the portal shall receive this data in the event object of the portalactivate callback.
evt.adoptPredecessor() will provide context to the originator of the portal and portalHost is exposed if the window has a portal browsing context.
Let us say that src/component in dependent on lib/util.js, in current world one would have to do the below to require the util in their component
1
constutil=require('../../lib/uitl.js');
The nesting for those realtive paths ../../ gets more complex as the directory structure gets more deeper.
For our rescue the module object of node got an addition of createRequireFromPath method in v10.12.0, which accepts a
filenameto be used to construct the relative require function.
and return a require function.
This can help in doing the below in our src/component, rather than dealing with relative paths.
try{thrownewError("End of life!");}catch{// ✋console.log("^ no params for catch, you are dead anyway!");}
JSON ⊂ ECMAScript
123
// Without the proposal:"foo<U+2028>bar<U+2029>baz"// → SyntaxError
123
// With the proposal:"foo<U+2028>bar<U+2029>baz"// does not throw
well-formed JSON.stringify
12
JSON.stringify('\uD800');// → '"\\ud800"'
Function#toString
12345
function/* this is bar */bar(){}bar.toString();// 'function /* this is bar */ foo () {}'// ^ perviously this was not the case.
Array#sort stability
123456789101112
[{name:"Jan",age:20},{name:"Jhon",age:20},{name:"David",age:18},{name:"Ram",age:18},{name:"Sita",age:18},{name:"Ravan",age:18},{name:"Asura",age:12},{name:"Milly",age:12},].sort((m,n)=>m.age-n.age));// People with the same age retain their order.
flipBtn.addEventListener('click',function(){// we need to flip, stop everythingvideoElm.pause()videoElm.srcObject=null// toggle \ flipshouldFaceUser=!shouldFaceUser;capture();})