DEV Community: Mensur Duraković

Code Untangled: Immutability

Mensur Duraković — Tue, 05 Sep 2023 07:42:02 +0000

You heard about the term "immutability" in programming.

But why is immutability an important concept? Why is it mentioned so often in programming and especially in the front-end world?

Immutability refers to the concept that you can't change the property of a data structure after its creation. For example, an immutable object remains constant throughout its lifetime.

Immutability as a concept has significant implications in programming languages. Especially in areas of data handling and manipulation.

Some characteristics of the immutability concept:

Freezy: Once you create an immutable object, you "freeze" its values. You can't change that object anymore. If you want to make the change, you have to create a new object. Then you apply the change to finally overwrite the original object.
Predictability: Immutable objects don't change state, so they have a predictable behavior. This is especially valuable in concurrent or parallel programming.
Safety: Immutability contributes to a safer code. With that, I mean eliminating the risk of unexpected changes that can occur in the code. You can reduce bugs caused by modifying shared, which leads to more reliable code.
Threads friends: Immutable objects are thread-safe. Many threads can access and use immutable objects. This goes without the need for explicit synchronization mechanisms. There's no risk of one thread modifying the object while another is using it.
Functional as it gets: Immutability is a core principle in functional programming. It encourages the use of pure functions that don't have side effects. It also operates only on their inputs, making code easier to reason about and test.
Cachy and memoy: Immutable objects are easily cached and reused. That's because their values don't change.
Undo/Redo friendly: In text editors, immutability simplifies implementing undo and redo functionality. This is achieveable preserving the previous states of objects. Besides text editors, this can be applicable to any application.

Now, let's understand the basics through some code examples.

Mutable data

What's mutable data?

Mutable data is data that you can change without creating a new value. In JavaScript, the best examples are arrays and objects, so let's take a look at this code:

const users = ["didier"]
const newUsers = users

users.push("john")

console.log({users, newUsers});
//prints {users: ["didier", "john"], newUsers: ["didier", "john"]}

console.log(users === newUsers)
//prints true

Even though we added "john" to the users array, the change is reflected in the newUsers array also.

Why?

Because in the 2nd line, we made a mistake. If we wanted newUsers to have all values from users array we should do it like this:

const newUsers = [...users]

Then we wouldn't have this problem.

But since, the code is written like that, both of these arrays point to the same reference. So if you change the data in one array you will change the other one as well.

That's why you get true as a result when you compare users and newUsers with shallow comparison. Shallow comparison uses an equality operator.

Any change in the mutable data is not detectable via shallow comparison. The "===" operator can not tell if the content of the array changed.

Immutable data

Immutable data is data that cannot be changed or modified after it is created. So only way to change that data is to create a new value and overwrite it.

In JavaScript, strings are a good example of immutable data:

let player1 = 'didier'
let player2 = player1
player1 = player1.concat(' drogba')

console.log({player1, player2})
// prints {player1: 'didier drogba', player2: 'didier'}

console.log(player1 === player2)
// prints false

If we compare this example to the previous one, we can see that we did the same thing. The difference is that here the value is not reflected on the second variable - player2 after we change the value in player1.

That's because .concat() doesn't change the value of the original string. It creates and returns a completely new string.

So we can say that strings, booleans, and numbers in JavaScript are immutable.

Why is immutability important?

You are asking yourself now, ok but why is immutability so important?

Well, it's important because some of the core concepts are based on immutability. Let's take React for example and how re-rending works:

function App() {
  const [users, setUsers] = useState([])

  const fetchUserData = () => {
    fetch("https://jsonplaceholder.typicode.com/users")
      .then(response =>  response.json())
      .then(data => {
        setUsers(data)
      })
  }

  useEffect(() => {
    fetchUserData()
  }, [])

  if(users.length === 0){
    return <div>No users available</div>
  }

  return (
    users.map(user => <User key={user.id} userData={user}/>)
  )
}

