DEV Community: Remon Fawzi

[Boost]

Remon Fawzi — Wed, 03 Sep 2025 11:17:43 +0000

Remon Fawzi

May 17 '25

Main differences between ReactJS and VueJS, in my opinion

#react #vue #programming #javascript

Comments 2

3 min read

CSS interview questions - 01

Remon Fawzi — Tue, 05 Aug 2025 13:33:15 +0000

In this series, we will have some CSS interview questions that cover the main concepts of CSS

01

We have this div element in our HTML

<div id="div" class="div"></div>

And, we have these styles in our CSS file

div.div {
  background-color: red;
}

#div {
  background-color: blue;
}

.div {
  background-color: yellow;
}

div {
  background-color: white;
}

Which background color will be applied to this div? And, why?

Each selector has a fixed number.

Id (starts with #) => 100
Class (starts with .) => 10
Attribute selectors (like [dir="rtl"]) => 10
Seudo classes (like :hover, :focus, :nth=of-type, ...) => 10
Element (div, p, ...etc) => 1
Seudo element (like ::before, ::after, and ::placeholder) => 1

Therefore, in the above example, it's blue because the highest-matched selector is the ID with a value of 100.

Notes

Each of the above CSS selectors has a specificity value.
CSS first looks for all matched selectors, then it calculates their specificities, and then decides which one will be applied.
By default, when specificities are equal, CSS will take the last selector, as it overrides the previous one.
Inline styles have more priority than external selectors.
The !important keyword overrides all other styles, even inline styles.

Quiz

What if we remove the ID selector from our CSS file? Which color will be applied in this case? And, why?

div.div {
  background-color: red;
}

.div {
  background-color: yellow;
}

div {
  background-color: white;
}

Thanks for reading.

Main differences between ReactJS and VueJS, in my opinion

Remon Fawzi — Sat, 17 May 2025 11:57:04 +0000

I'll state three main high level differences I see between React and Vue.

Syntax

As a frontend engineer, my first love is vanilla JavaScript, so when looking for a framework or a library, I love it to be closer to vanilla JavaScript.
So, for me, React has more advantages than Vue at this point, as React is all about pure JavaScript with some additional utilities.
Let's take one example: If I want to loop through some elements in React, I would use the JavaScript map function, while in VueJS, I would use the v-for directive, which is different from vanilla JavaScript. So, the template in React is close to vanilla JavaScript.

// Using VueJS
<template>
   <div v-for="element in elements" :key="element.id">{{ element.name }}</div>
</template>


// Using React
{
  elements.map(element => <div key={element.id}>{ element.name }</div>)
}

React currently has one official way of writing components (Functional components), while VueJS has two ways of writing components (CompositionAPI, OptionsAPI).
React has one way for defining state using the useState hook, while VueJS has two ways for defining state ref for all data types, and reactive specifically for reference data types.
This flexibility in VueJS is awesome, but it comes with a cost that if you look at different developers' codes, you'll see different coding styles, which sometimes make it harder for developers to adapt to each other's code.

So, for Syntax, I would go with React.

Performance

I'll focus on the Reactivity system of both of them, for sure, we can achieve good performance using each of them, but let's see which of them helps us achieve this more easily.
A React component has something called state. When any piece of this state changes, React re-renders the whole component by re-running all the JavaScript code in that component. Re-running the whole component's code is sometimes expensive. To prevent re-running everything, we use hooks like useMemo and useCallback.
So React developer needs to think about which piece of code is expensive to re-run, and try to decrease these re-runs or prevent them all. This is tricky.
On the other hand, in VueJS, Vue doesn't re-run the whole component's code with every state change, so you won't have expensive calculations that run unnecessarily, like React.
Vue computed function is easier than React's useMemo hook, as it detects what the value depends on without providing it.

// In React, I must tell React what my value depends on
const x = useMemo(() => y * z * w, [y, z, w])

// In VueJS, Vue's reactivity system will detect what my value depends on for me
const x = computed(() => y * z * w)

NOTE: I still didn't dive into React 19, as I know it handles many of these cases, so my opinion is comparing React 18 to Vue.

As a conclusion, I see that both of them can achieve good performance, but VueJS handles Reactivity out of the box. While React makes it easier to mess with Performance.

*So, for performance, I'll go with VueJS.
*

Community

VueJS's community is increasing, but React has more support currently.
So, for the community, I go with React.

Conclusion

Syntax, React is closer to vanilla JavaScript, so I prefer React when it comes to syntax.
Vue has a smarter reactivity system than React, so I prefer Vue when it comes to performance.
React has more community support than VueJS.

It's based on my own opinion and experience, so you may have different preferences, and it's okay. And I would like you to drop your opinion.

Thanks for reading!

Typescript interfaces vs type aliases

Remon Fawzi — Mon, 24 Feb 2025 18:52:50 +0000

In TypeScript there are two ways for defining the shape of an object.

Using interfaces:

interface Person {
     name: string;
     age: number;
}

Using type alias:

type Person = {
     name: string;
     age: number;
}

What are the differences between them?

1- Interfaces can only define the shape of objects, but types can be used to define any type.

type MyVar = string | number; // we can't do this with interfaces

2- Interfaces can be reopened

interface Person {
     name: string;
}

interface Person {
     age: number;
}

// Person must have the two properties name and age
const john: Person = {
     name: "John",
     age: 20
}

// This could be very helpful if I'm using an interface from a third-party library, so I can add more properties to the imported interface without creating a new one.

3- Interfaces can be inherited using the extends keyword

interface Animal {
     name: string;
}
interface Dog extends Animal {
     age: number;
}

// Multiple inheritance
interface Patient {
     id: number;
}

interface Husky extends Dog, Patient {
     order: number;
}

Inheritance can also be implemented with type alias using the & intersection operator

type Animal = {
     name: string;
};
type Dog = Animal & {
     breed: string;
};

Conclusion:

Interfaces are used to define objects' shapes.
Interfaces can be reopened.
Interfaces can be inherited using the extends keyword.
Both interfaces and type aliases can be used to define objects' shapes, but interfaces make more sense as they look more familiar when it comes to inheritance and OOP concepts.

TypeScript generics simplified

Remon Fawzi — Wed, 19 Feb 2025 14:56:54 +0000

What are generics in TypeScript?

Generics help us define functions or classes once, and expect different type declarations for them.

Let's start with an example
I want to create a function that takes an array and returns a random element of that array

function getRandomElement(arr:number[]) : number {
   const randomIndex = Math.floor(Math.random() * arr.length);
   return arr[randomIndex];
}

The above function takes an array of numbers and returns one random element of these numbers.

If I want to use the same function but with an array of strings, Typescript will complain, and I'll need to create another function that accepts an array of strings and returns a string.

Generic types are introduced to solve such situations, let's write our function using a generic type

function getRandomElement<GenericType>(arr:GenericType[]): GenericType {
    const randomIndex = Math.floor(Math.random() * arr.length);
    return arr[randomIndex];
}

Now our function takes a generic type which may be a string, number, or any other type, and returns an element of that type.

And this is how we would use our function

const randomElement1 = getRandomElement<number>([1, 2, 3])
const randomElement2 = getRandomElement<string>(['a', 'b', 'c'])

So, we pass a generic type that tells the function what to expect as parameters, and what to return.

Can we pass multiple generic types?

Yes, you can pass multiple generic types, let's see an example.

const merge = <T1, T2>(obj1: T1, obj2: T2): T1 & T2 => {
  return { ...obj1, ...obj2 };
};

And here's how we would use our function

merge<{ name: string }, { age: number }>({ name: "John" }, { age: 222 });

Typescript can also infer the generic types from the passed parameters

merge({ name: "John", age: 22 }, { age: 2 }); // TS will infer the generic types from the passed parameters

There's only one problem with our function, if anyone passes anything other than an object, it'll throw an error, cause we can only use spread operators here return { ...obj1, ...obj2 }; with objects.

We can solve this by setting constraints to our generic types, let's see how

const merge = <T1 extends object, T2 extends object>(obj1: T1, obj2: T2): T1 & T2 => {
  return { ...obj1, ...obj2 };
};

Using the extends keyword tells Typescript that the passed generic type should only match this extended type, so no one can pass anything other than an object.

And we can use any type as a constraint
Let's see one more simple example

type MyType = string | number;
const myFunction = <T extends MyType>(x: T) => { // My generic T will  be accepted only if it extends MyType
  return x;
};

We can also set default values to generic types, let's see how

const returnArr = <T = string>(): T[] => [];
returnArr<number>(); // TS knows it'll return an array of numbers
retrunArr(); // TS knows it'll return an array of strings by default

Note: To use one Generic type in a TSX file, you should append a comma for React to understand that it's a generic and not an HTML tag or a component

const arrow = <T,>(x: T) => {
    return x;
};

Conclusion

Typescript generics allow us to define reusable functions or classes that work with multiple types rather than a single type.
Generics help us define functions or classes once, and expect different behaviors from them.
We can pass a single or multiple generic types.
We can set default values for our generics.
Typescript is smart enough to infer our generics if they're used as parameters, or returned from our function.

Write better JavaScript and ReactJs code with Immerjs

Remon Fawzi — Mon, 01 May 2023 12:31:33 +0000

What is an immutable state?

It's a state that doesn't change over time.

So when we create an immutable object we don't change it's properties, If we need to change it's properties, we create a new copy of it and modify the properties as we want.

In JavaScript we can use both mutable and immutable states, We decide which is better for us, We can use Object.freeze() for example to make our object immutable.

Let's have an example, We've an object called state ...

const state = {
  id: 1,
  name: 'John',
  accounts: {
    facebook: {
      id: 'facebook',
      url: '/'
    },
    twitter: {
      id: 'twitter',
      url: '/'
    }
  }
};

We need to modify it's twitter account url and assign it to a new state without affecting the current state, So we would do something like this

const newState = {
  ...state,
  accounts: { ...state.accounts, twitter: { 
  ...state.accounts.twitter, url: '/newUrl' } }
};

This code has two main issues

It's so long in comparison to its purpose, I just want to update one property.
Readability is not so good, Why I'm seeing many properties and nested levels while I'm only updating one property?!

If we use ImmerJs, It'll be like this

const newState = produce(state, (draftState) => {
  draftState.accounts.twitter.url = '/newUrl';
});

Here, we can see

Shorter code
More readable, I'm only seeing the property I'm changing!

So, Immerjs produce function creates a new draft copy of your object or array, And let you modify it as you want, Then returns you a new state with the changes you applied.

In React

All states are immutable, When we set a state we create a new variable and assign it to the state, We don't change the current one

Let's have an example

const [quiz, setQuiz] = useState({
   title: "Quiz 1",
   questions: [
      {
        id: "1",
        type: "mcq",
        title: "Question 1?",
        answers: [
           {
             id: "a_1",
             text: "Answer 1",
             isTrue: true
           },
           {
             id: "a_2",
             text: "Answer 2",
             isTrue: false
           }
        ]
      }
   ]
});

We've a state holds an object, What if we want to push a new answer to the quiz? We would do something like this

const addAnswer = (questionId, newAnswer) => {
  setQuiz({
    ...quiz,
    questions: quiz.questions.map((question) =>
      question.id === questionId
        ? { ...question, answers: [...question.answers, 
         newAnswer] }
        : question
    )
  });
};

Complex, right? Here's how it's done using Immerjs

const addAnswer = (questionId, newAnswer) => {
  setQuiz(produce(prev, (draft) => {
      const question = draft.questions.find((el) => el.id === questionId);
      question.answers.push(newAnswer);
    }
  );
};

So it's not just about reducing amount of code, But we only focus on what we need to change "The answer", without caring about the other quiz properties.

There's also a light package use-immer contains a custom hook useImmer, It's used instead of useState to call the produce function automatically when setting a state

const [quiz, setQuiz] = useImmer({
   .....
});

It'll make our code more simpler

const addAnswer = (questionId, newAnswer) => {
  setQuiz((draft) => {
    const question = draft.questions.find((el) => el.id === questionId);
    question.answers.push(newAnswer);
  });
};

This awesome package immerjs makes Redux toolkit too much simpler than old redux pattern, It's automatically implemented there, So you don't need to use the many spread operators just to change one value in your reducers.

Thank you so much!

JavaScript tip to efficiently search in long arrays and save performance

Remon Fawzi — Fri, 27 Jan 2023 00:11:40 +0000

Let's assume We've this array contains 100 elements

const arr = [
  {
    id: 1,
    value: "Hello 1",
  },
  {
    id: 2,
    value: "Hello 2",
  },
  .....
  {
    id: 100,
    value: "Hello 100",
  },
];

When we try to search for any element in this array by ID for example

const element50 = arr.find(el => el.id === 50);

The time complexity here is O(n), n is the number of array elements, Which means in the worst case if I'm looking for the last element, It'll loop on all array elements to find that last element, And if We search a lot in this array it'll affect app performance so badly.

What we can do here is mapping this array to be an object of keys and values, Keys are the item we search by, In our case it's the ID, And values are the remaining attributes ...

So let's create our new object

const arr = [
  {
    id: 1,
    value: "Hello 1",
  },
  {
    id: 2,
    value: "Hello 2",
  },
  {
    id: 100,
    value: "Hello 100",
  },
];
let arrayMap = {};
arr.forEach(el => {arrayMap[el.id] = el});

Now our object arrayMap will be like this

{
  1: {
    id: 1,
    value: "Hello 1",
  },
  2: {
    id: 2,
    value: "Hello 2",
  },
  ....
  100: {
    id: 100,
    value: "Hello 2",
  },
}

So now if we want the 50th element We'll do this

const element50 = arrayMap[50];

Now time complexity will be O(1), It won't loop on other elements to find the element we want, It'll just get it as an attribute from our new object .. By this We'll save a lot of operations especially if We search a lot in a large array.

So here're the steps We follow to make search in arrays more efficient

Create a new empty object
Map our array to be keys and values in our object, Keys are what we search by, And values are the object itself
We search using object square brackets, EX: obj[id]

The only one limitation when using this trick is that We can only search for an exact value, For example we can't use it to search for an element that includes a specific text, But we can do for an element that exactly equals a specific text.

Conclusion:

Time complexity for searching in arrays is O(n)
Time complexity for indexing an object attribute is O(1)
By mapping our array to an object then find elements by indexing this object, We decrease time complexity from O(n) to O(1)

Happy coding!

Don't use useEffect unnecessarily

Remon Fawzi — Tue, 10 Jan 2023 23:05:09 +0000

In this post We'll prove that in 90% of our components we don't need to write a useEffect ...

First question, When does useEffect run?

const User = ({name}) => { // 1
  const [initials, setInitials] = useState(""); // 2
  useEffect(() => {
    setInitials(name.split(" ").map(str => str.charAt(0))); // 4
  }, [name]);
  return (
    <p>{initials}</p> // 3
  );
};

React will render this component in this sequence:

Read the prop name, let's say it's value is "John Doe".
Define the state called initials and give it the empty string as initial value.
Return the JSX with this initial value, So initials will be an empty string.
Run the function passed to the useEffect hook which sets the name to be "John Doe"
Return the new JSX which now has initials as JD

So our component already had the value "John Doe" from beginning, But useEffect made it render twice! ... Let's get rid of this additional render ...

const User = ({name}) => { // 1
  const initials = name.split(" ").map(str => str.charAt(0)); // 2
  return (
    <p>{initials}</p> // 3
  );
};

Now React will

Read the value of name
Calculate initials
Return the JSX with the right value, Without the need of rendering the component again!

What if the previous component has more renders due to change in other props, It'll recalculate the initials in every new render, right? Yes, But instead of using a useEffect and putting the name in the dependency array ... We can easily use the useMemo hook not to recalculate the value with every new render!

const User = ({name, age, email}) => { // 1
  const initials = useMemo(() => {
    name.split(" ").map(str => str.charAt(0)); // 2
  }, [name]);
  return (
    <p>{initials}</p> // 3
  );
};

Component will not recalculate initials when age or email changes!

So let's put this rule in our minds whenever We're creating a React component ...

Anything that could be calculated from props or state, Shouldn't be calculated inside a useEffect

We've all misused the useEffect hook to achieve things that could be easily achieved without using it and without the need of having additional renders which decrease page performance.

There's only one case in which you have to use useEffect, If you want to do something when component mounts (displayed for the first time), this thing is external (API fetch, subscribing to event, Applying something to a DOM element), Simply it's not depending on state or props ... So it'll be something like this

useEffect(() => {
    const fetchedPosts = fetch('....');
}, [])

Conclusion

useEffect should be your last choice
useEffect runs after rendering your component, So if it makes any change to state, it'll cause additional renders
Anything that could be calculated from props or state, shouldn't be calculated inside a useEffect
You can use useMemo for expensive calculations
You can use useEffect only if you want to do something external (Ex: API fetch) when component mounts (First render only)

Thank u!

What you should know about React Key Prop

Remon Fawzi — Mon, 26 Dec 2022 23:52:02 +0000

In this post we'll understand what is React key prop used for, and how should we use it

React has it's virtual DOM, it applies changes on this virtual DOM, then calculates the difference between this virtual DOM and the real DOM that appears on browser

As we can see React has the virtual DOM in a tree, When a state changes it determines the affected nodes, then apply changes to them, then it applies differences to the real DOM

In case of rendering lists React needs to identify exactly each element, Why? Imagine having a simple component like this

const TodoList = () => {
  const [todoList, setTodoList] = useState([
    {id: 1, text: 'Playing football'},
    {id: 2, text: 'Studying'},
    {id: 3, text: 'Sleeping'}
  ]);
  return (
    <ul>
      {todoList.map((item) => (
        <li>{item.text}</li>
      ))}
    </ul>
  );
};

export default TodoList;

In virtual DOM this component will be presented like this

As we can see, the li elements depends on the todoList state, And every time we set this state (Adding, modifying or removing items from the todoList) we'll be setting a new array to it with a new reference, So React will take the new array and create new li elements using the new array ... Here exactly React needs something that identify the old elements that were already rendered using the previous state not to recreate them, That's why they created the Key Prop

To have a valid Key prop, it should

Have a constant value that doesn't change with each render, so we shouldn't do something like this

return (
    <ul>
      {todoList.map((item) => (
        <li key={Math.random()}>{item.text}</li>
      ))}
    </ul>
);

Math.random() will be called with every render and generate a new random value, So every render React will identify all elements as new elements and create them from scratch which leads to a weak performance

Instead, We should have a key that doesn't change with new renders, Like id coming from DB or even an id generated with Math.random() but created in the initialization only

const TodoList = () => {
  const [todoList, setTodoList] = useState([
    {id: Math.random(), text: 'Playing football'},
    {id: Math.random(), text: 'Studying'},
    {id: Math.random(), text: 'Sleeping'}
  ]);
  return (
    <ul>
      {todoList.map((item) => (
        <li key={item.id}>{item.text}</li>
      ))}
    </ul>
  );
};

It should be unique per siblings, So each sibling should have a different key than it's siblings

*Why shouldn't we use index as a key?
*

  return (
    <ul>
      {todoList.map((item, index) => (
        <li key={index}>{item.text}</li>
      ))}
    </ul>
  );

React uses index as a default key if We don't assign a key, But the risk here is that if We add an element to the beginning of the array it'll have key=0 which was the key of the current second element of the array, Same thing will happen if we add or remove elements from the array.
This will be very clear if we use inputs as an example

   {todoList.map((item, index) => (
     <li key={index}>
        <p>{item.text}</p>
        <input />
     </li>
   ))}

The first item here has a key=0, If we write anything in it's input, then add a new item to the beginning of our todo list, The new added item will have key=0, and the old item which we've written in it's input will have key=1, Now on the screen we'll see what We've written in the second item appearing in the first item cause React identifies the element only by it's key ... That's why index is not preferred to be used as a key

There's another one good hack about keys, For React a new key means a new element with new states ... And sometimes we need to reset component states, What we usually do in this case we create a useEffect and listen to a variable then reset states when this variable changes, Like this example

  const [posts, setPosts] = useState([]);
  const [comments, setComments] = useState([]);
  const [likes, setLikes] = useState([]);

  useEffect(() => {
    setPosts([]);
    setComments([]);
    setLikes([]);
  }, [useId]);

Instead of doing this, We can simply pass userId as a key to this component and when userId changes, it'll have a new key and a *new states
*

<UserProfile key={userId} />

Conclusion

Key is important for React not to recreate list items
Key must be unique for each sibling
Key must have a constant value that doesn't change while rendering
Index isn't preferred to be used as a key
Key can be used to reset component states

Thank u!

Why useState hook returns array and not object? Let's create a custom hook to see

Remon Fawzi — Sun, 14 Aug 2022 22:04:00 +0000

Hello, Have you ever asked why returning arrays from functions became trendy nowadays?

As we all know react hooks like useState, useEffect or useRef could only be used in the top level of a component and can't be used inside a function, custom hooks are functions where we can use React hooks inside of them.

let's see our example without using custom hook ...

import React, { useState, useEffect } from "react";

const Form = () => {
  const [name, setName] = useState(
    JSON.parse(localStorage.getItem("name")) ?? ""
  );
  const [email, setEmail] = useState(
    JSON.parse(localStorage.getItem("email")) ?? ""
  );

  useEffect(() => {
    localStorage.setItem("name", JSON.stringify(name));
  }, [name]);
  useEffect(() => {
    localStorage.setItem("email", JSON.stringify(email));
  }, [email]);
  return (
    <form>
      <input type="text" value={name} onChange={e => setName(e.target.value)} />
      <input
        type="text"
        value={email}
        onChange={e => setEmail(e.target.value)}
      />
      <button>Register</button>
    </form>
  );
};

export default Form;

So, We've a react component contains a form of two inputs, the target is to save user's inputs in localStorage and retrieve them when he comes back.

So We've a state for each input, which is initialized from stored value or an empty string, onChange we set state with the new value, and We've a useEffect to set the value to localStorage when changed.

This is fine, but let's build the same example using custom hook to see the difference ...

import { useState, useEffect } from "react";

export default function useStoreInput(storageKey) {
  const [value, setValue] = useState(
    JSON.parse(localStorage.getItem(storageKey)) ?? ""
  );

  useEffect(() => {
    localStorage.setItem(storageKey, JSON.stringify(value));
  }, [value, storageKey]);

  return [value, setValue];
}

This is simply our custom hook, It's a normal function that uses React hooks, We pass localStorage key name to it, and it defines a state for us and initialize it with the value from localStorage as before, then it listens to this state and store it to localStorage when changed.

As we can see we've chosen to return array [value, setValue] and not an object, We'll see why ...

Let's see our component uses our new custom hook ...

import React from "react";
import useStoreInput from "./useStoreInput";

const Form = () => {
  const [name, setName] = useStoreInput("name");
  const [email, setEmail] = useStoreInput("email");

  return (
    <form>
      <input type="text" value={name} onChange={e => setName(e.target.value)} />
      <input
        type="text"
        value={email}
        onChange={e => setEmail(e.target.value)}
      />
      <button>Register</button>
    </form>
  );
};

export default Form;

As we can see when using custom hooks we didn't see any code repetition in our component, that's because of two reasons ...

custom hooks are great to extract component's logic in a simple function, it also makes our logic reusable for any other input.
returning arrays make it easier and cleaner to destructure values, We only give names to the returned array elements.

If we've decided to return object instead of array, our component would look like this

import React from "react";
import useStoreInput from "./useStoreInput";

const Form = () => {
  const { value: name, setValue: setName } = useStoreInput("name");
  const { value: email, setValue: setEmail } = useStoreInput("email");

  return (
    <form>
      <input type="text" value={name} onChange={e => setName(e.target.value)} />
      <input
        type="text"
        value={email}
        onChange={e => setEmail(e.target.value)}
      />
      <button>Register</button>
    </form>
  );
};

export default Form;

So every time I use the hook I'd tell it to rename value and setValue with new names.

This is exactly why useState() hook returns array and not object

const [counter, setCounter] = useState(0);

So react creators have chosen to return array from the hook to make it easier to destructure the returned array and define new states.

It's not only about hooks or React or even JavaScript, You can think the same way if you use a language that supports destructuring.

Returning arrays is awesome but for sure it depends on your case, let's assume if we've a function that returns 10 properties but we don't always use all properties, in some cases We only use the 8th element, also maintaining code in this case would be so hard, so it's not always a right decision to return an array.

Thank you!