Fundamental JavaScript You Need to know

JavaScript a language which works in a multiple way and makes its self quite interesting by its multipurpose activity.

Fundamental Js

Js has 2 kinds of values as the first one is ​Primitive Values​, and
then there are ​Objects and Functions​.​ But it has 9 separate types in this two values.

● Undefined​ (undefined), used for unintentionally missing values.
● Null​ (null), used for intentionally missing values.
● Booleans​ (true and false), used for logical operations.
● Numbers​ (-100, 3.14, and others), used for math calculations.
● Strings​ (“hello”, “abracadabra”, and others), used for text.
● Symbols​ (uncommon), used to hide implementation details.
● BigInts​ (uncommon and new), used for math on big numbers.

● Objects​ ({} and others), used to group related data and code.
● Functions​ (x => x * 3 and others), used to refer to code.

In this types Null And Undefined are the lonely one.

If we ask questions in expressions to Js they give us the answer.For example, the 3+ 3 expression is answered with 6.

We can inspect the type of any element by using expression typeof . For example, typeof(5) is the string value “number”.

Error handling,Using “try..catch”………….

The try..catch construct has two main blocks:The one is try, and then catch:

try..catch

The JavaScript engine first reads the code that is written, and then runs it. The errors that occur on the reading phase are called “parse-time” errors and are unrecoverable (from inside that code). That’s because the engine can’t understand the code at all.

So, try..catch can only handle errors that occur in valid code. Such errors are called “runtime errors” or, sometimes, “exceptions”.

If an exception happens in “scheduled” code, like in setTimeout, then try..catch won’t catch it:If an exception happens in “scheduled” code, like in setTimeout, then try..catch won’t catch it.

Coding Style

Code Must be always neat and clean. Our code is our one kind of identity . Its an one kind of art.

To write a clean code we need to follow this:

Syntax:

Curly Braces

In most JavaScript projects we see curly braces are written in “Egyptian” style with the opening brace on the same line as the corresponding keyword — not on a new line. There should also be a space before the opening bracket.

Line Length

No one likes to read a long horizontal line of code which is a boring task. It’s best practice to split a long horizontal line.

Indents

There are two types of indents:

Horizontal indents: 2 or 4 spaces.

Vertical indents: empty lines for splitting code into logical blocks.

Semicolons

A semicolon should be present after each statement, even if it could possibly be skipped though it is barely used in JavaScript.

Nesting Levels

One should try to avoid nesting code too many levels deep.

Function Placement

If one is writing several “helper” functions and the code that uses them, there are three ways to organize the functions.

1. Declare the functions above the code that uses them.
2. First Code , then functions
3. Mixed: a function is declared where it’s first used.

Style Guides

A style guide contains general rules about “how to write” code, e.g. which quotes to use, how many spaces to indent, the maximal line length, etc. A lot of minor things.

Automated Linters

Linters are tools that can automatically check the style of your code and make improving suggestions.

Comments

As we know, comments can be single-line: starting with // and multiline: /* ... */.

We normally use them to describe how and why the code works.

Bad comments

Novices tend to use comments to explain “what is going on in the code”.But in good code, the amount of such “explanatory” comments should be at minimum.

Recipe: factor out functions

Sometimes it’s beneficial to replace a code piece with a function.

Good comments

There are two types of good comments. They are:

1. Describe the architecture
2. Document function parameters and usage

What is cross browser testing?

Cross browser testing is the practice of making sure that the web sites and web apps you create work across an acceptable number of web browsers. As a web developer, it is your responsibility to make sure that not only do your projects work, but they work for all your users, no matter what browser, device, or additional assistive tools they are using. You need to think about:

• Different browsers other than the one or two that you use regularly on your devices, including slightly older browsers that some people might still be using, which don’t support all the latest, shiniest CSS and JavaScript features.
• Different devices with different capabilities, from the latest greatest tablets and smartphones, through smart TVs, right down to cheap tablets and even older feature phones that may run browsers with limited capabilities.
• People with disabilities, who use the Web with the aid of assistive technologies like screenreaders, or don’t use a mouse (some people use only the keyboard).

Cross browser issues commonly occur because:

