Forem: nagwan sami

What is JavaScript?!!

nagwan sami — Sun, 05 May 2024 14:13:53 +0000

If you decided one day to go into a discussion about Javascript, you will probably hear words like high-level, garbage-collected, interpreted, multi-paradigm, dynamic, prototype-based, and single-threaded, which may turn you into 🥱, 😵‍💫 or 🤨.

Each of these words explains an aspect of javascript, and putting them all together will help draw a mental image of javascript, the main goal of this writing, is to build this mental image 🤝.

Let’s start 🏁

High-level 👀: It simply means, we do not have to worry about the hardware staff, that’s it 🤷‍♀️.

Each program that runs on a computer needs some hardware resources, to do its work. Some programming languages are designed to be more developer-friendly, which means enabling the developers to focus on the functionality of the program rather than the low-level details of machine instructions, such as Python and Javascript these are called high-level programming languages.

Garbage collection 🧹: This is an algorithm inside the javascript engine that automatically removes old unused variables from the computer memory, to not block it with unnecessary stuff.

Oh, and for the weird word engine, do not worry we are going to discuss it in detail in another writing 🤞, temporarily consider it as a Javascript lab, it is where the javascript code is executed.

Interpreted 👩‍💻: Saying that Javascript is an interpreted language, is not 100% true, let’s break this down…

There are two main ways for a programming language to be translated into machine language 0s & 1s, compiling and interpreting.

Javascript uses a combination of the two techniques, so it is not purely an interpreted language.

You may now wonder, so why it is famed as an interpreted language?!!

There are many reasons for this that we may discuss later but for now, let’s say it is a kind of label javascript earned in its earliest days as browsers’ engines were mainly dependent on interpreting for code execution.

Multi-paradigm 🤓: a programming paradigm is a mindset and style in code structure flow and techniques.

The point is that some programming languages are limited to a single paradigm unlike Javascript, you choose your favourite paradigm and Javascript will stay as powerful as it is✌️, this is a kind of flexibility, don't you agree🤔?!

With the mention of flexibility, let’s discuss…

Dynamic 🕶: While using a dynamically typed language we do not need to explicitly set a variable data type, in other words, in dynamically typed languages data types are associated with values, not with the variables this explains why when it comes to initialising a variable in javascript we do not need to set a specific data type to it, it is just set when the code is executed, and we are still able to change a variable datatype by reassigning it, the debate around if this considered a pro or a con of JavaScript is there, but it is out of our scope.

Prototype-base 🧬: In JavaScript, almost everything has a template from which we can simply make a copy, this copy we can modify as much as we can but it still INHERITS the features of the main template we cloned it from. The template is what is called a prototype.

Now let's move to our last term which is…

Single-threaded 🫡: We can think of the word thread as it means task, so when we say single-threaded it means managing one task at a time, let’s try to understand this a little bit better.

There is a tight relationship between the core design of a programming language and the environment this language runs on.

Some programming languages are designed on their core to support multiple threads, like Python for example, while others are not like Javascript.

There should be a kind of harmony between a programming language and the environment it runs on, so if a language supports multiple threading the environment it runs on has to support it, otherwise, the language’s multithreading capabilities would be disabled which will cause many errors and unexpected behaviour, depending on the core code of the program.

Javascript was originally designed to make web pages more vivid, and browsers are single-threaded by nature, so even if the Javascript core is designed to handle multiple threading it wouldn't be useful in the traditional sense of web pages.

In light of the previously mentioned points, you may wonder, since JS code execution is done sequentially if any code takes a long time to execute, it will block anything that needs to be executed after that, but as we are interacting with web pages this does not seem to be the case!! so how 🤔?!!

The answer to this question requires going through the process of JavaScript code execution which we may cover in another writing, but simply, there is an execution mechanism in browsers that takes asynchronous actions, actions with delays e.g. API calls, to be handled away from the main thread, then these actions get back again to the main thread once they are done, this is not so nuanced, just to cut a long story short.

Hope this helps and thanks for reading. If you have any questions or topics you want me to write about I will be happy to help❤️.

why should we use React hooks?!

nagwan sami — Tue, 01 Dec 2020 17:43:37 +0000

Hooks 🤔 Hooks 👀 Hooks 🤨
What Hooks are 🙄

Personally cannot see better answer than the one mentioned in the official react docs 🤷

Hooks are a new addition in React 16.8. They let you use state and other React features without writing a class.

Mmm, Not convinced yet 😏, why we should even seek to replace classes 🙄

It is not a replacement rather than a recommendation and a new way of writing more elegant and neat code.

let's discuss one of the core and maybe the main difference between function and class component, and pointing out how hooks are gonna help us writing effortless code.

I LOVE this part😉

Class components do not capture the rendered values, while functional components DO.

Now it may be a 🙃, 🤔 or 🤨 moment, but wait ✋

An application UI is the representative of the current application state, with every change in the application state, or props we got a fresh new render for our UI, with everything included within, EVERYTHING here means everything even the event handlers used. Everything in the UI belongs to an EXACT particular render with EXACT particular data, (either state or props).