We know how React's useState hook works, but let's repeat. Whenever the component state changes, React will re-render that component. So React is watching changes in the users variable and then acts accordingly.

To be able to detect changes in the state, React uses shallow comparison between the old and new states. Then it decides if it needs to re-render the component or not.

Now, let's do something stupid in the code:

function App() {
  const [users, setUsers] = useState([])

  const fetchUserData = () => {
    fetch("https://jsonplaceholder.typicode.com/users")
      .then(response =>  response.json())
      .then(data => {
        users.push(...data)
        setUsers(users)
      })
  }

  useEffect(() => {
    fetchUserData()
  }, [])

  if(users.length === 0){
    return <div>No users available</div>
  }

  return (
    users.map(user => <User key={user.id} userData={user}/>)
  )
}

In the example above, when the data is fetched, we are pushing the data in users array with the spread operator. Then, we set new data by passing users variable into setUsers.

Photo by roman raizen

I know, it's horrible. Your eyes are bleeding but bear with me.

So in the example above, React will not be able to detect any change in the state. Why? Because we are directly modifying the users array.

As a side-effect of our horrible code, React won't re-render the component when the data is fetched.

Immutability and performance

Before we stated that React uses shallow comparison for detecting component state changes. It's doing that because comparison by value could result in slow performances.

Let's take a look at this example:

function App() {
  const [blocks, setBlocks] = useState(new Array(10000).fill({active: false}))

  const onClickHandler = (blockIndex) => {
    const updatedBlocks = blocks.map((block, index) => {
      return index === blockIndex ? {active: !block.active} : block
    }) 
    setBlocks(updatedBlocks);
  }

  return (
    blocks.map((block, index) => <button 
    key={index} 
    style={{backgroundColor: block.active ? 'green' : 'gray', width: '50px', margin: '4px'}} 
    onClick={() => onClickHandler(index)}>
      {index + 1}
    </button>)
  )
}

This component above is a simple button-click grid with 10,000 buttons displayed. On button click we find that button and check if it's active. if yes, we switch the color to gray, otherwise, if it's not active we set the color to green.

This line is very interesting:

const [blocks, setBlocks] = useState(new Array(10000).fill({active: false}))

Here we create a new array of 10k objects.

So imagine, React would perform state changes by checking the value. It would be very slow. Instead, React uses shallow comparison for state change detection.

So, this piece of code is very expensive:

const onClickHandler = (blockIndex) => {
  const updatedBlocks = blocks.map((block, index) => {
    return index === blockIndex ? {active: !block.active} : block
  }) 
  setBlocks(updatedBlocks);
}

Here, we create a new array every time a user clicks on the button. We know that inside that array, 9999 objects will remain the same, while only one will be changed. With that, we set the changed array in setBlocks, and the state is changed.

Creating a new variable of state objects to keep the state immutable can be expensive sometimes. There are techniques like memoization to fix this slow behavior.

Conclusion

Immutability is a vital concept in programming. Due to its capacity to ensure predictability, and enhance reliability, it's very important.

By prohibiting the alteration of data after creation, immutability guarantees consistent behavior. It also reduces the likelihood of unexpected bugs, fostering more dependable code.

Write Code Like a Senior: 5 Must-Know Tips for Crafting Code

Mensur Duraković — Mon, 28 Aug 2023 13:57:58 +0000

In this article, we are talking about 5 simple tips you can start using this moment to improve your code quality.

No matter what programming language you use or how many years of experience you have, you can use these tips in your daily work.

So let's start.

1) Nesting and early returns

For sure, everyone encountered some heavy nested code in their projects.

Nested code refers to code structures where one block of code contains another. This often results in many levels of indentation. While nested code isn't bad, excessive nesting can lead to several issues. These issues can make code harder to, maintain, and debug.

Nesting can be problematic because:

Complexity and readability - it's very hard to read nested code
Maintenance - comes as a side-effect of the first point, nested code is harder to maintain
Debugging - it's harder to debug nested code
Scoping issues - often variables overlap and cause scoping issues
Testing - it's harder to write tests for heavy nested code