• sometimes browsers have bugs, or implement features differently. This situation is a lot less bad than it used to be; back when IE4 and Netscape 4 were competing to be the dominant browser in the 1990s, browser companies deliberately implemented things differently to each other to try to gain competitive advantage, which made life hell for developers. Browsers are much better at following standards these days, but differences and bugs still creep through sometimes.
• some browsers may have different levels of support for technology features than others. This is inevitable when you are dealing with bleeding edge features that browsers are just getting round to implementing, or if you have to support really old browsers that are no longer being developed, which may have been frozen (i.e. no more new work done on them) a long time before a new feature was even invented. As an example, if you want to use cutting edge JavaScript features in your site, they might not work in older browsers. If you need to support older browsers, you might have to not use those, or convert your code to old fashioned syntax using some kind of cross-compiler where needed.
• some devices may have constraints that cause a web site to run slowly, or display badly. For example, if a site has been designed to look nice on a desktop PC, it will probably look tiny and be hard to read on a mobile device. If your site includes a load of big animations, it might be ok on a high spec tablet, but might be sluggish or jerky on a low end device.

Block Bindings

Traditionally, the way variable declarations work has been one tricky part of programming in JavaScript. In most C-based languages, variables (or bindings) are created at the spot where the declaration occurs. In JavaScript, however, this is not the case. Where variables are actually created depends on how declare them, and ECMAScript 6 offers options to make controlling scope easier.

Var Declarations and Hoisting

Variable declarations using var are treated as if they are at the top of the function (or global scope, if declared outside of a function) regardless of where the actual declaration occurs; this is called hoisting.

Block-Level Declarations

Block-level declarations are those that declare variables that are inaccessible outside of a given block scope. Block scopes are created:

1. Inside of a function
2. Inside of a block (indicated by the { and } characters)

Block Binding in Loops

Perhaps one area where developers most want block level scoping of variables is within for loops, where the throwaway counter variable is meant to be used only inside the loop.

Global Block Bindings

Another way in which let and const are different from var is in their global scope behavior. When var is used in the global scope, it creates a new global variable, which is a property on the global object (window in browsers). That means one can accidentally overwrite an existing global using var.

Emerging Best Practices for Block Bindings

While ECMAScript 6 was in development, there was widespread belief you should use let by default instead of var for variable declarations. For many JavaScript developers, let behaves exactly the way they thought var should have behaved, and so the direct replacement makes logical sense. In this case, one would use const for variables that needed modification protection.

Functions

Functions are an important part of any programming language, and prior to ECMAScript 6, JavaScript functions hadn’t changed much since the language was created. This left a backlog of problems and nuanced behavior that made making mistakes easy and often required more code just to achieve very basic behaviors.

Functions with Default Parameter Values

Functions in JavaScript are unique in that they allow any number of parameters to be passed, regardless of the number of parameters declared in the function definition. This allows one to define functions that can handle different numbers of parameters, often by just filling in default values when parameters aren’t provided.

Working with Unnamed Parameters

JavaScript functions don’t limit the number of parameters that can be passed to the number of named parameters defined. You can always pass fewer or more parameters than formally specified. Default parameter values make it clear when a function can accept fewer parameters, and ECMAScript 6 sought to make the problem of passing more parameters than defined better as well.

The Spread Operator

Closely related to rest parameters is the spread operator. While rest parameters allow one to specify that multiple independent arguments should be combined into an array, the spread operator allows one to specify an array that should be split and have its items passed in as separate arguments to a function.

Block-Level Functions

In ES 3 and earlier, a function declaration occurring inside of a block (a block-level function) was technically a syntax error, but all browsers still supported it. Unfortunately, each browser that allowed the syntax behaved in a slightly different way, so it is considered a best practice to avoid function declarations inside of blocks (the best alternative is to use a function expression).In an attempt to rein in this incompatible behavior, ECMAScript 5 strict mode introduced an error whenever a function declaration was used inside of a block. In ECMAScript 6, the doSomething() function is considered a block-level declaration and can be accessed and called within the same block in which it was defined.

Arrow Functions

One of the most interesting new parts of ECMAScript 6 is the arrow function. Arrow functions are, as the name suggests, functions defined with a new syntax that uses an “arrow” (=>). But arrow functions behave differently than traditional JavaScript functions in a number of important ways:

• No this, super, arguments, and new.target bindings - The value of this, super, arguments, and new.target inside of the function is by the closest containing no narrow function.
• Cannot be called with new - Arrow functions do not have a [[Construct]] method and therefore cannot be used as constructors. Arrow functions throw an error when used with new.
• No prototype — since you can’t use new on an arrow function, there's no need for a prototype. The prototype property of an arrow function doesn't exist.
• Can’t change this - The value of this inside of the function can't be changed. It remains the same throughout the entire lifecycle of the function.
• No arguments object - Since arrow functions have no arguments binding, you must rely on named and rest parameters to access function arguments..
• No duplicate named arguments — arrow functions cannot have duplicate named arguments in strict or nonstrict mode, as opposed to nonarrow functions that cannot have duplicate named arguments only in strict mode.

Thats just a glimpse of fundamental JavaScript. One should search and read and learn more to work fluently in JavaScript.