DEV Community: Shihabudheen US

OWASP top 10

Shihabudheen US — Sat, 05 Dec 2020 07:28:19 +0000

OWASP stands for Open Web Application Security Project, which is an open-source foundation for web app security. They have curated a list of top 10 vulnerabilities and the list is a good place to start with for making your apps more secure.

Here we will discuss the 2017 release candidate 2 of OWASP top 10 vulnerabilities.

Injection In programming, the commands and the data to be operated upon are defined by code.

For example, consider a signup form. Here we get the input(data) from the user and act up it using the commands we used to code the application. What if the input intended to be data acted as a command for the application. With that, the user can take the application to unindented states. This is an example of an injection attack. There are SQL injection, LDP injection, OS injection, XPath injection etc.
Access control is one way to prevent this type of attack.

Prevention:
- input validation: can include blacklisting and whitelisting of characters and their data types and lengths.
- prepared statements and stored procedures: the user must only be able to pass the parameters rather than a complete dynamic query. The developer can also have stored procedures(named queries) so that all required queries are kind of well defined.
- least privilege: ensure you only provide the required level of access.

Broken Authentication and session management Authentication is verifying who you are and what belongs to you. A session starts when an authenticated user starts using his account/resources. The most common was of authentication is a username and password. At times people might trick the user with some emails or phone calls which sound urgent in order to acquire their passwords and user names. This is called Social engineering/Pishing. With the increased computation power availability hackers can run periodic and systematic attacks to get access to an account and this is called Automated Attacks. One way is credential stuffing where the hacker periodically tries out the user credentials exposed in a security breach. As most of the people reuse the passwords this works so often. Another one is brute-foroce attack where the attacker will guess to the password and try different possible combinations of credentials. Broken application logic can also lead to broken auth. Suppose if you have a less efficient forgot password reset mechanism hackers can get hold of your accounts easily.

Solution:

limit the number of retries
stronger passwords
encrypt the passwords well
two-factor authentication where the user uses a password as well as an OTP to login.

Sensitive Data exposure
At times the sensitive data might be leaked or exposed. It is always advised to encrypt data while storing and sending. Encryption(🔐) involves an algorithm(mathematical formula) and a key(🔑). If one has to decrypt the data they must know the algorithm and 🔑 used to encrypt it.
Always try to store the least possible sensitive information which is only required.
Prevention:
- enforce PCI standards
- enforce laws and regulations
- reduce the scope. Always process, collect, store and transmit only the least required data.
- encrypt sensitive data at rest and transit. TLS(successor of SSL), HTTPS(HTTP + TLS) and HSTS(HTTP Strict Transport Security). HSTS convert all HTTP connections to HTTPS.
XML External Entities(XXE)
XXE is more like an injection attack that happens in a system where XML is used for inter-application communication.

XML is used to transfer data and files.
A malicious XML input from an external source is sent to an application with an intent to take down the entire application or Remote Code Execution(RCE).
Example of one such attack is XML Bomb, where an XML string get reproduced into 10x after each parsing finally results in DoS(Denial of Service)/Billions Laugh Attack attack. With this, the application is no more able to handle further requests due to memory overflow.

Prevention:
- disable XML external entities
- whitelist, blacklist and validating inputs
- upgrade the XML processor and libs

Broken access control
Authorization is more related to enforcing user roles and allowing authenticated users to perform certain actions that their user role facilitates.
Every application will have a certain kind of user roles, who are privileged to perform different levels of actions. Access control is broken if user roles are not being strictly enforced.

Prevention:
- enforce proper access control
- logging and monitoring access control failures
- manual testing of access control by security researchers(penetration testing), QA or developers in unit or integration tests
Security misconfiguration
An application may consist of different infrastructure and software components. At times the misconfiguration of these components can end up making our applications vulnerable to attacks. Few examples are,
- Error handling: during development, it is common to enable error handling. But once the application is being deployed in production we should ensure this error handling and logging being turned off so that the hackers can't know what exactly is failing and use it against us.
- Default passwords and settings: many of the infra and software components are shipped with default passwords. We. should them to be removed and strong passwords are being used. Suppose if the hacker new which service we are using and is able to get access using the default password, then it will be troublesome.
- Outdated libraries and frameworks The best approach is to provide least privilege to the services and they should have only the required privileges to access DB and other services. And in general no GOD users.

Prevention:

harden all systems
update and patch regularly
test configurations

Cross-site scripting(XSS) Using <script/> to inject malicious scripts through an HTML input. They are mainly of the following types:
- reflected cross-site scripting, which is more like pishing when the user clicks on a link that in turn executes a malicious code
- stored XSS, happens when a user visits a page with a malicious payload. User doesn't have to do anything, he/she just need to visit the page. This kind of attack is more dangerous as it can spread too quickly and can end up being a worm.

XSS is used to

steal credentials
install keyloggers
defame websites

Prevention:

enable Content Security Policy(CSP
applying Context-Sensitive Encoding. It ensures software doesn't interpret data as instructions as we tell it not to.
use HTML entity encoding and URL encoding, which tells the software the inputs as data rather than code.
escape unstructured HTTP data

Insecure deserialization Serialization is the process of converting digital information into a different format so that it can be stored well. Deserialisation is the reverse process of converting the store information into digital format. There are chances for hackers to tamper the serialized information and cause chaos after deserialisation and this is referred to as insecure deserialisation. Most of the time developers use libraries for serialising and deserialising data. But most of these libs are not foolproof and may miss many guards.

Prevention:

use encryption and have in place integrity checks
logging and error reporting to detect insecure deserialisation
isolate code that deserialises

Using components with unknown vulnerabilities The software has bugs. In modern-day development, we make use of a lot of open-source libraries, frameworks and systems. But if those components have any vulnerabilities we are also getting vulnerable by using it. There is a list maintained by (CVE)[https://cve.mitre.org/index.html]. If an attacker knows a bug in a component it can be his/her doors to our system too.

Prevention:

continuously monitor the components and dependencies for security flaws
if the patches are time taking, apply virtual patch using Web Application Firewall(WAF).

Insufficient logging and monitoring Logging is noting down what is having in a system continuously. Logging is kind of an electronic record of things happening. This can include login, logouts, error, input validation failures, etc. We not always should just log it but monitor them closely too, to understand what is actually happening. To make it effective there must be an incident reporting system in place too. The time to detect a breach is nearly 197 days.

Preventions:

ensure you log what is required and no sensitive information. But it can have sufficient user context so that we can know who is doing what.
the logs must be well monitored so that we can spring to act quickly.
have an Incident Response Plan, which says how to respond to an incident. This lay down the steps to be carried out and who will do what.

🎣 [Hookable] ⚛️[React]

Shihabudheen US — Sun, 20 Sep 2020 15:27:09 +0000

Spoiler 🚫: this one is not worth reading. Upfront you are warned!⚠️

react is a library to define the blueprint of UI. It doesn't know how to render, it is just to define the UI.
react-dom is the one that takes care of the rendering part. We can pass the actual DOM element into who the react defined UI should be shoved into.

ReactDom.render(domElement,reactElement)

for markup react uses something called JSX, which is not pure HTML. Under the hood, it is babel which transpile this to JavaScript

<div isBold>Shihab</div>

...
React.createElement('<div>',{ isBold:true },'Shihab')

In React.createElement(), first and second params are fixed as type and props respectively. The rest of the arguments are treated as children, and it can be of any count.

React.createElement('<div>',{ isBold:true },'Shihab',' ','learning',' ','React')

...
<div>Shihab is learning React</div>

React is UI in terms of state. What we tell React is for a given state, how the UI should look like. This is what makes React declaratively. If you start to think of React in terms of state, it is much easier and cleaner to build things. To relate, think of like a UI designer. For the given condition(state) what should be the UI like. If you initially start thinking about the interactions and all the stuff, you are actually making things difficult.

useState

CodeSandbox

useState take an initialValue and return [currentValue,setValue]
if value changes it should re-render

function useState(initialValue){
  function setValue(newValue){ 
     initialValue = newValue
     render()
  }

  return [initialValue,setValue]
}

function render(){
  ReactDOM.render(....)
}

render()

But here, there is a problem. It is the component which calls the useState. So each time the component(function) gets called, it is calling useState afresh. In that case, if we try to set a new value to the initial value, it wouldn’t hold. Between the renders, it will lose value. So we should have some mechanism to persist the values, across renders. For that, we can use a global variable, let us call it states.

states will have the [currentValue,setValue] getting pushed for all renders.

const states=[]

function useState(initialValue){
  function setValue(newValue){ 
     states[0][0] = newValue
     render()
  }

  const tuples = [initialValue,setValue]
  states.push(tuples)
  return tuples
}

function render(){
  ReactDOM.render(....)
}

render()

Still, there are problems.

It is evident that we keep on pushing into the states array and soon it will run out of space.
if we have multiple useStates inside the component, how we identify its current value from states array. So there should be some sort of identifier.

We only need to push to the states array on the initial render. On subsequent renders, we just have to find the respective value, update it and return its tuple.

Since the useStates are being called once per useState statements inside the component, we can have, a call counter for the useState. On each call we increment it and on each render we reset it.

const states=[]

let callCount=-1

function useState(initialValue){
  const id = ++callCount

  if(states[id]){
    return states[id]
  }

  function setValue(newValue){ 
     states[id][0] = newValue
     render()
  }

  const tuples = [initialValue,setValue]
  states.push(tuples)
  return tuples
}

function render(){
  callCount=-1
  ReactDOM.render(....)
}

render()

To note, this is not the actual implementation of useState in React. This is just a thought. From the above snippet, we can conclude that,

useState should be called in the same order and the same no.of times between the renders. In other words, useStates can’t be called inside conditions.

useRef

In the non-react world, we have different ways to reference or identify the DOM element. We usually use querySelectors,document.getElementById,etc. But in react, it is not encouraged much, because we can have multiple instances of the same component and if we use an id to identify a DOM element, it would cause problems.

So in React world, we have refs. refs are usually used to "ref"erence DOM element in React.

// create ref
const inputRef=useRef()

// assign ref
<input ref={inputRef}/>

// use ref
inputRef.current.focus()

Note:

handler(e){
 e.preventDefault()
}

<button onClick={(e)=>this.handler(e)}>Click Me</button>

// same as
<button onClick={this.handler}>Click Me</button>

Implicit arguments of callbacks are passed by default. We don't need an intermediate param for them to be captured.

useEffect

we can think of them as side effects to be run

useEffect(()=>{
  // effect
  return ()=> // clean up
},[...deps])

effect run when any of the deps changes and clean up follows
if no deps is provided with the effect is triggered on each render and clean up follows
if deps is an empty array, it runs only once in the entire life cycle of the component that too when the component mounts and clean up is triggered on the unmounting

Note: suppose you have a fetch inside an useEffect and you want to avoid the unwanted state updates if the useEffect is triggered while the current fetch is in progress. Use the below snippet for the clean up the intermittent calls, just before the last

useEffect(()=>{
 let isCurrent = true
 fetchUser(id).then(user=>{
   if(isCurrent) setUser(user)
 })
return ()=> isCurrent=false
},[id])

function clickHandler(id){
 setId(id)
}

over here, no matter how many times the clickHandler is triggered, only the last one will trigger a state update

useContext

const MyContext=React.createContext()

function App(){
  const [productId,setProductId]=useState(1)

  return (
    <MyContext.Provider value={{ productId,nsetProductId }}>
       <Header/>
       <Body>
         <Product/>
       </Body>
       <Footer/>
    </MyContext.Provider>
}

// deeply nested child component
function Product(){
  const { productId,setProductId } = useContext(MyContext)
  return (
    <Container>
      ...
    </Container>
  )
}

useReducer

it helps to keep states together
the changes can be a bit more self-descriptive
no need to call different setState (from useState) to update different states

function fetchAds(){
 try{
   setLoading(true)
   ...
 }catch(err){
   setLoading(false)
   setError(err)
 }
}

...
function fetchAds(){
 try{
   dispatch({type:'FETCH_ADS'}) // more self-descriptive
   ...
 }catch(err){
   dispatch({type:'FETCH_ADS_FAILED'}) // no multiple setState calls
 }
}

in fact, useState is implemented on top of useRedcer

const initialState = {
  counter: 0
};

function reducer(state, action) {
  switch (action.type) {
    case "INCREMENT":
      return { ...state, counter: state.counter + 1 };
    ...
    default:
      throw Error(`Unhandled action type: ${action.type}`);
  }
}

function App(){
  const [state, dispatch] = useReducer(reducer, initialState);

  const { counter } = state;

  function increment() {
    dispatch({ type: "INCREMENT" });
  }

  ...

  return (
    <div className="App">
      <h1>Count: {counter}</h1>
      <div>
        <button onClick={increment}>Increment</button>
        ...
      </div>
    </div>
  );
}

Codesand box

Note: in Redux reducers, we usually return the state as the default case inside the reducer switch. That is because we have the reducers separated as different files. When an action type is being dispatched all of the reducers get invoked but its handler resides inside the subset of global reducers. But for useReducers we need not do that. These are most of the time local to the components and are only invoked from it. We will have a clear idea about the action types. And practically we should be notified if any unhandled action types are dispatched. So it is ok if we throw an error in the default case of these reducers.

by using useReducer with the context we can implement our own Redux. Sample gist

Modules in JavaScript

Shihabudheen US — Sun, 06 Sep 2020 07:34:26 +0000

Why modules?

In olden days, the scripts were added inside the markup. But as the projects started growing, maintainability became an issue. So people started to maintain scripts as separate files and it got imported via <script src='...'/> tags for usage.

Moreover, to share the variables and functions, all of them were pushed to the window(global scope). Often this leads to unexpected overrides and malicious usage(global namespace pollution).

The problems with his approach were:

the order of script loading was important. If one functionality has a dependency on another one, it should ensure the dependency is already loaded before executing. If not it might fail to execute and start throwing errors.
sharing variables(states) and functions(behaviour) were difficult. The things to be shared were pushed to the global scope(window), which led to unexpected overrides(namespace collisions), malicious usage and global namespace pollution.

Modules were introduced to solve these concerns.

What is a module?

A file with functionality, which can be reused is called a module. The modules helped to solve the global variable conflicts (scope issues). The variables and functions in a module are always file scoped. With modules, sharing was more explicit. Things to shared have to be exported and things to be consumed has to be imported.

By default, module scripts

use strict mode
they are deferred while loading
executed only once(in the first import) irrespective of the number of times it is being imported in the whole code (singleton).

With modules, the scripts can be split into multiple files, with less headache. The explicit link between the files was well evident, with import and export statements, and it became easier to combine and recombine them as chunks.

Types of modules

ESModules

ESModules is the language level module system in JS. This is currently under adoption.

To use ESM in the browser we have to define the type as module for the script.

<script src='index.js' type='module'/>

Apart from ESModules we have:

AMD(Asynchronous Module Definition): legacy ones
CommonJS: module system created for Node.js. If you want to use ESModules inside Node, then the module file must have an extension of .mjs.
UMD (Universal Module Definition): kind of universal modules, which supports both AMD and CommonJS styles.

Working of Modules

When working with modules, we actually try to create a graph of dependencies and a module instance after parsing the files(creating module records). To do this, we just pass an entry file for the graph construction to start. This is done as,

<script src='main.js' type='module'/>

Three different steps in module loading are,

Construction: find, download, and parse all of the files into module records.
Instantiation: find boxes in memory to place all of the exported values in (but don’t fill them in with values yet). Then make both exports and imports point to those boxes in memory. This process is called linking.
Evaluation: run the code to fill in the boxes with the variables’ actual values.

For ESMs, these steps are asynchronous and can be performed separately.

But in the case of CommonJS, all of them are performed synchronous(w/o any breaks). Though each step need not be async.

It is up to the loader how to load files. And the loader varies between the platforms(browser and Node).

Next.js: the new normal

Shihabudheen US — Mon, 31 Aug 2020 12:58:26 +0000

Next.js is a full-stack framework based on React.js.

What it offers:

Prerendering: the entire HTML is created in the server and send to the client. So the client receives the HTML rather than the JS file. Once the HTML(string) is available it gets rehydrated at the client side. One can think of rehydration as adding event listeners and making it interactive. All the routes are pre-rendered by default.

Scripts

The common commands used to run and build a next project are the following.

"scripts":{
  "dev": "next",   // start in dev mode
  "build": "next build", // start production build
  "start": "next start" // run production build
}

Routing

using reach-router under the hood
file-system-based routing
for that, we create a special folder called pages
all the folder/file names become the routes for those files
we can handle dynamic routes and receive the parameters like notes/:id. For that we just need to create a file named [id].js(x) inside a notes folder. If the notes folder has an index file it will be treated as the notes/ route
to use the param inside the render function we can use useRouter hook from next/router. For classes, you have withRouter HOC.

notes/[id].js

import { useRouter } from 'next/router'

function App(){
 const router = useRouter()
 const {id} = router.query

 return (
    ...
 )
}

export default App

note: In React, functional components are actually the render function. The entire function is the render method in case of functional components. With classes, we will have an explicit render() with a return value.

if you want to handle slugs, like notes/shihab/1, you can have a file named [...slug].js inside the notes directory. This time the router query will return an array-like ['shihab',1]. Even with catch-all routes, the index will still be used.

Navigation

Link component

For navigation next/link expose a Link element. It is always for client-side routing. That means, on navigation, this will not trigger a network call.

import Link from 'next/link'

function App(){
  ...
  return {
    ....
    <Link href='/notes/[id]' as={`/notes/${id}`}>
      <a>Note</a>
    </Link>
  }
}

as path will be the exact path URL, the href will be the file's relative location. The href prop takes a page name as it is in the pages directory. For dynamic routes, you will need the as prop as well.

You must have an a tag as the child of the Link component, but the href lives on the Link.

For server-side routing, you can readily use an anchor tag like <a href='/docs'>Server side routing</a>

Programmatic routing

In order to navigate from code, one can use router.push() from next/router's useRouter hook.

import { useRouter } from 'next/router'

function naviagteOnSuccess(){
 const router = useRouter()

 ....
 router.push('/notes/[id]',`/notes/${note.id}`)
}

Styling

if you are using global CSS, pages/_app.js is the only place you can import it. If you try to import it in other places Next.js will throw an error. This is more tied to the bundling of styles and loading them
Next.js readily supports CSS Modules. With CSS modules we get file scoped styles. How it works is, with each import of CSS module file, a file specific class name gets added(prepended) to the classes you use. So the style you use is specific to that particular file and doesn't collide with others. The CSS modules will only work with non-pure selectors like classes and ids, etc and not with element selectors(div, span, p,...). The filename should be like file-name.module.(s)css.

Special files

`_app.js`

if you want to hijack the entry file of Next, _app.js file is the place. If you want to inject global styles, props or anything, it should happen here. This _app.js is automatically created for you out of the box if you don't.

Next.js config

next-config.js in the root of the project

TS support

Just create a .tsconfig.json in the root.
Next will ask you to add some libs and dependencies. Add them.
Bhoom, now Next will auto-populate the tsconfig for you. No more traction in setting up TS.

API routes

Next is a full-stack framework. You can have your API route handlers inside a directory pages/api.
The routing is the same as that for pages.

Data fetching

by default fetch is available

Data can be fetched on the server and the client. Client-side data fetch is the same, what we do in a normal React app. The components may be rendered in the Server, but data fetching will only happen on the client in this case. That means, if you fetch the data in the client(using hooks or lifecycle methods), they aren't triggered on Server. The Server will render the view with the components initial State, that's all. No, waiting until the client fetches or manipulation is over.

To fetch data on the server we have

getStaticProps
getStaticPaths
getServerSideProps
getInitialProps
All of the above methods are only meant to run on the server(except getInitialProps, during subsequent calls).
they are not even added to the client bundle
these methods can access DB, file system and all the things that can be done on the server-side
the return value(objects) of these methods are injected into or send to the client-side components as JSON files

getStaticProps

to pass down any static props to the components, that are available during the build time
it may receive the props from the getStaticPaths method
the return value is always an object
this object is available as the props inside the component
when building dynamic pages you will have the params passed from getStaticPaths, inside the getStaticProps
it is only called once at the build time (when building the app using next build command)

export async function getStaticProps(context) {
  return {
    props: {}
  }
}

getStaticPaths

if you want to generate static pages you can use this method
it should return an array of paths
the pages are created for the paths at build time
if the pages need some data to be fetched, we use the getStaticProps
it might not be required to statically generate all the pages in advance, so you can opt for runtime SSR using fallback: true
by using fallback you can show some loaders if required when the page is being built

export async function getStaticPaths() {
  // get all the paths for your posts from an API
  // or file system
  const results = await fetch('/api/posts')
  const posts = await results.json()
  // create the paths array
  const paths = posts.map(post => ({params: {slug: 
  post.slug}}))
  /*
  [
    {params: {slug: 'get-started-with-node'}},
    {params: {slug: 'top-frameworks'}}
  ]
  */
  return {paths}
}

export async function getStaticProps({ params }) {
  const res = await fetch(`/api/post/${params.slug}`)
  const post = await res.json()
  return {
    props: {post}
  }
}

getServerSideProps

called on every request on the server
used if you want to do some data fetching for dynamic SSR routes
you will have access to HTTP header, query params,req and res headers
even if it is client-side navigation, this method is triggered on the server-side and data is sent down. This is actually an extra roundtrip 😢.

export async function getServerSideProps() {
  const response = await fetch(`https://somedata.com`)
  const data = await response.json()

  return { props: { data } }
}

getInitialProps

not recommended as per docs, but not yet deprecated 💪
on Server-Side Rendering(SSR) pages it is run on the server and data is passed down as JSON
for Client-Side Rendering(CSR) it runs on the client
used to fetch data

Note: when the page is fetched upon URL/address bar navigation, it is SSR. On client side navigation it is CSR.

When to use what

Do you need data at runtime but don't need SSR? Use client-side data fetching.
Do you need data at runtime but do need SSR? Use getServerSideProps
Do you have pages that rely on data that is cachable and accessible at build time? Like from a CMS? Use getStaticProps

Do you have the same requirement as above but the pages have dynamic URL params? Use getStaticProps and getStaticPaths

Rendering modes

Basically 3 rendering modes

Static: pages are built at run time.
Server Side: page are built on each request and cached after the initial hit
Client-side: the rendering happens on the client. The server will not send the HTML markup string. By default, the pages are pre-rendered while using Next.js.

The type of rendering is chosen based on the data fetching strategy we choose(mostly). By default, the pages are pre-rendered by Next. Pre-rendering means, the server sends down an HTML markup string to the client. Once the request is received the client will try to make it interactive by injecting listeners and handlers (hydration).

By choosing the appropriate data fetching strategy we can decide the rendering mode for the app.

If your component works with

DOM APIs
only on client data, there is no point in server-side rendering them. We can opt-out of SSR by using,

const NoSSR=dynamic(()=>import('../component'),{
 loading:()=><div>Loading.....</div>,
 ssr:false
})

Here <NoSSR/> will always be client rendered.

Deployment

By default, it requires a Node.js environment. By using next export we can create a pure static build from our Next project and server it.

CORS in short

Shihabudheen US — Fri, 28 Aug 2020 05:47:50 +0000

What is CORS ❓

CORS is actually a method to access the resources📁 that are forbidden 🚫 to be used by the client🌐, by default. There exists a same-origin policy which ensures clients can only access the resources in their own domain. That means if I am a client with domain xyz.com I can only access resources in the domain xyz.com.If I try to access something from lmn.com it will be blocked 🚫 by the browser.

Why CORS❔

The CORS mechanism in the browser helps us to use the resources available in a different domain. With all the CORS enabled ✅ request there is an Origin header that gets added. In the response sent from the server 🗄️, there will be an access-allowed-origins header which contains the details of the origins which can utilise that response. The browser will see 🔍 if the origin matches the allowed ones. If it is matched, the response can be consumed by the client. Else, it will throw the CORS error ⛔.

One point to understand is, CORS is only applicable to clients like browsers. It will not come into picture when the cURL or postman requests are being made.

The same-origin policy is beneficial 👌 because it prevents 🚫 malicious 🦠 websites and servers from accessing our data. As I told, if the resource is to be accessible, it should be either in the same origin or should be whitelisted 📄 by the server.

Linters: don't wait to test

Shihabudheen US — Thu, 20 Aug 2020 19:45:46 +0000

Linters help you to analyse your code statically, i.e without actually even running it. This helps us:

to catch the errors and pitfalls in the code far before doing the testing
enforce style and coding practises so that, throughout the project, the conventions are strictly followed.

ESLint

ESLint is an open-source project originally created by Nicholas C. Zakas which provides a pluggable linting utility for JavaScript. It parses your code, analyses it and runs linting rules that may trigger warnings or errors to let you know if your code is right or wrong.

Installation

ESLint can be installed either globally or locally.

npm i -g eslint or npm i -d eslint

It is better to install ESLint project-wise because it will save you from running into conflicts.

If you use VSCode, we can use the ESLint plugin which is really handy.

Configuration of ESLint

ESLint is highly configurable. We can do that either, using

configuration comments
configuration files

The second approach is easier and productive so we will explain that.

Configuration files

When using configuration files, it is entire project-specific. The configuration file can be a JSON, YAML or JS file. It is named .eslintrc.* and placed at the root of the project. Or else it can go inside the package.json files under the key eslintConfig.

To create a configuration file you can run the command

npx eslint --init

// or

yarn run eslint --init

but make sure you have package.json in the project root. If not you have to create one before running the init command.

Available options

The configuration files can take many options. A few of them are

parserOptions: tells ESLint how you want it to parse your code. The available options are:
- ecmaVersion: to specify the version of ECMAScript syntax you want to use. For es6 syntax support we can use { "parserOptions": { "ecmaVersion": 6 } }, but for the latest keyword support we need to mention it using the env. By setting { "env": { "es6": true } } the es6 syntax support is enabled automatically.
- sourceType: set to script(default) or module if your code is in ECMAScript modules.
- ecmaFeatures: an object indicating which additional language features you'd like to use.
- globalReturn: enable global return
- jsx: enable jsx support
- impliedStrict: enable global strict mode (version > ECMA5)
parser: ESLint uses espree by default as the parser. We can change it by passing a parser option in the configuration. Even with a separate parser, parserOptions are to be passed. The supported parsers are:
- esprima
- babel-eslint
- @typescript-eslint/parser
plugins: plugins are a set of ESLint rules related to some specific subject. As an example, eslint-plugin-react contains many rules related to React. If needed the eslint-plugin- prefix can be omitted from the plugin name.

{
    // ...
    "plugins": [
        "jquery", // means eslint-plugin-jquery
        "@jquery/jquery", // means @jquery/eslint-plugin-jquery
        "@foobar" // means @foobar/eslint-plugin
    ]
    // ...
}

Caution: you have to install the plugin as a dev
dependency for your rules to work properly.

processor: some plugins may come with processors, which helps to extract JS code from other file types. Or it can also convert the JS code to other formats/types. more...
env: it is used to specify which environments your script is designed to run in. Each environment brings with it a certain set of predefined global variables. For example, when using testing tools like protractor, there are a few global keywords that are protractor specific. We can use env to enable them. To enable an env, just add it in the object with value as true and the environment as the key.

{
    "env": {
        "browser": true,
        "node": true
    }
}

globals: if there are any user-defined global variables that are being accessed inside the script, that can go inside the globals.

{
    "globals": {
        "var1": "writable",
        "var2": "readonly"
    }
}

rules: which rules are enabled and at what error level. Following are the error levels available:

-off/0 - turn the rule off

-warn/1 - turn the rule on as a warning (doesn't affect exit code)

-error/2 - turn the rule on as an error (exit code is 1 when triggered)

Ignoring files and directories

In order to ignore files from getting linted, we can do it either by creating an ignorePatterns field in the configuration or by creating a .eslintignore file in the project root.

Proxy in short

Shihabudheen US — Thu, 13 Aug 2020 20:09:59 +0000

What is proxy❓

Proxies are servers 🏛️ that sit in between your machine 💻 and the server 🗄️ you are trying to reach. It is kind of a middleman 👮‍♀️. When you request data from a server, that request is intercepted and forwarded by the proxy server. For the data to reach back, it has to pass through the same proxy again.

When you are behind a proxy 🕸️, your computer's IP will never be shared. All your internet traffic would be seen as coming from a different IP, that is of the proxy server.

Why to use a proxy❔

Proxy servers are usually used to:

ensure security 🔐
site whitelisting 📄
monitoring 🛰️
fake location 🗺️

Depending upon the purpose, there are different types of proxy servers. Some of them are:

1.Transparent proxy

Transparent proxies are the simplest kind of proxy. They pass all of your information along, but with the proxy's IP address. These proxies don't offer any kind of privacy protection.

2.Anonymous proxy

Anonymous 👻 proxies are a commonly used type of proxy. They never pass your IP address to the website you are browsing although they will identify themselves as a proxy in the request. This helps you to keep your browsing activity private 🦹‍♀️.

3.Rotating proxy

Rotating proxies work a little differently from the others. Every time a client connects to the proxy, a new IP address is created for it. So they never use the same IP address more than once.

4.Reverse proxy

Reverse proxies are completely different from everything we've covered so far. A reverse proxy hides the IP address of a server you're trying to send a request to. When a server needs security and privacy from clients, that's when these types of proxies come in.

VPNs

VPN(Virtual Private Network)s are also meant for security and monitoring. But it will control and monitor all the network activities, including FTP downloads and uploads, and background OS operations like updates. In that way, VPNs are much more secure 🔐 than proxy servers. When you are using a VPN, even the ISP(Internet Service Provider) can't see your internet activity. All they can see is, just connected 🔌 to a VPN. So, your requests are highly private and concealed when using a VPN.

Compared to proxy servers, VPNs are expensive 💰 to run and maintain.

Build tools (purely front end)

Shihabudheen US — Thu, 13 Aug 2020 19:01:22 +0000

🚨 With newer HTTP 2/3 a few of things being discussed below are outdated. But the usage of build tool can’t still be ruled out.

Why build tools❓

Often times we love ♥️ to keep all our files separate and tidy. For example, consider a simple HTML project. We will have separate files for JS, styles and HTML. As the project grows and with more pages getting added, the file sizes and their number may also increase. Keeping files separate, maintenance is a lot easier. In case of a bug, it is easier to track and patch. In short, development becomes hassle-free😎.

But what about production?🤔 In prod, the story is different, as we can't afford too many files. For each file, we need to make a separate HTTP call and that can be quite expensive. So in production, it is better to keep the file count as minimum as possible.

One way is to combine these files. We can combine all our JS, CSS and HTML code into individual files. If we start doing it manually, it can be really cumbersome and tedious😫. We may easily lose the track too. This is where we can rely upon a set of tools termed build-tools🧰.

What are build tools❔

As the name indicates, build-tools are tools, that help us in creating builds. Builds are production-ready executables of our project. Build tools, help us do more than concatenating our files.

We can use it for ♦️file compression, ♦️removal of white spaces and unwanted codes, ♦️linking of files and much more. If we can think of all these operations as individual tasks, build-tools are helping us to automate them. Run a single command and build tools will do its magic✨.

There are a lot of build tools out there and each serves different use cases. To name a few, 👉 Grunt, 👉 Gulp, 👉
parcel.js and 👉 Webpack. Some of them are easy to use, but a few require a steep learning curve. So it is better to learn a tool, only if it is required.

For small projects, one might not require a build tool at all. But if your project is quite big and complex it is wise to use a build tool.

Rethinking JS [short notes]

Shihabudheen US — Mon, 10 Aug 2020 17:35:50 +0000

Mental model 🧠

Mental models are how we think 🤔 about something
Slow and fast thinking
Slow thinking is laborious, front lobe
⚡️ Fast thinking is less tiring and most often preferred(default)
Mental models are essential to write good code, easy to reason about and less prone to errors

Context

You are on the JS asteroid in the space. You see stars⭐️, planets🪐 and asteroids ☄️ floating in space 🌌.

Values and Expressions

Values

values are things. They are like numbers in Math, words in a sentence and dots in geometry. It is a thing 🧱. We can't 🚫 do much to them, but we can do things with them
there are two types of values in JS. Primitive and Composite
Primitive values are numbers and strings(and few more). They are like far distant stars and we can only look and refer them, but we can't change them or affect them.
Composite values are different. We can manipulate them from code. Like functions and objects. They are like rocks closer to the asteroid that we are on.

Expression

expressions are kind of questions ❓ that we ask JS. The expressions always result in values.

`typeof`

to know the type of value we can use typeof operator.
typeof _value will give us the type of the value as string.

The types can be,
Primitive

undefined (undefined)
null (object)
number (number)
bigint
symbol
string
boolean

Composite

object (object)
function (function)

Primitives are immutable

In JS, primitives are immutable. For example

let name='yikes'
name[0]='l' // can't change
console.log(name) // 'yikes'

Even though string appears to be similar to an array, which is not a primitive we might have an intuition that we can mutate or change it. But in practice, we can't since the strings are primitive. This also applies to all the primitives.

let number=10
number.value='ten'
console.log(number) // 10

Since the addition of a property is also a kind of mutation, this too is not allowed on Primitives.

Variables

Variables are like wires. We can connect the variables to values. In order to connect a variable wire to a value, we use assignment statements.

let x='Shihab'

Now the variable wire x is connected to string value Shihab. The RHS of an assignment is always an expression.

let world='World'
let say='Hello '+ world

Since we are asking JS, what is 'Hello '+world it is an expression which resolves to a value 'Hello World'.

The RHS of let x='Shihab' is also an expression, since it also resolves to a value 'Shihab'. We call it literlas since we write down the exact value.

In JS, we always pass the value and not the variable itself. We cannot change what the variable points to, but at times we can change the value itself.

let num=10
function double(x){
   x=x*2
}
double(num) // here we pass the value 10 
            // and not the reference to it
console.log(num) // 10

let arr=[10,20]
function mutate(input){
  input[0]=30
}
mutate(arr)
console.log(arr) // [30,20]

This is because we pass the value of arr which is [10,20]. Since arrays are mutable, we were able to mutate the value. And the function cannot change the value arr was wired to, thus we get [30,20] when trying to print arr.

Counting Values

We should always think, values as having a precise count.

Undefined ----> Undefined [1]
null -----> null
Boolean -----> true or false [2]
Number ----> 18 quintillion [...]
BigInit ---> Use for arbitrary precision and no round-off. Mainly used in financial calculations.
String ---> A string for each conceivable string that exists in the universe. A string has properties but it is not as same as other objects. Since the string is primitive it is immutable.
Symbols ---> recently new
Objects ---> Each time it creates a brand new Object
Function ---> Each function expressions are distinct. Like any other things in JS, functions are expressions too. When it is called with () [Call expression] JS resolves it to the return value of it. If not, it resolves to function expression or body. Function are also Objects, but special objects. Whatever you can do with Objects can be done with functions too. But what makes function different is, the can be invoked.

In this we way, we have can better place and point our variables to values. In our model, there should be only two booleans, and one undefined and null. All the time, when a primitive is being referred, JS actually summons them. But in the case of Objects {} and functions (), it creates a brand new value for us.

Equality in JS

In JS there are mainly 3 types of equalities

Same Value Object.is()
Strict equality ===
Loose equality ==

Same Value

Same value returns true is we are pointing to the same values.

Strict Value

It is same as Object.is() expect for

NaN === NaN // false
0 === -0 // true
-0 === 0

To test, if a number is NaN we can use Number.isNaN() or num !== num.

Loose Equality

It just compares the sameness of values.

2=='2'
true==0

Properties

Properties are similar to variables. They also point to values, but they start from an Object and they belong to it.

let sherlock={
 surname:'Homes',
 address:{
  city:'London'
 }
}

Even though it seems like a single object is being created there are actually two distinct objects here. An object can never reside inside another object, even though it might seem nested from code.

let sherlock={
 surname:'Holmes',
 age:64
}

Rules of reading a property

console.log(sherlock.age)

Properties will have names, which are strings basically. They must be unique within an object,i.e. an object cannot have two keys with the same name. The names are case sensitive too.

These rules look roughly like this:

Figure out the value of the part before the dot (.).
If that value is null or undefined, throw an error immediately.
Check whether a property with that name exists in our object.

a. If it exists, answer with the value this property points to.

b. If it doesn’t exist, answer with the undefined value.

If a property is missing, we get an undefined. But it doesn't mean that we have that property on the object pointing to undefined. It is more like, we are asking JS for the value (expression) and it is replying us that it is not defined, undefined.

Assigning to a property

sherlock.age=65

figure out which wire is on the left side
we figure out which value is on the right side
point the wire on the left side to the value on the right side

Mutation

Suppose we have the following

let sherlock={
 surname:'Holmes',
 address:{
   city:'London'
 }
}

let john={
 surname:'John',
 address: sherlock.address
}

Now we want to change john.

john.surname='Lennon'
john.address.city='Malibu'

But we observe we could see sherlock.address.city has also changed to Malibu from London. This is because both sherlock.address and john.address pointed to the same Object.

So because of this, the mutation can be dangerous. It might unintentionally change the values at all the places where it is being referred.

In order to avoid mutation, we could have done the following:

When mutating john,

john={
 surname:'Lennon',
 address:{ city: 'Malibu' }
}

john.surname='Lennon'
john.address={ city:'Malibu' }

Is Mutation that Bad?

The mutation is not bad at all, but we should pay closer attention to it. The bliss with the mutation is, it helps us update or change a value realtime at multiple places. If think the other way, that is misery with it too.

Even though you declare an Object with const it will not presentation mutation to the Object. It will only prevent the reassignments.

const x = {
  name:'Shihab'
}

x.name = 'Shifa' // allowed
x.age = 22 // allowed

x = {} // not allowed

Prototype `proto`

let human={
 teeth:32
}

let gwen={
 age:19
}

console.log(gwen.teeth) // undefined

But we can access teeth property of human in gwen by,

let gwen={
 __proto__: human
}

Now,

console.log(gwen.teeth) // 32

With adding __proto__ we instruct JS, to continue searching for teeth in __proto__ too.

Prototype Chain

The search for the values will continue until the base prototype is reached. In JS the base prototype is Object.__proto__ which is set to null.

As you can see, so this is kind of a chain that is getting created when we as JS to look for a property on an Object. This is being referred to as prototype chain.

let mammal={
 brainy:true
}

let human={
 __proto__:mammal,
 teeth:32
}

let gwen={
 __proto__:human,
 age:19
}

console.log(gwen.brainy) // true

Shadowing

When an Object has the same property on it and as well as inside the __proto__, the own shadows the value on __proto__. This is called Shadowing.

Assignments

The property assignments directly happen on the Object and not on the __proto__.

let human={
 teeth:32
}

let gwen={
 __proto__:human
}

On gwen.teeth=31

To check if the property belongs to an Object or its __proto__, we have a method called hasOwnProperty on Object.

ObjectName.hasOwnProperty(prop)

If the prop is a property on ObjectName, it will return true if not false.

Object prototype

When we create a new Object, there is a __proto__ that gets added by default. It is the prototype of the Object.

To terminate the prototype chain of any Object we can just assign null to its __proto__.

Polluting prototype

All the in-built methods and properties of Objects, Arrays and Strings are defined in the __proto__ of their base. In this way, these get shared among all the values, that are being created out of it.

But this practice of sharing is highly discouraged.

But the sharing of methods and properties via the prototype chain is the base of classes and all other features. But the direct usage of polluting prototype is not recommended.

proto vs. prototype

You might be wondering: what in the world is the prototype property?

The story around this is confusing. Before JavaScript added classes, it was common to write them as functions that produce objects, for example:

function Donut() {
  return { shape: 'round' };
}

let donut = Donut();

You’d want all donuts to share a prototype with some shared methods. However, manually adding __proto__ to every object looks gross:

function Donut() {
  return { shape: 'round' };
}

let donutProto = {
  eat() {
    console.log('Nom nom nom');
  }
};

let donut1 = Donut();
donut1.__proto__ = donutProto;
let donut2 = Donut();
donut2.__proto__ = donutProto;

donut1.eat();
donut2.eat();

As a shortcut, adding .prototype on the function itself and adding new before your function calls would automatically attach the __proto__:

function Donut() {
  return { shape: 'round' };
}
Donut.prototype = {
  eat() {
    console.log('Nom nom nom');
  }
};

let donut1 = new Donut(); // __proto__: Donut.prototype
let donut2 = new Donut(); // __proto__: Donut.prototype

donut1.eat();
donut2.eat();

Now this pattern has mostly fallen into obscurity, but you can still see prototype property on the built-in functions and even on classes. To conclude, a function’s prototype specifies the __proto__ of the objects created by calling that function with a new keyword.

An async boring sync example😆

Shihabudheen US — Wed, 29 Jul 2020 16:59:38 +0000

When learning about JavaScript, one would have definitely come across the terms single-threaded, synchronous and asynchronous. In this article, I am trying to explain what it actually means (or at least how I understood).

The boring example 🤖.

Let us start with an example. Suppose, you are running a takeaway restaurant. Your menu includes 🍵(tea), ☕(coffee),🥪(sandwich) and 🍔(burger). Yes, you only serve four items for now 🤣. Currently, you operate via a single counter since you are the only employee. You have to take the order, do the billing, and prepare it, and all by yourself. Pretend you are a born multi-tasker 🦸‍♂️.

With that said, you can only serve a single customer at any point in time. The time to fulfil an order is as follows:

Item	Time 🕐
coffee	2 minutes
sandwich	15 minutes
burger	15 minutes
tea	2 minutes

Since it is a single queue system even ☕ and 🍵 takers have to wait if they behind have any 🍔 or 🥪 buyers in the queue. People are people😬, and no one wants to spend their whole day just waiting in a long queue. Soon you found that you are losing the customers, all because of this long wait time😩.

Now the question is how can you retain your customers and earn more❓ The answer is super simple, reduce the wait time and server more people 🏆. Let us see two approaches (there are n other approaches as well).

Approach 1️⃣

We can add new 🤵(assistants) for processing the orders and 👨‍🍳(cooks) for preparation. Now an assistant/waiter will serve a burger or sandwich order. The ready to serve orders can be still managed by you🏋️‍♂️. Each time a 🍔 or 🥪 order comes up, you call upon a waiter to get it done. The waiter will take the order, inform the cook and wait until the cook prepares the order. Once it is ready, the order is well packed and handed over to the customer by the waiter. To ensure super fast delivery⚡️ for an order, a cook and a waiter work together from order taking to delivery. So the 🥪 and 🍔 customers are no more blocking the ☕ or 🍵 orders.

❎ The problem with this approach is, the waiter keeps on doing what they are meant to do, waiting... They are simply waiting 🏄🏾‍♀️ while the food is being cooked. Until an order is placed, the cook is waiting🏌🏾‍♂️ too. In short, now the waiter and cook waste a lot of time just, waiting.

Approach 2️⃣

Let us try introducing a 🏷(token) system only for the 🥪 and 🍔 orders. We take the order at a single counter and assign a 🏷 for each 🥪 and 🍔 orders. The customer clears the counter after collecting their token. Once the order is ready 🍛, the token number is called out 📣 and the 📦(parcel) is handed over through the main counter. Here too, we rely on extra 👨‍🍳(cooks) for preparation and a 🤵(single waiter). The called out customers join the queue to collect their order.

With this approach, the overall 🕰(time) has 📈increased (but still lower than the existing model), but the wait time is somewhat judiciously distributed.

Sync vs Async 🎊

Now let us get into the meat👽. The currently existing model of operation, the one before the optimization is kind of synchronous flow. Succeeding customers are awaiting for the previous order to be fulfilled. As the customers are blocked by the guys in front of them, we call it a blocking model.

The new two approaches can be considered as asynchronous or non-blocking (still there is a small wait time). As a separate 🤵-👨‍🍳 pair is working on a single order, the first approach is more like a multi-threaded one. The second approach is still kind of single-threaded but still unblocking.

Some JS stuff

As per docs, JS is said to be synchronous and single-threaded. Inherently synchronous operations are blocking as we just saw above. Being said, JS is synchronous have you ever felt it 🤔? Has your screen frozen when scrolling through your Facebook posts? Next time while googling, try to type and search at the same time(nearly instantaneous). I was able to search for videos, while my YouTube was still playing in mini-player mode. We know that JS is doing all of this in our browser and we were never blocked from multi-task. So is JavaScript actually synchronous? Let me know the answers in comments...👇

If you were paying attention, by now you would have the answer...

JS has a single thread (in JS engine) which processes all your tasks. The time taking jobs(n/w calls, timing functions) are pushed out and processed by separate engines. Once they re done, they maintain a secondary queue(callback/microtask queue). Once the high priority/synchronous tasks are completed, the items in the secondary queue are pushed to the main queue(call stack), where they are served one by one, by the main thread. In short, we make the fewer priority tasks WAIT ⏰

JS: 🌈 Feel proud of it

Shihabudheen US — Mon, 20 Jul 2020 14:04:06 +0000

What is JavaScript❓

JavaScript is a scripting language. According to Stackoverflow’s 2020 survey insights, JavaScript is the second most loved 🤟 programming language.

JavaScript was ‘born to make web live’ and thus the creator called it LiveScript. But from the scripting language that Brendan Eich created to make Mosaic(browser) lively, it has come a long way. Now JS is in your browser, on your phone and even in space 🚀.

So, take a moment to appreciate yourself for choosing JS and sticking with it.

They says🗣️

As always, Wikipedia is our one-stop for all the questions. Wiki📚 says,

JavaScript, often abbreviated as JS, is a programming language that conforms to the ECMAScript specification. JavaScript is high-level, often just-in-time compiled, and multi-paradigm. It has curly-bracket syntax, dynamic typing, prototype-based object-orientation, and first-class functions.

That is a lovely definition I would say, still there are many things unclear. What is ECMAScript, just-in-time compiled and what on earth is first-class functions? So let us try to answer a few. (These are not my answers, this is what Google gave me!!!)😆

I says 🙋‍♂️

Let us start with answering where is JS running🏃‍♂️? Most of the time it is running inside our browsers. Nowadays, browsers are so complex and it has many engines, compilers, tokenizers, this and that, running together just to show us a web page. As JS is mighty, browsers have a dedicated engine only for JS called, JavaScript Engine ⚙️, shortened as JSE.

ECMAScript

Out there we have many browsers and they have their own tweaks and quirks for the JSE. But JS is guaranteed✅ to run the same everywhere. There shouldn’t be anything like, in Chrome but not in Firefox. This is where ECMA comes into the picture. ECMA is entrusted with standardising JS. And for this, ECMA has a general-purpose language called ECMAScript and JS is a language standardised based on it. That’s all about ECMAScript.

Oftentimes, one will come across terms like ES5 and ES6, associated with JS for sure. The JS community is so active and they come up with newer syntactic sugars (less code, do more) and new features, to keep the language up and going. With each year, ECMA releases a new version for JS specifications with new additions and features. These are being referred to as ES5(2009), ES6(2015) and so on (yeap, there is a career gap)🤣. When writing this article, the latest version of ECMA out is ES11. But it is up to the browsers what version to use and when to adopt new changes. As of today (mid-2020), ES5 is the only 100% all browser supported ECMA version.

Just-in-time complied

Computers💻 are dumb machines and they can only understand two states ON and OFF, or 0 and 1. But learning a binary language to code is cumbersome and too much. As developers most of the time we are coding in high-level languages which are more human-readable. Under the hood ⚒️, the high-level language code gets translated to machine friendly binary streams by translators👨‍🏫.

And currently, what we have is two types of translators out there. One guy is a pro, who translates the entire code and creates the low-level equivalent in a single go. The other guy is still a noob and can only translate the code line by line. We call the pros as compilers and the noobs as interpreters.

As of today, JS is said to be an interpreted language(I don't agree completely)🙊. That means code conversion and execution is always and only, one line at a time.

The past is history, the future is a mystery and the present is the only truth!

This is what, just in time compilation signifies.

First-class functions

And (un)fortunately, JS is a programming language with first-class functions. With that, we can assign a function to a variable, pass around the functions as arguments to other functions and return a function from another function. I would say the most beautiful and interesting trait of the language is evident when a function is returned from another function. (Sorry, out of scope for this article.)🙇‍♂️

🗽 This is not the end, but just a beginning

With all this said, we have just scratched the tip of an iceberg[🗻+🧊]. There are a lot of unsaid, and I am well aware. What I want to prove is, JavaScript is such a beautiful language. It is liberal enough that we don’t want to mention the data types of our variables and no yelling at missed semicolons (I know, it is a bad convention but still). This article lives its purpose if this makes you interested in learning more about the language and its nitty-gritty and helps you to admire its beauty 🏖️.

In upcoming articles, I will help you relive the splendours of JS. I help you understand how a single-threaded blocking/synchronous language runs the entire show on its own! (❓) I promise👍 it will not be the conventional syntax and code snippets explanations, but more will be of how things are done under the hood.

DEV Community: Shihabudheen US

OWASP top 10

🎣 [Hookable] ⚛️[React]

useState

useRef

useEffect

useContext

useReducer

Modules in JavaScript

Why modules?

What is a module?

Types of modules

ESModules

Working of Modules

Next.js: the new normal

What it offers:

Scripts

Routing

Navigation

Link component

Programmatic routing

Styling

Special files

_app.js

Next.js config

TS support

API routes

Data fetching

getStaticProps

getStaticPaths

getServerSideProps

getInitialProps

When to use what

Rendering modes

Deployment

CORS in short

What is CORS ❓

Why CORS❔

Linters: don't wait to test

ESLint

Installation

Configuration of ESLint

Configuration files

Available options

Ignoring files and directories

More read

Proxy in short

What is proxy❓

Why to use a proxy❔

VPNs

Build tools (purely front end)

Why build tools❓

What are build tools❔

Rethinking JS [short notes]

Mental model 🧠

Context

Values and Expressions

Values

Expression

typeof

Primitives are immutable

Variables

Counting Values

Equality in JS

Same Value

Strict Value

Loose Equality

Properties

Rules of reading a property

Assigning to a property

Mutation

Is Mutation that Bad?

Prototype __proto__

Prototype Chain

Shadowing

Assignments

Object prototype

Polluting prototype

proto vs. prototype

An async boring sync example😆

`_app.js`

`typeof`

Prototype `proto`