Take a look at this code snippet:

if (user && user.isAuthenticated) {
  // ...20 lines of code

  if (timezone) {
    // ...10 lines of code

    if (isQualified) {
      // ...50 lines of code
    }
  }
}

what should be done instead?

const userAuthenticated = user && user.isAuthenticated;
if (!userAuthenticated) {
  return;
}

// ...20 lines of code
const timezone = ...
if (!timezone) {
  return;
}

// ...10 lines of code
const isQualified = ...
if (!isQualified) {
    return;
}

// ...50 lines of code

You see how much better this is. There are no indentations and everything is much easier to read.

Another thing related to nesting is the early return concept.

Early return is a programming concept where a function exits and returns a value before completing its code. This is often used to handle special cases or error conditions.

Let's take a look at this example:

function getDailyRewards(user){
    if(user.isAuthenticated){
        // ...50 lines of code
    }
}

This if condition wraps ~50 lines of code. Ugly as hell. Let's rewrite it:

funcion getDailyRewards(user) {
  if (!user.isAuthenticated) {
    return;
  }

  // ...50 lines of code
}

Much better.

Instead of wrapping the whole code logic with an if condition we exit early if a user is not authenticated. The rest of the code is below the guard clause and it's much easier to read it.

2) Useless if/else blocks

This one is specific to beginners. I like to bug my students on exercises when they write useless if/else blocks in the code.

Here is one classic example:

function isEven(number) {
  if (number % 2 === 0) {
    return true;
  } else {
    return false;
  }
}

When I see code like this, I ask them if they can write it shorter, more elegant. Then, some of them do something like this:

function isEven(number) {
  if (number % 2 === 0) {
    return true;
  }
  return false;
}

Then I ask them if they can write those 4 lines in 1 line. Then they do something like this:

function isEven(number) {
  return number % 2 === 0 ? true : false; 
}

Again, I ask them if they can do it without if/else or ternary operator, and then finally we get something like this:

function isEven(number) {
  return number % 2 === 0;
}

Here is one more example, similar to first case:

function getScheduleKey() {
  const hasSchedule = this.hasTeleVisitScheduled();
  if (hasSchedule) {
    return this.schedule.key;
  } else {
    return this.schedule.cancelSchedule.key;
  }
}

If you look closely, there is no need to write else block here. The function is ending and there is a return anyway.

So we can fix it like this:

function getScheduleKey() {
  const hasSchedule = this.hasTeleVisitScheduled();
  if (hasSchedule) {
    return this.schedule.key;
  }
  return this.schedule.cancelSchedule.key;
}

The moral of the story, avoid useless if/else blocks.

3) Hardcoded strings and numbers

Hardcoding strings and numbers embed values into your code. Instead of using variables or constants to represent them.

Photo by Marcos Mayer

There are several reasons why hardcoding values are generally considered bad practice:

Lack of flexibility and maintainability: If you hardcode values throughout your codebase, making changes to those values requires finding and modifying each occurrence. This means if you hardcoded a string 100 times in the code and after 2 months you need to change that string, you will need to change it again in 100 places.
Reusability: Hardcoding values make it difficult to reuse the same code in different contexts. If you want to use the same logic with different values, you would need to duplicate the code. Then you can change the values, and this is leading to code duplication.
Readability: Code with hardcoded values can become harder to read and understand. Especially for other developers who might not be familiar with the context. Meaningful variable names make the purpose of the value more clear.
Debugging and error detection: When errors occur, it's easier to spot mistakes if you're using named variables or constants.
Scalability: As your project grows, maintaining hardcoded values becomes challenging. Changing a single value across the codebase can become a tedious and error-prone task.
Localization and internationalization: If your code needs to support many languages or locales, hard-coded values can make it difficult to translate.
To conclude, it's bad to have hardcoded strings and numbers in your code.

Now, let's take a look at this beautiful example that inspired me to write this article. It was much longer in original form, but here is shorter version with fewer if conditions:

if (fitnessTrainingSchedule.name == "Training 03 Schedule") {
  checkWindowForTrainingSchedule(10, 16, "Milestone3Schedule", "Training 03 Schedule");
}
if (fitnessTrainingSchedule.name == "Training 04 Schedule") {
  checkWindowForTrainingSchedule(24, 30, "Milestone4Schedule", "Training 04 Schedule");
}
if (fitnessTrainingSchedule.name == "Training 05 Schedule") {
  checkWindowForTrainingSchedule(52, 58, "Milestone5Schedule", "Training 05 Schedule");
}
if (fitnessTrainingSchedule.name == "Training 06 Schedule") {
  checkWindowForTrainingSchedule(80, 86, "Milestone6Schedule", "Training 06 Schedule");
}
if (fitnessTrainingSchedule.name == "Training 07 Schedule") {
  checkWindowForTrainingSchedule(108, 114, "Milestone7Schedule", "Training 07 Schedule");
}
if (fitnessTrainingSchedule.name == "Training 08 Schedule") {
  checkWindowForTrainingSchedule(136, 142, "Milestone8Schedule", "Training 08 Schedule");
}
if (fitnessTrainingSchedule.name == "Training 09 Schedule") {
  checkWindowForTrainingSchedule(164, 170, "Milestone9Schedule", "Training 09 Schedule");
}
if (fitnessTrainingSchedule.name == "Training 10 Schedule") {
  checkWindowForTrainingSchedule(216, 230, "Milestone10Schedule", "Training 10 Schedule");
}

On the first look, you can see a bunch of numbers and strings that are similar but you have no clue what is this code doing. All you know it is doing something with fitness training schedules. To understand this code, you need to take a look in other scripts.

Let's see the refactored version:

const TRAINING_SCHEDULE_03 = {
  name: "Training 03 Schedule",
  milestone: "Milestone3Schedule",
  startDaysInterval: 10,
  endDaysInterval: 16
};
const TRAINING_SCHEDULE_04 = {
  name: "Training 04 Schedule",
  milestone: "Milestone4Schedule",
  startDaysInterval: 24,
  endDaysInterval: 30
};
const TRAINING_SCHEDULE_05 = {
  name: "Training 05 Schedule",
  milestone: "Milestone5Schedule",
  startDaysInterval: 52,
  endDaysInterval: 58
};
const TRAINING_SCHEDULE_06 = {
  name: "Training 06 Schedule",
  milestone: "Milestone6Schedule",
  startDaysInterval: 80,
  endDaysInterval: 86
};
const TRAINING_SCHEDULE_07 = {
  name: "Training 07 Schedule",
  milestone: "Milestone7Schedule",
  startDaysInterval: 108,
  endDaysInterval: 114
};
const TRAINING_SCHEDULE_08 = {
  name: "Training 08 Schedule",
  milestone: "Milestone8Schedule",
  startDaysInterval: 136,
  endDaysInterval: 142
};
const TRAINING_SCHEDULE_09 = {
  name: "Training 09 Schedule",
  milestone: "Milestone9Schedule",
  startDaysInterval: 164,
  endDaysInterval: 170
};
const TRAINING_SCHEDULE_10 = {
  name: "Training 10 Schedule",
  milestone: "Milestone10Schedule",
  startDaysInterval: 216,
  endDaysInterval: 230
};

