Last Updated on January 27, 2022
- Execution context references the ‘environment’ a function executes in; that is, variable scope (and the scope chain, variables in closures from outer scopes), function arguments, and the value of the
this
object. - Lexical scope is the concept that every inner level can access its outer levels
- Hoisting: The way in which the JavaScript interpreter declares variables at the top of the function it is contained in (the current scope.) And to clarify – declared not initialed (assigned) a value. This results in some variables being accessible even though they are not yet physically declared in the code. Common practice in JS is to always declare your vars at the top of your scope to avoid confusion.
- Here’s a list of different hoisting scenarios.
- Hoisting function variables:
foo() function foo() { console.log('hi!') // works }
foo() var foo = function() { console.log('hi!') // does not work }
Hoisting regular variables:
var a = 1; function b() { a = 10; // return; f(); function f() { console.log('f ' + a); } } b(); console.log('a ' + a);
- Function expressions is declaring and assigning the function to a var at the same time:
var getRectArea = function(width, height) { return width * height; }
- .call, .bind and .apply:
// CALL function greet() { var reply = [this.person, 'is an', this.role].join(' '); console.log(reply); } var i = { person: 'Peter', role: 'person' }; greet.call(i); // ---------------------------------------- // BIND: Does not run function, but returns a function you can run later. var test = { logName: function(name) { console.log(name); }, logNumber: function(num1, num2) { console.log(num1 + num2); } } var logString = test.logName.bind(test); // So you have to run it explicitly. logString('peter'); // ---------------------------------------- // Apply, you can write a method once and then inherit it in another object, // without having to rewrite the method for the new object. var newObj = { do: function(num1, num2) { test.logNumber.apply(this, [num1, 5]) } } // APPLY: BINDS and RUNS (no need to run) newObj.do(5);
- Prototype and Constructors:
// Prototype Access var temp = { name: '', logName: function(n) { console.log(n); } } var dillon = Object.create(temp); dillon.logName('hi'); var defaultObjectPrototype = Object.getPrototypeOf(dillon); console.log( defaultObjectPrototype.hasOwnProperty('hi') ); console.log( Object.getPrototypeOf(defaultObjectPrototype) ); //------------------------------------ // Constructor Usage // Use capital case for constr functions... function Person(name) { this.name = name } Person.prototype.logName = function(lastname) { console.log(this.name + ' ' + lastname) } Person.prototype.occupation = function(occ) { console.log(this.name + ' works as a ' + occ) } var me = new Person('Peter'); console.log( me.logName('Dillon') ); console.log( me.occupation('web dev') );
- Event Delegation: You place the event listener on the parent to capture the bubbled event – imagine a table of 1000 rows. The callback function lets you handle it in any way.
https://codepen.io/peterdillon/pen/jWGwKz - typeof
var str = 'hello'; String.prototype.myMethod = function() { return typeof this; } str.myMethod() // returns "object" console.log( str.includes('e') ); // typeof str // returns "string" // Because behind the scenes, String creates a string object // in order the give you methods that work on string // Like this: var tempObj = new String('your current string');
- Object.prototype.toString()
function Dog(name, species) { this.name = name; this.species = species; } dog1 = new Dog('Gabby', 'Dog'); Dog.prototype.toString = function dogToString() { return this.name, this.species; } console.log(dog1.toString());
- Traversal up, down, left and right: View Pen
- Manipulation – add, remove, copy, and create nodes in the DOM tree.
- Change the text content of a node and toggle, remove or add a CSS classname. View Pen
- Explain:
role=”button”
Can make any element (span, div etc.) behave as a button control to a screen reader,role=”presentation”
Removes any semantic meaning so screen readers don’t react to it semantically. - HTTP requests – GET and POST along with associated headers such as Cache-Control, ETag, Status Codes, and Transfer-Encoding.
- Security – JSONP, CORs, and iFrame policies View Pen
- REST vs RPC:
The fundamental problem with RPC is coupling. RPC clients become tightly coupled to service implementation in several ways and it becomes very hard to change service implementation without breaking clients: - Clients are required to know procedure names;
- Procedure parameters order, types and count matters. It’s not that easy to change procedure signatures(number of arguments, order of arguments, argument types etc…) on server side without breaking client implementations;
- RPC style doesn’t expose anything but procedure endpoints + procedure arguments. It’s impossible for client to determine what can be done next.
- On the other hand in REST style it’s very easy to guide clients by including control information in representations (HTTP headers + representation). For example:
- It’s possible (and actually mandatory) to embed links annotated with link relation types which convey meanings of these URIs;
- Client implementations do not need to depend on particular procedure names and arguments. Instead, clients depend on message formats. This creates possibility to use already implemented libraries for particular media formats. It’s possible to easily change URIs without breaking clients as far as they only depend on registered (or domain specific) link relations;
- It’s possible to embed form-like structures in representations, giving clients the possibility to expose these descriptions as UI capabilities if the end user is human;
- Support for caching is additional advantage;
- Standardised status codes;