NOW, WHAT 🙄?!

check this snippet and let's do the following...

select a friend then press send msg

let's say you choose Adam you will see you choose Adam and after 3 seconds a message Hi Adam is printed, fair enough!

NOTE: the 3 seconds because we use setTimeOut() to wait for a while before printing the message.

select a friend then press send msg, and before the 3 seconds pass, select a different friend and press send msg again 👩‍💻

let's say in the first time you selected Sarah and then Adam,
what happened is, with your first click you see you choose Sarah and once you press again it changes to be you choose Adam,
BUT after 3 seconds the message printed is Hi sarah, your first choice, and after other 3 seconds the message changes to be Hi adam.

we agree this is the right behaviour and nothing abnormal or creepy is happening here, BUT again we need to emphasis this is happening because the function component capture the values rendered.

We may think of capture as saving or preserving the data and knows what to do with, which is not the case in a class component, let's check this snippet and repeat the exact same steps we have made above...

When we select a friend, let's say Adam, and before 3 seconds reselect another friend, Sarah, after 3 seconds we will not see our first choice, instead we are gonna see our last choice Hi sarah😵

let's take it step by step:

both function and class components access the selected value from their props, which is immutable CANNOT BE CHANGED, but in the class component, the props are accessible via this, which is mutable CAN BE CHANGED and it is meant to be.

so the props value gonna printed in the class component is taken from the new this, actually the very new this.

to solve 🔧 this, and make a class component capture its values during different renders we used to follow many approaches:

saving the props value in a variable😏

 let friend = this.props.friend

which is not the choice recommended, what if we have a fair number of props or we needed even to access functions and state, it is gonna be a real mess🤦.

tying up everything we need to a specific render, check this snippet

using this way everything needed is connected to a specific render.

this one of the core difference between class and functional components, and this difference actually used to cause a lot of problems and most of us stuck there for a while one day, but we had to use class components as we needed state, and lifecycle hooks and there was no alternative so we had to, but now with hooks, we do not have to any more😉.

Hope this helps, thanks for reading and if you have any questions or any topic you want me to write about I will be happy to help, and your comments and constructive notes are more than welcome ❤️

React synthetic events

nagwan sami — Tue, 28 Jul 2020 21:27:02 +0000

I would like a fresh start 😇

React
A JavaScript library used to build vivid shiny user interfaces🥰.

Event
The different ways the user uses to interact with an application, e.g. click, mouseover, input… etc

Synthetic
It is a ...🤔 Let's understand how React deals with events first.

React listens to every event at the document level, after receiving an event from the browser, React wraps this event with a wrapper that has the same interface as the native browser event, which means we still can use methods like preventDefault().

So what is the need for this wrapper?!!😏

think of a situation where the exact same event has different names across different browsers.

imagine an event that fires when the user winks😉, this event in chrome called A in Safari called B, in such case, we will need to make different implementations for each browser😵.

What this wrapper does is registering all the different names for the same event effect, winking in our case, with only one name, so in a case when we want to listen to our winking effect instead of being listening to A for chrome and B for Safari we just use onWink, which is the wrapper react creates around the real event.

So whenever we are triggering an event in a React component, we are not actually dealing with the real DOM event, instead, we are dealing with React's custom event type, a synthetic event.

Now close your eyes😴, but not this kind of closing😅, and in your memory remember all the onClick(s), onBlur(s), onChange(s) you have ever used in your react components, these are not the real ones, these are react's synthetic events😇.

So we do not have to think anymore about different browsers implementations, react makes creating cross-browsers applications much less painful, which means we can concentrate more on adding browsers prefixes to our CSS properties😅.

This is not the end, as this is not the only bright side of React's synthetic events😃. Another catchy benefit of synthetic events is that React reuses these events objects, by pooling them, which results in performance gains.

Once the event handler is invoked, an event handler is a method executed once an event is triggered, all the properties on this event object will be nullified, set to their empty/default states, to be ready to be reused again.

Till this point, everything looks amazing, and you might feel🧐, but you might also go through some 🤨, 🙄, or even 😤 moments once you see Warning: This synthetic event is reused for performance reasons in the browser.

What makes most of us go through 🤨, 🙄, and 😤 moments, is not that despite it is warning it is written in red, but it is actually accessing any event properties in the event handler function fails

Imagine the following:

import React, { useState } from "react"

const ExampleComponent = (() => {
  const [counter, setCounter] = useState()

  function handelArrowBtn(event) {
    if (event.keyCode === 40) { //down arrow button
      setCounter(counter - 1)
    } else if (event.keyCode === 38) { // up arrow button
      setCounter(counter + 1)
    }
  }

  return (
    <div>
      <input
        type="number"
        value={counter}
        onKeyDown={handelArrowBtn}
       />
    </div>
  )
})

export default ExampleComponent

This counter will neither be increased nor decreased. And our lovely red warning will be printed in the browser console.

Let's see what is happening here...