if (fitnessTrainingSchedule.name == TRAINING_SCHEDULE_03.name) {
  checkWindowForTrainingSchedule(
    TRAINING_SCHEDULE_03.startDaysInterval,
    TRAINING_SCHEDULE_03.endDaysInterval,
    TRAINING_SCHEDULE_03.milestone,
    TRAINING_SCHEDULE_03.name
  );
}
if (fitnessTrainingSchedule.name == TRAINING_SCHEDULE_04.name) {
  checkWindowForTrainingSchedule(
    TRAINING_SCHEDULE_04.startDaysInterval,
    TRAINING_SCHEDULE_04.endDaysInterval,
    TRAINING_SCHEDULE_04.milestone,
    TRAINING_SCHEDULE_04.name
  );
}
if (fitnessTrainingSchedule.name == TRAINING_SCHEDULE_05.name) {
  checkWindowForTrainingSchedule(
    TRAINING_SCHEDULE_05.startDaysInterval,
    TRAINING_SCHEDULE_05.endDaysInterval,
    TRAINING_SCHEDULE_05.milestone,
    TRAINING_SCHEDULE_05.name
  );
}
if (fitnessTrainingSchedule.name == TRAINING_SCHEDULE_06.name) {
  checkWindowForTrainingSchedule(
    TRAINING_SCHEDULE_06.startDaysInterval,
    TRAINING_SCHEDULE_06.endDaysInterval,
    TRAINING_SCHEDULE_06.milestone,
    TRAINING_SCHEDULE_06.name
  );
}
if (fitnessTrainingSchedule.name == TRAINING_SCHEDULE_07.name) {
  checkWindowForTrainingSchedule(
    TRAINING_SCHEDULE_07.startDaysInterval,
    TRAINING_SCHEDULE_07.endDaysInterval,
    TRAINING_SCHEDULE_07.milestone,
    TRAINING_SCHEDULE_07.name
  );
}
if (fitnessTrainingSchedule.name == TRAINING_SCHEDULE_08.name) {
  checkWindowForTrainingSchedule(
    TRAINING_SCHEDULE_08.startDaysInterval,
    TRAINING_SCHEDULE_08.endDaysInterval,
    TRAINING_SCHEDULE_08.milestone,
    TRAINING_SCHEDULE_08.name
  );
}
if (fitnessTrainingSchedule.name == TRAINING_SCHEDULE_09.name) {
  checkWindowForTrainingSchedule(
    TRAINING_SCHEDULE_09.startDaysInterval,
    TRAINING_SCHEDULE_09.endDaysInterval,
    TRAINING_SCHEDULE_09.milestone,
    TRAINING_SCHEDULE_09.name
  );
}
if (fitnessTrainingSchedule.name == TRAINING_SCHEDULE_10.name) {
  checkWindowForTrainingSchedule(
    TRAINING_SCHEDULE_10.startDaysInterval,
    TRAINING_SCHEDULE_10.endDaysInterval,
    TRAINING_SCHEDULE_10.milestone,
    TRAINING_SCHEDULE_10.name
  );
}

This code is definitely longer but it's more readable and understandable. You can see what this code is doing and what is the meaning of the parameters.

Of course, it's far from perfect code. It contains a lot of repetitive code which we are gonna fix next.

4) Repetitive code

Code repetition is also known as code duplication. It refers to having the same or similar blocks of code appear in many places within a project. Code repetition is generally considered bad in programming for several reasons:

Maintenance complexity: When the same code appears in many places, any changes or updates to that code need to be made in all those places. This increases the risk of introducing errors. It also makes maintenance more difficult and time-consuming.
Bug propagation: If there is a bug in the repeated code, it needs to be fixed in every instance. Missing even one instance could lead to inconsistent behavior or unexpected issues.
Readability and understanding: Repeated code can make the codebase harder to read and understand. Especially for other developers who might need to work on or maintain the code. It obscures the logic and intent of the project.
Code bloat: Repeated code contributes to code bloat, making the project larger and slower. This can affect performance and efficiency.
Code reviews and collaboration: During code reviews, duplicated code can be flagged as an issue. This leads to discussions about code organization and design choices. It can also create conflicts in version control systems. Especially, when many developers are working on similar code.

Photo by Viktor Talashuk

The code example we refactored before has a huge problem and that's code repetition. It violates the DRY principle which says "don't repeat yourself".

Let's fix that:

const TRAINING_SCHEDULES = [
  {
    name: "Training 03 Schedule",
    milestone: "Milestone3Schedule",
    startDaysInterval: 10,
    endDaysInterval: 16
  },
  {
    name: "Training 04 Schedule",
    milestone: "Milestone4Schedule",
    startDaysInterval: 24,
    endDaysInterval: 30
  },
  {
    name: "Training 05 Schedule",
    milestone: "Milestone5Schedule",
    startDaysInterval: 52,
    endDaysInterval: 58
  },
  {
    name: "Training 06 Schedule",
    milestone: "Milestone6Schedule",
    startDaysInterval: 80,
    endDaysInterval: 86
  },
  {
    name: "Training 07 Schedule",
    milestone: "Milestone7Schedule",
    startDaysInterval: 108,
    endDaysInterval: 114
  },
  {
    name: "Training 08 Schedule",
    milestone: "Milestone8Schedule",
    startDaysInterval: 136,
    endDaysInterval: 142
  },
  {
    name: "Training 09 Schedule",
    milestone: "Milestone9Schedule",
    startDaysInterval: 164,
    endDaysInterval: 170
  },
  {
    name: "Training 10 Schedule",
    milestone: "Milestone10Schedule",
    startDaysInterval: 216,
    endDaysInterval: 230
  }
];

const targetedTrainingSchedule = TRAINING_SCHEDULES.find(
  (trainingSchedule) => trainingSchedule.name === fitnessTrainingSchedule.name
);

if (!targetedTrainingSchedule) {
  return;
}

checkWindowForTrainingSchedule(
  targetedTrainingSchedule.startDaysInterval,
  targetedTrainingSchedule.endDaysInterval,
  targetedTrainingSchedule.milestone,
  targetedTrainingSchedule.name
);

As you can see we moved all objects in an array. Then, instead of repeating if conditions for every possible fitness training schedule, we find the one we are looking for. Then we pass the params from the targeted training schedule into function.

This looks much nicer than before.

5) Function arguments mess

Function arguments, also known as parameters, are values that you provide to a function when you call it. These arguments provide the necessary data for the function to perform its task or calculations.

If you are not careful with function arguments, you can create a mess in the code. I once encountered a function that looked like this:

function createUser(
  username,
  email,
  password,
  firstName,
  lastName,
  birthdate,
  gender,
  phoneNumber,
  profilePicture,
  registerPurpose,
  isActive,
  isAdmin,
  isVerified,
  registrationDate,
  status,
  timezone,
  theme,
  accountType,
  subscriptionPlan,
  preferredLanguage,
  expiryDate,
  lastPasswordUpdate,
  lastLogin,
  notificationSettings,
  customFields
)

When a function has a large number of parameters, it becomes harder to understand, read, and maintain. It can be challenging to keep track of what each parameter does and how they interact with each other.

A function with many arguments can make the code harder to read and understand. Especially for developers who are new to the codebase.

Also, testing functions with many parameters becomes more complex. Each parameter can have different possible values and interactions. This increases the number of test cases required to cover the function's behavior. Additionally, debugging issues in functions with many parameters can be more challenging.

A function with many parameters might be tightly coupled to its callers. If one parameter changes, it might affect the function's behavior and need changes in many places.

So this case above was later just refactored to this:

function createUser(userData)

This is much better than before.

Also, in previous example, a function receives the data from one object. There is no need to pass them all one by one. You can pass the whole object:

// this is not OK
checkWindowForTrainingSchedule(
  targetedTrainingSchedule.startDaysInterval,
  targetedTrainingSchedule.endDaysInterval,
  targetedTrainingSchedule.milestone,
  targetedTrainingSchedule.name
);

// this is OK
checkWindowForTrainingSchedule(targetedTrainingSchedule);

In the end, it's a good practice to aim for functions with a reasonable number of parameters.

If you find that you need many parameters to achieve a certain functionality, consider using data structures like objects. Objects allow you to group related parameters together. You can also break down the function into smaller more focused functions. These functions can interact with each other to achieve the desired outcome.

This promotes cleaner, more maintainable, and more testable code.