After the event handler function, handelArrowBtn() in our case, is invoked the object of our synthetic event, onKeyDown in our case, gets nullified, the old values to the keys within this object are no longer exist, the event object returned to its original state to be ready to be reused, and as this is an object, so our handelArrowBtn() has access to it by reference which means our function now has access to the event object with its original state(nullified version).

So, how can we solve this?!😯

Actually, this can be solved in many ways:

Store the event property we need

function handelArrowBtn(event) {
  let keyCode = event.keyCode
  if (keyCode === 40) {
    setCounter(counter - 1)
  } else if (keyCode === 38) {
    setCounter(counter + 1)
  }
}

or we may also pass the properties we want as arguments to the event handler function instead of directly accessing it from the function

return (
    <div>
      <input
        type="number"
        value={counter}
        onKeyDown={(e) => handelArrowBtn(e.keyCode)}
      />
    </div>
  )

Using event.persist() which will remove the synthetic event from the pool, which enables us accessing the event object properties in our code

function handelArrowBtn(event) {
   event.persist()
   if (event.keyCode === 40) { 
      setCount(count - 1)
    } else if (event.keyCode === 38) {
      setCount(count + 1)
    }
  }

Hope this helps and thanks for reading. If you have any questions or topics you want me to write about I will be happy to help❤️.

Javascript var, let and const

nagwan sami — Sat, 18 Jul 2020 20:15:59 +0000

I hate intros but we must have one 🤷

Before 2015 javascript developers used to use var as the keyword to declare variables, and life was easy, but not calm 😅

With using var to declare variables developers had to fight in many fields…

Redeclaration 🤦‍♀️
Believe it or not, with var you can use the same variable name as many times as you can without facing any errors, but you have to be ready for the unexpected results😬.

imagine the following:

function sayHi() {
    var name = "Our New User"
    var isLoggedIn = true

    if (isLoggedIn) {
        var name = "Sarah"
    }
    console.log("Hi" + name) // Hi Sarah
}

The first thing that comes to your mind now is, so what?!,
I redefine the variable, what the problem with that?!🤨 It is not a problem at all, as long as you know that is exactly what you want to do, not just that you forget that this variable has already declared before🧐.

The real problem with redeclaration comes with large apps, and once you forget that you have used the same variable name before.

DISCLAIMER✋: this won`t be a problem in case you have solid memory that helps you remember all the variables you have declared within a specific scope.

Scope 😵
The line above ends with the word SCOPE, before digging deeper, let`s first understand what scope is, think of scop as a box within which some functions and variables are accessible.

Chances are variables declared using var keyword are limitless, except if they are declared within a function.

This means if a variable is not inside a function it will be accessible in the whole app😨.

Now try to connect this point with the one before, redeclaration,
now developers have to remember all the variables they have declared in the global/function scope else they find themselves trapped with results they never expect.

Imagine the following…

function sayHi() {
    var name = "Our New User"
    var isLoggedIn = true
    if (isLoggedIn) {
        var name = "Sarah"
        console.log("Hi" + name) // Sarah
    }
    console.log("Hi" + name) // Sarah
}

The log inside the if block makes sense, as we are logging the variable defined within this block, but the log outside the if block is the one highlights the problem, it supposed to prints “Our New User” the value of the variable declared outside the if block, but what happens here is the variable name declared within the if block totally replaced the one declared outside the if block and here we have to mention hoisting.

Hoisting 😧
Hoisting is the process of lifting variables and functions declarations to the top of their scope.

Variables declared with the keyword var hoisted to the top of the global/function scope and initialized with the value undefined.

Connecting this with the previous point,

function sayHi() {
    var name = "Our New User"
    var isLoggedIn = true
    if (isLoggedIn) {
        var name = "Sarah"
        console.log("Hi" + name) // Sarah
    }
    console.log("Hi" + name) // Sarah
}

we now can find out what is happening here, the new variable declared within the if block is hoisted to the top of the function and of course replaced the original one, which justifies why the two console logs prints the same result.

Now as we went through the problems js developers spent a long time fighting with, now let`s move forward how ES2015 saved our day 😉.

Regarding redeclaration, variables declared using either let or const cannot be redeclared within the same scope.

Mentioning the scope, both let and const are block-scoped, a block of code is any set of code within {}, which means if a variable declared using either let or const within {} it won`t be accessible outside these {}, despite they are hoisted to the top of their scop, which is the {}.

Now let's check out our sayHi function...

function sayHi() {
    let name = "Our New User"
    var isLoggedIn = true // out of our scope
    if (isLoggedIn) {
        let name = "Sarah"
        console.log("Hi" + name) // Sarah
    }
    console.log("Hi" + name) // Our New User
}

Now it works as expected the new variable declared within the if block stays within the if block and it does not affect the one outside the if block

But now the question is, which one to use let or const 🤔?!
The answer is, whatever you want😇, just remember that variables declared with let can be updated while those created with const cannot.

Hope this helps and thanks for reading. If you have any questions or topics you want me to write about I will be happy to help❤️