DEV Community: Sathish Kumar N

Unveiling React Native 0.74: What's Inside the Latest Release?

Sathish Kumar N — Tue, 23 Apr 2024 07:26:23 +0000

🎉 Big News!

🚀 React Native 0.74 has Arrived with Major Updates!

Here's what's included:

Yoga 3.0 Integration:

Improved layout engine for more predictable styling.

Support for position: static
Support for align-content: space-evenly
Improvements to layout correctness
Yoga’s JavaScript bindings are now distributed as an ES Module
Fixes several crashes in Java bindings
Some existing Yoga APIs have been removed

Default Bridgeless New Architecture:
The app should run seamlessly in Bridgeless mode, provided that it was running with the old architecture before, ensuring a streamlined development experience.

Batched onLayout Updates:
Reduced re-renders for smoother performance.

Yarn 3 as Default Package Manager:
Enhanced project management capabilities.

Key Insights: What Developers Need to Know?

Introduction of Yoga 3.0 for improved layout rendering.
Default adoption of Bridgeless New Architecture for streamlined development.
Implementation of batched onLayout updates for smoother performance.
Yarn 3 as the default package manager for new projects, enhancing project management capabilities.
Minimum Android SDK requirement bumped to version 23 (Android 6.0) for improved compatibility and performance.
Removal of deprecated PropTypes, reducing app size and memory overhead.
API changes to PushNotificationIOS, preparing for its relocation to a community package.
Various other breaking changes and enhancements across platforms.

Key Benefits: What Users Can Expect?

Enhanced Performance and Stability: Expect smoother operations and improved reliability in your React Native projects.
Optimized App Size for Better User Experience: Users will enjoy faster downloads and more available storage space, resulting in enhanced overall satisfaction.

For detailed upgrade instructions and a full list of changes, refer to the official React Native documentation.

React Native 0.74 - Yoga 3.0, Bridgeless New Architecture, and more · React Native

Today we're releasing React Native 0.74! This release adds Yoga 3.0, Bridgeless by default under the New Architecture, batched onLayout updates (New Architecture), and Yarn 3 as the default package manager for new projects.

reactnative.dev

Happy coding!😊👩‍💻👨‍💻

Part 4: Writing Clean and Efficient React Code- Best Practices and Optimization Techniques

Sathish Kumar N — Sun, 18 Jun 2023 06:18:39 +0000

Welcome to Part 4 of our series on "React best practices in 2023"! In this part, we will explore various techniques and strategies to write clean and efficient code in your React applications. By following these best practices, you can improve the maintainability, performance, and readability of your codebase.

Let's dive in and learn how to write clean and efficient React code that not only works well but is also easier to understand, maintain, and scale.

1. Implement error boundaries to handle component errors gracefully

Wrap your components or specific sections of your application with error boundaries to catch and handle errors in a controlled manner.

This prevents the entire application from crashing and provides a fallback UI or error message, improving the user experience and making it easier to debug issues.

Higher-Order Component (HOC) - withErrorBoundary:



// HOC for error boundary
const withErrorBoundary = (WrappedComponent) => {
  return (props) => {
    const [hasError, setHasError] = useState(false);
    const [errorInfo, setErrorInfo] = useState(null);

    useEffect(() => {
      const handleComponentError = (error, errorInfo) => {
        setHasError(true);
        setErrorInfo(errorInfo);
        // You can also log the error to an error reporting service here
      };

      window.addEventListener('error', handleComponentError);

      return () => {
        window.removeEventListener('error', handleComponentError);
      };
    }, []);

    if (hasError) {
      // You can customize the fallback UI or error message here
      return <div>Something went wrong. Please try again later.</div>;
    }

    return <WrappedComponent {...props} />;
  };
};

Usage:



// HOC for error boundary
import withErrorBoundary from './withErrorBoundary';

const Todo = () => {
  // Component logic and rendering
}

const WrappedComponent = withErrorBoundary(Todo);

2. Use React.memo for functional components

React.memo is a higher-order component that memoizes the result of a functional component, preventing unnecessary re-renders.

By wrapping your functional components with React.memo, you can optimize performance by skipping re-renders when the component's props have not changed.

Here is an example,



// ❌ 
const TodoItem = ({text}) => {
  return <div> {text} </div>
} 

// Todo

const Todo = () => {
 //... Component logic

return <div>
 //.. Other elements
   <TodoItem //.. />
</div>
}

In this example, we have a functional component called TodoItem that receives a name prop and renders a todo text.

By default, the component will re-render whenever Todo parent component re-render.

To optimize performance, we can wrap TodoItem with React.memo, creating a memoized version of the component. This memoized component will only re-render if its props have changed.



// ✅ Memoized version of TodoItem using React.memo
const TodoItem = React.memo(({text}) => {
  return <div> {text} </div>
})

By using React.memo, we can prevent unnecessary re-renders and optimize the performance of functional components.

However, it's important to note that React.memo performs a shallow comparison of props. If your component receives complex data structures as props, ensure that you handle prop updates appropriately for accurate memoization.

3. Use Linting for Code Quality

Utilizing a linter tool, such as ESLint, can greatly improve code quality and consistency in your React projects.

By using a linter, you can:

Ensure consistent code style
Catch errors and problematic patterns
Improve code readability and maintainability
Enforce coding standards and conventions

4. Avoid default export

The problem with default exports is that it can make it harder to understand which components are being imported and used in other files. It also limits the flexibility of imports, as default exports can only have a single default export per file.



// ❌ Avoid default export
const Todo = () => {
  // component logic...
};

export default Todo;

Instead, it's recommended to use named exports in React:



// ✅ Use named export
const Todo = () => {

}

export { Todo };

Using named exports provides better clarity when importing components, making the codebase more organized and easier to navigate.

Named imports work well with tree shaking.

Tree shaking is a term commonly used within a JavaScript context to describe the removal of dead code. It relies on the import and export statements to detect if code modules are exported and imported for use between JavaScript files.

Refactoring becomes easier.
Easier to identify and understand the dependencies of a module.

5. Use object destructuring

When we use direct property access using dot notation for accessing individual properties of an object, will work fine for simple cases.



// ❌ Avoid direct property access using dot notation
const todo = {
   id: 1,
   name: "Morning Task",
   completed: false
}

const id = todo.id;
const name = todo.name;
const completed = todo.completed;

This approach can work fine for simple cases, but it can become difficult and repetitive when dealing with larger objects or when only a subset of properties is needed.

Object destructuring, on the other hand, provides a more concise and elegant way to extract object properties. It allows you to destructure an object in a single line of code and assign multiple properties to variables using a syntax similar to object literal notation.



// ✅ Use object destructuring
const { id, name = "Task", completed } = todo;

It reduces the need for repetitive object property access.
Supports the assignment of default values.
Allows variable renaming and aliasing.

6. Use fragments

Fragments allow for cleaner code by avoiding unnecessary wrapper divs when rendering multiple elements.



// ❌ Avoid unnecessary wrapper div
const Todo = () => (
  <div>
    <h1>Title</h1>
    <ul>
      // ...
    </ul>
  </div>
);

In the above code, Unnecessary wrapper div can add unnecessary complexity to the DOM structure, potentially impacting the accessibility of your web page.



// ✅ Use fragments
const Todo = () => (
  <>
    <h1>Title</h1>
    <ul>
      // ...
    </ul>
  </>
);

7. Prefer passing objects instead of multiple props

when we use multiple arguments or props are used to pass user-related information to component or function, it can be challenging to remember the order and purpose of each argument, especially when the number of arguments grows.



// ❌ Avoid passing multiple arguments
const updateTodo = (id, name, completed) => {
 //...
}

// ❌ Avoid passing multiple props
const TodoItem = (id, name, completed) => {
  return(
    //...
  )
}

When the number of arguments increases, it becomes more challenging to maintain and refactor the code. There is an increased chance of making mistakes, such as omitting an argument or providing incorrect values.



// ✅ Use object arguments
const updateTodo = (todo) => {
 //...
}

const todo = {
   id: 1,
   name: "Morning Task",
   completed: false
}

updateTodo(todo);

Function becomes more self-descriptive and easier to understand.
Reducing the chances of errors caused by incorrect argument order.
Easy to add or modify properties without changing the function signature.
Simplify the process of debugging or testing functions to passing an object as an argument.

8. Use arrow functions

Arrow functions provide a more concise syntax and lexical scoping, eliminating the need for explicit this binding and improving code readability.



// ❌
function sum(a, b) {
  return a + b;
}

Above code can result in verbose code and potentially lead to misunderstandings regarding the context and binding of this.



// ✅ Use arrow function
const sum = (a, b) => a + b;

Arrow functions make the code more compact and expressive.
It automatically bind the context, reducing the chances of this related bugs.
It improves code maintainability.

9. Use enums instead of numbers or strings



// ❌ Avoid Using numbers or strings
switch(status) {
  case 1:
    return //...
  case 2:
    return //...
  case 3:
    return //...
}

Above code that is harder to understand and maintain, as the meaning of numbers may not be immediately clear.



// ✅ Use Enums
const Status = {
  NOT_STARTED: 1,
  IN_PROGRESS: 2,
  COMPLETED: 3
}

const { NOT_STARTED, IN_PROGRESS COMPLETED } = Status;

switch(status) {
  case NOT_STARTED:
    return //...
  case IN_PROGRESS:
    return //...
  case COMPLETED:
    return //...
}

Enums have meaningful and self-descriptive values.
Improve code readability.
Reducing the chances of typos or incorrect values.
Better type checking, editor autocompletion, and documentation.

10. Use shorthand for boolean props



// ❌
<Dropdown multiSelect={true} />



// ✅ Use shorthand
<Dropdown multiSelect />

Shorthand syntax for boolean props improves code readability by reducing unnecessary verbosity and making the intention clear.

11. Avoid using indexes as key props



// ❌ Avoid index as key
const renderItem = (todo, index) => {
  const {name} = todo;
  return <li key={index}> {name} </>
}

Using indexes as key props can lead to *incorrect rendering * especially when adding, removing, or reordering list items.

It can result in poor performance and incorrect component updates.



// ✅ Using unique and stable identifiers
const renderItem = (todo, index) => {
  const {id, name} = todo;
  return <li key={id}> {name} </>
}

Efficiently update and reorder components in lists.
Reducing potential rendering issues.
Avoids in-correct component update.

12. Use implicit return in small functions



// ❌ Avoid using explicit returns 
const square = value => {
  return value * value;
}

When we use explicit return can make small function definitions unnecessarily longer and harder to read.

It may result in more cluttered code due to additional curly braces and explicit return statements.



// ✅ Use implicit return
const square = value => value * value;

Implicit return reduces code verbosity.
Improves code readability.
It can enhance code maintainability by focusing on the main logic rather than return statements.

13. Use PropTypes for type checking



// ❌ Bad Code
const Button = ({ text, enabled }) => 
      <button enabled>{text}</button>;

Above code can lead to passing incorrect prop types, which may result in runtime errors or unexpected behavior.



// ✅ Use PropTypes
import PropTypes from 'prop-types';

const Button = ({ enabled, text }) => 
      <button enabled> {text} </button>;

Button.propTypes = {
  enabled: PropTypes.bool
  text: PropTypes.string.isRequired,
};

It helps catch error on compile time.
It provides better understanding and expected type of the component.
PropTypes act as a documentation for other developers working with the component.

14. Prefer using template literals



// ❌ Bad Code
const title = (seriesName) => 
      "Welcome to " + seriesName + "!";

Above code can result in verbose code and make string interpolation or concatenation more difficult.



// ✅ Use template literals
const title = (seriesName) => 
      `Welcome to ${seriesName}!`;

It simplify string manipulation by allowing variable interpolation within the string.
It makes code more expressive and easier to read.
It support multi-line strings without additional workarounds.
Improving code formatting.

15. Avoid huge component

Avoiding huge components in React is crucial for maintaining clean, modular, and maintainable code.

Large components tend to be more complex, harder to understand, and prone to issues. Let's explore an example to illustrate this concept:



// ❌ Avoid huge component
const Todo = () => {
  // State Management
  const [text, setText] = useState("");
  const [todos, setTodos] = useState([])
  //... More states

  // Event Handlers
  const onChangeInput = () => //...
  // Other event handlers

  return (
   <div>
      <input //.. />
      <input //.. />   
      <button //.. />
      <list //... >
        <list-item //..>
      </list/>
   </div>
  )
};

export default Todo;

In the above example, we have a component called Todo, which contains multiple state variables and event handlers and elements.

As the component grows, it becomes harder to manage, debug and understand.

You can check below blog for to address this, it's recommended to break down such huge components into smaller, reusable, and focused components.

Part 3: Component Structure - Building Reusable and Maintainable Components in React!

Sathish Kumar N ・ May 22 '23

#react #bestpractice #javascript #componentstructure

Stay tuned for an upcoming blog dedicated to optimization techniques in React. We'll explore additional strategies to enhance performance and efficiency in your components. Don't miss out on these valuable insights!

Happy coding!😊👩‍💻👨‍💻

Part 3: Component Structure - Building Reusable and Maintainable Components in React!

Sathish Kumar N — Mon, 22 May 2023 03:30:00 +0000

Welcome to Part 3 of our "React Best Practices in 2023" series! In this part, we will explore the importance of component structure and how it contributes to creating components that are highly reusable, modular, and easy to maintain.

Building reusable and maintainable components in React is not just about writing code; it's about adopting best practices and following sound architectural principles.

By carefully structuring our components, adhering to the Single Responsibility Principle, and embracing concepts like Atomic Design and Component Composition, we can create code that is more modular, easier to test, and simpler to maintain.

This approach leads to a more efficient development process and ultimately results in high-quality, scalable React applications.

Let's consider an example where we have a Todo application implemented in React.

// ❌ Bad code with multiple responsibilities
import React, { useState } from 'react';

const TodoApp = () => {

  // Handling state ❌ 
  const [todos, setTodos] = useState([]);
  const [newTodo, setNewTodo] = useState('');

  // Handle input change ❌ 
  const handleInputChange = (e) => {
    setNewTodo(e.target.value);
  };

 // Handle todo logic ❌ 
  const handleAddTodo = () => {
    if (newTodo.trim() !== '') {
      const updatedTodos = [...todos, newTodo];
      setTodos(updatedTodos);
      setNewTodo('');
    }
  };

  const handleDeleteTodo = (index) => {
    const updatedTodos = todos.filter((_, i) => i !== index);
    setTodos(updatedTodos);
  };

  const handleCompleteTodo = (index) => {
    const updatedTodos = todos.map((todo, i) => {
      if (i === index) {
        return { ...todo, completed: !todo.completed };
      }
      return todo;
    });
    setTodos(updatedTodos);
  };

  // ❌  It doesn't provide a clear separation of smaller reusable components. 
  return (
    <div>
      <h1>Todo App</h1>
      <input type="text" 
value={newTodo} onChange={handleInputChange} />
      <button onClick={handleAddTodo}>Add Todo</button>
      <ul>
        {todos.map((todo, index) => (
          <li key={index}>
            <span style={{ textDecoration: todo.completed ? 'line-through' : 'none' }}>{todo.text}</span>
            <button onClick={() => handleDeleteTodo(index)}>Delete</button>
            <button onClick={() => handleCompleteTodo(index)}>
              {todo.completed ? 'Mark Incomplete' : 'Mark Complete'}
            </button>
          </li>
        ))}
      </ul>
    </div>
  );
};

Above codebase contains a single component that handles everything from rendering the UI to handling data and state management. This monolithic approach leads to a lack of separation of concerns and violates the SRP and Atomic Design principles.

To improve the code, we can follow the SRP and Atomic Design principles:

Single Responsibility Principle (SRP)

This principle states that a class or component should have a single responsibility or single reason to change. By keeping components focused on a specific task, you improve code readability, maintainability, and reusability.

It promotes breaking down complex functionality into smaller, focused parts that are easier to understand, test, and maintain.

It encourages components to have clear and specific responsibilities, enhancing their reusability and maintainability.

It helps in avoiding tightly coupled components by keeping them focused on specific tasks.

Let's breakdown the monolith,

TodoInput: Extract the input handling logic into a separate useTodoInput custom hook and component TodoInput.

Responsible for handling user input and adding new todos.

TodoList: Extract the todo list handling logic into a separate useTodoList custom hook and component TodoList.

Responsible for rendering the list of todos.

TodoItem: Move the rendering logic for individual todos into a separate TodoItem component.

Responsible for rendering an individual todo item.

By separating the state and event handling logic into custom hooks or components, we ensure that each component has a following single responsibility.

Todo Input

The useTodoInput custom hook can manage the input state using the useState hook and handle the input change event

useTodoInput.js

// ✅ Responsible for manage state and UI events

import { useState } from "react";

const useTodoInput = (onAddTodo) => {
  const [inputValue, setInputValue] = useState("");
  const [disabled, setDisabled] = useState(true);

  const handleSubmit = (e) => {
    e.preventDefault();
    onAddTodo(inputValue);
    clearInput();
  };

  const handleInputChange = (e) => {
    const value = e.target.value;
    setInputValue(value);
    setDisabled(value.trim() === "");
  };

  const clearInput = () => {
    setInputValue("");
    setDisabled(true);
  };

  return {
    disabled,
    inputValue,
    handleInputChange,
    handleSubmit
  };
};

export { useTodoInput };

By utilizing custom hooks, we can encapsulate the state and event handling logic in a reusable and modular way, promoting code reusability and maintainability.

TodoInput.jsx

Move the JSX code related to the input field, "Add Todo" button, and todo list into separate JSX file.

// TodoInput.jsx

// ✅ Responsible for rendering TodoInput UI

const TodoInput = ({ onAddTodo }) => {
  const {
    disabled,
    inputValue,
    handleInputChange,
    handleSubmit
  } = useTodoInput(onAddTodo);

  return (
    <form className="todo-input" onSubmit={handleSubmit}>
      <input
        type="text"
        value={inputValue}
        onChange={handleInputChange}
        placeholder="Add a todo"
      />
      <button
        className={`add-button ${disabled ? "disabled" : ""}`}
        disabled={disabled}
        type="submit"
      >
        Add
      </button>
    </form>
  );
};

By separating the JSX code into individual files, we can improve code organization and readability, making it easier to maintain and understand the component structure.

Like this we need to split our TodoItem and TodoList.

This refactoring approach adheres to the SRP by assigning single responsibilities to each component, utilizes custom hooks for state and event handling, and separates the JSX code into reusable components, promoting modularity and maintainability in the React application.

Finally, the component structure will look like below,

// ✅ Component Stucture

components/
├── todo-input/
│   ├── TodoInput.jsx
│   ├── useTodoInput.js
│   └── TodoInput.css
├── todo-item/
│   ├── TodoItem.jsx
│   └── TodoItem.css
├── todo-list/
│   ├── TodoList.jsx
│   ├── useTodoList.js
│   └── TodoList.css
└── ...

You can check it out the whole codebase in codesandbox.

We can further refactor this codebase using Atomic Design principles.

Atomic Design Principles

Atomic Design is a methodology for designing and organizing components in a hierarchical manner based on their level of abstraction and complexity.

It classifies components into five levels: Atoms, Molecules, Organisms, Templates, and Pages, with each level having a specific responsibility.

Atoms: At the lowest level, atoms represent the smallest and most basic UI elements, such as buttons, inputs, or icons.

They have a single responsibility, focusing on their visual appearance and basic functionality.

Molecules: Molecules are combinations of atoms that work together to create more complex UI elements.

They have a slightly higher level of responsibility, representing a group of related atoms.

Organisms: Organisms are composed of molecules and atoms, representing larger and more self-contained sections of a user interface.

They have more complex behavior and may include state management and interaction logic.

Templates: Templates are specific arrangements of organisms that provide a basic structure for a page or section.

They define the overall layout and composition of the UI.

Pages: Pages are instances where templates are populated with real data, creating actual content for the user to interact with.

Let's take an example of same todo app. I will give an high level code design using the Atomic Design Pattern:

Atoms

Atoms contains small, reusable UI components like Button and Input.

// ✅ Atoms

// Button.jsx
const Button = ({ onClick, children }) => {
  return (
    <button className="button" onClick={onClick}>
      {children}
    </button>
  );
};

//Input.jsx
const Input = ({ value, onChange }) => {
  return (
    <input className="input" type="text" value={value} onChange={onChange} />
  );
};

Each atom has its own JavaScript file (Button.jsx, Input.jsx) and CSS file (Button.css, Input.css).

Molecules

The molecules directory contains combinations of atoms (Button.jsx) that form more complex components, such as the the TodoItem component.

// ✅ Molecules

// TodoItem.jsx
const TodoItem = ({ todo, onDelete, onComplete }) => {
  return (
    <li className="todo-item">
      <span className={todo.completed ? 'completed' : ''}>{todo.text}</span>
      <Button onClick={onDelete}>Delete</button>
      <Button onClick={onComplete}>
        {todo.completed ? 'Mark Incomplete' : 'Mark Complete'}
      </Button>
    </li>
  );
};

It has its own JavaScript file (TodoItem.js) and CSS file (TodoItem.css).

Organisms

The organisms directory contains larger, more feature-rich components, such as the TodoForm and TodoList components.

// ✅ Organisms

// TodoForm.jsx
const TodoForm = ({ onAddTodo }) => {
  const {inputChange, addTodo} = useTodoForm();

  return (
    <div className="todo-form">
      <Input value={newTodo} onChange={inputChange} />
      <Button onClick={addTodo}>Add Todo</Button>
    </div>
  );
};

// TodoList.jsx
const TodoList = ({ todos, onDeleteTodo, onCompleteTodo }) => {
  return (
    <ul className="todo-list">
      {todos.map((todo, index) => (
        <TodoItem
          key={index}
          todo={todo}
          onDelete={() => onDeleteTodo(index)}
          onComplete={() => onCompleteTodo(index)}
        />
      ))}
    </ul>
  );
};

They are composed of molecules and/or atoms and have their own JSX(TodoForm.jsx, TodoList.jsx), Custom Hooks(useTodoForm.js) and CSS files.

Templates

The templates contains components that provide the overall structure of a page or layout. In this case, the Todo template is responsible for rendering the TodoForm and TodoList components.

// ✅ Templates

// Todo.jsx
const Todo = () => {
  const { 
    todos, 
    addTodo, 
    deleteTodo, 
    completeTodo 
  } = useTodo();

  return (
    <div className="todo-app">
      <h1>Todo App</h1>
      <TodoForm onAddTodo={addTodo} />
      <TodoList
        todos={todos}
        onDeleteTodo={deleteTodo}
        onCompleteTodo={completeTodo}
      />
    </div>
  );
};

It has its own JSX file (Todo.jsx) and Custom Hook (useTodo.js) and CSS file (Todo.css).

Pages

The pages directory components that represent a specific page in the application. In this example, there is a HomePage component that serves as the main entry point of the Todo app.

// ✅ Pages

// HomePage.js
const HomePage = () => {
  return (
    <div className="home-page">
      <TodoApp />
    </div>
  );
};

This example demonstrates how the Todo app codebase can be structured using the Atomic Design pattern. Each component is responsible for a single concern, and they can be easily reused and composed to build the complete Todo app.

Final Thoughts

When designing your React app, it's essential to avoid assigning multiple responsibilities to a single component. Here are some practical strategies to help you achieve a cleaner and more maintainable codebase:

1. Identify clear responsibilities: Clearly define the purpose of each component. Break down complex functionalities into smaller, focused components with well-defined responsibilities.

2. Separation of concerns: Separate concerns by dividing your app into distinct components based on their functionality. Each component should have a specific role and handle a single responsibility.

3. Component composition: Instead of building large components that handle multiple tasks, compose your UI by combining smaller, reusable components. This promotes reusability and modularity.

4. Single-task functions: Extract complex logic from components into separate functions or utility modules. By encapsulating specific functionalities in separate functions, you keep your components focused on rendering and UI-related tasks.

5. Follow the SOLID principles: Adhere to SOLID principles, such as the Single Responsibility Principle (SRP), which states that a component should have only one reason to change. This principle helps you design components that are focused, maintainable, and easier to test.

6. Use custom hooks: Extract common logic into custom hooks that can be shared across components. This allows you to reuse logic without introducing unnecessary complexity to individual components.

7. Modular architecture: Organize your codebase using a modular architecture, such as the feature-based folder structure. This approach promotes separation of concerns and helps in keeping components focused on their specific responsibilities.

By consciously designing your React app with these practices in mind, you can avoid assigning multiple responsibilities to components. This leads to cleaner, more maintainable code that is easier to understand, test, and extend.

Bonus - Component Hierarchy

It is generally recommended to follow a specific component hierarchy to maintain consistency and readability in your codebase.

// ✅ Component Hierarchy

// External dependencies
import React, { useState, useRef, useEffect } from 'react';
import PropTypes from 'prop-types';
import _ from 'lodash';

// Internal dependencies
import { TodoItem } from './TodoItem';
import { TodoUtils } from '../utils';
import { useTodo } from '../hooks';
import { withTimer } from '../hoc';
import { TodoType } from '../enums';

// Stylesheets
import './Component.css';
import '../styles/common.css';

// Assets
import todoImage from '../assets/todoImage.png';

const Todo = () => {
  // State logic
  const [todos, setTodos] = useState([]);

  // Ref
  const inputRef = useRef(null);

  // Variable
  const title = 'Todo List';

  // Custom hook
  const {addTodo} = useTodo();

  // Higher-order component
  const timer = 
withTimer(TodoItem);

  // Component lifecycle methods (useEffect)
  useEffect(() => {
   //...
  }, []);

  // Component render
  return (
    <div>
      {/* Component JSX */}
    </div>
  );
}

Todo.propTypes = {
  // Prop types declaration
};

export { Todo };

By structuring your component hierarchy in a consistent and organized manner, you can improve the readability, maintainability, and scalability of your React app.

A well-defined hierarchy helps developers navigate the codebase, understand component relationships, and make modifications efficiently.

Stay tuned for more tips and tricks on building high-quality React applications in my future blog posts!

Happy coding!😊👩‍💻👨‍💻

Part 2: Folder Structure - Building a Solid Foundation

Sathish Kumar N — Mon, 15 May 2023 20:02:56 +0000

Welcome to Part 2 of our "React Best Practices in 2023" series! In this blog, we'll dive into the crucial aspect of organizing your project's folder structure.

The key is to maintain a clear and organised structure that makes it easy to locate and manage your files.

A well-designed folder structure is essential for maintaining a clean and scalable codebase, improving collaboration among team members, and enhancing overall development efficiency.

There are different types of folder structures commonly used in React projects, including the Component-Based structure, Feature-Based structure and Domain-Based Structure.

While there are various folder structure options available, The "Feature-Based structure" is considered one of the best approaches for organizing your codebase in React projects.

It promotes modularity, scalability, and maintainability by grouping related files and components based on features or functionalities rather than technical layers.

Here are some reasons why the Feature-Based structure is often preferred:

1. Modularity and Separation of Concerns
2. Code Reusability
3. Scalability and Team Collaboration
4. Easier Navigation and Understanding
5. Maintenance and Refactoring

Let's consider an example of a social media application like Facebook app to better understand how the feature-based structure works in practice.

We need to create base folders that form the foundation of our feature-based structure. These base folders serve as the starting point for organizing our code and provide a clear structure for the entire project.



src/
├── features/       // Grouping features of the application
│   └── ...         // Other feature folders
├── shared/         // Shared elements used across multiple features
│   ├── components/ // Reusable components
│   ├── services/   // Shared services or API calls
│   ├── hooks/      // Custom hooks
│   ├── hoc/        // Higher-order components
│   ├── slices/     // Redux slices for state management
│   └── utils/      // Utility functions
├── assets/         // Storing static assets
│   ├── images/     // Storing image files
│   ├── fonts/      // Storing font files
│   └── ...
├── styles/         // Global styles
│   └── ...
├── App.jsx         // Entry point of the application
└── ...             // Other necessary files and folders

In this structure,

The features folder is where you group your code based on different features or functionalities of the application. Each feature has its own subfolder.
The shared folder contains various subfolders like components, services, hooks, hoc, slices, and utils to store shared elements used across multiple features.

Using useReducer and Redux Toolkit Together: A Powerful Combination for State Management

Sathish Kumar N ・ May 12 '23

#react #reducer #redux #bestpractice
The assets folder is for storing static assets such as images, fonts, or other media files.
The styles folder is where you can put global styles or style-related files.
App.jsx represents the main component or entry point of your application.

In Facebook, we might have features such as "News Feed," "Profile," and "Chat." We would create separate subfolders for each of these features inside the features directory.

Let's add sub-folder's under "News Feed".



src/
├── features/
│   ├── news-feed/        // Folder for the News Feed feature
│   │   ├── components/   // Components related to the News Feed
│   │   ├── containers/   // Containers or pages related to the News Feed
│   │   ├── services/     // Services or API calls specific to the News Feed
│   │   ├── utils/        // Utility functions specific to the News Feed
│   │   ├── slices/       // Redux Slices to manage states specific to the News Feed
│   │   └── ...
│   └── ...               // Additional feature folders
├── ...  
├── App.jsx              
└── ...

In this structure,

The components folder contains React components that are specific to the News Feed feature. These Components are responsible for the presentation and rendering of the user interface. They focus on the visual aspects of the application and handle the display of data. Components receive data through props and render JSX to define the structure and appearance of the UI.

The containers folder contains container components also known as smart or connected components, are responsible for connecting the application's data and logic with the presentation components. They handle data fetching, state management, and provide data and functionality to the presentation components.

Let's dive in to the containers folder.



news-feed/
├── components/                      // Folder for presentation components
│   └── ...                          // Additional components related to the News Feed feature
├── containers/                      // Folder for container components
│   ├── news-feed-page/                // Folder for the News Feed page container
│   │   ├── NewsFeedPage.jsx         // Container component for the News Feed page
│   │   ├── NewsFeedPageStyles.css   // Styles specific to the News Feed page
│   │   ├── NewsFeedPageUtils.js     // Utility functions specific to the News Feed page
│   │   ├── useNewsFeedPage.js       // Custom hook for managing News Feed data, events and callbacks
│   │   └── ...                      // Additional files related to the News Feed page
│   └── ...  
└── ...

Please check the "Separation of concerns in React" for above file separation under "container" folder.

Separation of concerns in React and React Native.

Sathish Kumar N ・ May 9 '23

#react #bestpractice #designpatterns #modularity

The final structure of our app's folder will look like this, providing a well-organized and modular approach to organizing our codebase:



src/
├── features/
│   ├── news-feed/
│   │   ├── components/
│   │   │   ├── PostItem.jsx
│   │   │   ├── CommentItem.jsx
│   │   │   ├── LikeButton.jsx
│   │   │   └── ...
│   │   ├── containers/
│   │   │   ├── news-feed-page/
│   │   │   │   ├── NewsFeedPage.jsx
│   │   │   │   ├── NewsFeedPageStyles.css
│   │   │   │   ├── NewsFeedPageUtils.js
│   │   │   │   ├── useNewsFeedPage.js
│   │   │   │   └── ...
│   │   │   ├── PostDetailsPage.jsx
/* No need to create separate folder if
 container have less functionality and logic */
│   │   │   └── ...
│   │   ├── services/
│   │   │   ├── newsFeedService.js
│   │   │   └── ...
│   │   ├── utils/
│   │   │   ├── dateUtils.js
│   │   │   └── ...
│   │   ├── slices/
│   │   │   ├── newsFeedSlice.js
│   │   │   └── ...
│   │   └── ...
│   ├── profile/
│   │   ├── components/
│   │   │   ├── ProfileInfo.jsx
│   │   │   ├── Avatar.jsx
│   │   │   ├── ProfileSettings.jsx
│   │   │   └── ...
│   │   ├── containers/
│   │   │   ├── ProfilePage.jsx
│   │   │   └── ...
│   │   ├── services/
│   │   │   ├── profileService.js
│   │   │   └── ...
│   │   ├── utils/
│   │   │   ├── validationUtils.js
│   │   │   └── ...
│   │   ├── slices/
│   │   │   ├── profileSlice.js
│   │   │   └── ...
│   │   └── ...
│   └── ...
├── shared/
│   ├── components/
│   ├── services/
│   ├── hooks/
│   ├── hoc/
│   ├── slices/
│   ├── utils/
│   ├── assets/
│   └── styles/
│   └── ...
├── App.jsx
└── ...

Organizing components within their respective feature folders helps maintain a clear separation of concerns and makes it easier to locate and work with specific components. It also promotes code reusability and modularity within the application.

Note: The provided folder structure is just an example and may vary depending on your project's requirements and preferences.

Stay tuned for Part 3: Component Structure - Building Reusable and Maintainable Components in React!

Happy coding!😊👩‍💻👨‍💻

Part 1: Naming Conventions - The Foundation of Clean Code

Sathish Kumar N — Mon, 15 May 2023 04:58:09 +0000

Welcome to the first part of my blog series, "React Best Practices in 2023." In this blog, we will delve into the crucial topic of naming conventions and how they serve as the foundation of clean and maintainable code in React.

Naming conventions play a vital role in improving code readability, maintainability, organization, and communication. They help create a cohesive and structured codebase that is easier to work with, reduces errors, and promotes collaboration among developers.

In this part, we will focus specifically on naming conventions in React. We will explore the recommended approaches for naming components, variables, functions, and other identifiers within your React projects. You'll gain insights into the popular conventions such as PascalCase, camelCase, kebab-case and SCREAMING_SNAKE_CASE, and understand when and where to apply them.

We will also discuss the benefits of meaningful and descriptive names that accurately reflect the purpose and functionality of the elements in your code.

Pascal Case

Pascal Case typically refers to the convention of writing compound words in which the first letter of each word is capitalized and there are no spaces or punctuation marks between the words.

In React, we can use pascal case for below elements:

1. React Component

// React Component
const Todo = () => {
   //...
}

2. CSS Class Names

// CSS Class Names
Todo.css
Todo.scss
Todo.module.scss

3. Enumerations

// Enums
const RequestType = {
   //...
}

Camel Case

Camel case refers to the convention of writing compound words or phrases where each word begins with a capital letter except the first word, which starts with a lowercase letter.

In React, we can use camel case for below elements:

1. Variable Names

// Variable Name
const userName = "sathishskdev";

2. Function Names

// Function Name
const getFullName = (firstName, lastName) => {
    return `${firstName} ${lastName}`;
}

3. Object Properties

// Object Properties
const user = {
  userName: "sathishskdev",
  firstName: "Sathish",
  lastName: "Kumar"
}

4. CSS Module Class Names

// CSS Module Class Names
.headerContainer {
    display: "flex";
}

5. Custom Hooks

const useTodo = () => {
  //...
}

6. Higher Order Component

const withTimer = () => {
  //...
}

Kebab Case

Kebab case refers to the convention of writing compound words in lowercase letters and separating them with hyphens("-").

In React, we can use kebab case for below elements:

1. CSS Class Names

// CSS Class Names
header-container {
    display: "flex";
}

<div className="header-container">
  //...
</div>

2. Folder Names

// Folder Names
  src
     todo-list // Folder name
         TodoList.jsx
         TodoList.module.scss
     todo-item // Folder name
         TodoItem.jsx

SCREAMING_SNAKE_CASE

SCREAMING_SNAKE_CASE refers to the convention of writing compound words or phrases in uppercase letters, with words separated by underscores ("_").

1. Constants

// Constants
const BASE_PATH = "https://domain.services/api";

2. Enumeration Properties

// Enumeration Properties
const RequestType = { // Name in Pascal Case
  // Properties in Screaming Snake Case
  GET: 'GET',
  POST: 'POST',
  PUT: 'PUT',
  DELETE: 'DELETE',
};

3. Global Variables

// Global Variables
const ENVIRONMENT = 'PRODUCTION';
const PI = 3.14159;

Higher-Order Component Naming Convention

Here are best practices for naming Higher-Order Component:

1. Use "with" as Prefix

Common convention is to use the prefix "with" followed by the functionality or purpose of the HOC.

2. Use "Original Component" as Suffix

Include the original component name in the HOC's name to indicate the component it is enhancing or wrapping

// HOC: name have "with" as Prefix
// "Filter" is add as Suffix which is original component
const withFilter = () => {
 //...
}

// Usage of the HOC
const Filter = withFilter(/*Component Name*/);

Custom Hooks Naming Convention

Here are best practices for naming custom hooks:

1. Use "use" as Prefix

Common convention is to use the prefix "use" followed by the functionality or purpose of the Custom Hooks.

2. Use "Behaviour of hook" as Suffix

Name the custom hooks that accurately describes the purpose or behaviour of the custom hook.

// Custom Hook: useTimer
// name have "use" as Prefix
// "Timer" is add as Suffix which is behaviour of hook
const useTimer = (initialTime) => {
  // ... hook implementation
};

// Usage of the custom hook
  const { time, start, stop, reset } = useTimer(60);

Use more descriptive and specific names

It's important to avoid using generic or unclear names for your components, variables, or functions.

Let's take an example to illustrate this:

// ❌ Pitfalls to Avoid

const MyComponent = () => { 
// What kind of component is this?

const data = getData() 
// What kind of data is this?

const onClick = () => {
  // What does it do?
}
//...
}

In the above example, The component name, variable name "data" and the function name "onClick" are generic and don't convey their specific purpose or context.

To improve clarity and maintainability, it's recommended to use more descriptive and specific names.

Here's an best practice:

// ✅ Best Practice

const ProductDetails = () => {

const productInfo = fetchProductInfo();
// Fetches detailed product information

const addProductToCart = () => {
  // Add the product to the shopping cart
};
//...
}

In the improved example, the component is renamed to "ProductDetails", which clearly indicates its purpose. The variable name "productInfo" conveys that it holds detailed information about a product. The function name "addProductToCart" describes its action of adding the product to the shopping cart.

By using descriptive and meaningful names, it becomes easier for other developers (including yourself) to understand and maintain the code in the long run.

Choosing Singular or Plural Naming

The decision to use singular or plural names for various elements, such as components, variable and functions, can significantly impact code clarity.

Let's take an example:

// ✅ Best Practice

const fetchConversation = () => {
  // Fetch single conversation.
}

const fetchConversations = () => {
  // Fetch multiple conversations.
}

// Use singular name for a single conversation
const conversation = { /*Conversation Details*/ }

// Use plural name for multiple conversation
const conversations = [
  { /*Conversation Details*/ }, 
  { /*Conversation Details*/ }
]

By aligning the singular or plural form of component, function and variable names with their intended purpose, we improve code readability and facilitate better understanding for other developers working on the codebase.

Avoid Excessive Abbreviations

Here's an example that demonstrates the importance of avoiding excessive abbreviations in code:

// ❌ Bad example

// Excessive abbreviation
const selUsr = {
  usrId: '1',
  usrNm: 'Sathish Kumar',
  usrEmail: 'sathish@domain.com',
};

// Usage
selUsr.usrId

In the above example, the object selUsr contains selected user information with abbreviated property names like usrId, usrNm, and usrEmail. While this code may be functional, it lacks clarity and can cause confusion for other developers who need to work with this object and property.

Here's an best practice:

// ✅ Best Practice

// Descriptive object and property names
const selectedUser = {
  userId: 1,
  userName: 'Sathish Kumar',
  userEmail: 'sathish@domain.com',
}

// Usage
selectedUser.userId

In this example, the property names userId, userName, and userEmail are more descriptive, providing a clearer understanding of the data being used. This makes the code easier to read, maintain, and collaborate on, contributing to better overall code quality.

That concludes our exploration of naming conventions in React.js. By following these best practices, you are well-equipped to create clean, readable, and maintainable code in your React projects.

Remember, choosing meaningful and descriptive names for your variables, functions, components, and other elements is essential for enhancing code clarity and improving collaboration among developers. Consistency in naming conventions throughout your project will make your codebase more organized and easier to understand.

In the next part of our series, we will delve into the critical topic of folder structure in React. We'll discuss how to organize your project's files and directories effectively, and how to implement a modular approach that promotes code reusability and maintainability.

Stay tuned for next post!

Happy coding!😊👩‍💻👨‍💻

Using useReducer and Redux Toolkit Together: A Powerful Combination for State Management

Sathish Kumar N — Fri, 12 May 2023 04:06:44 +0000

Developers may hesitate to use useReducer in React because it requires a different approach to managing state than the more familiar useState hook.

While useState provides a simple way to manage state within a component, it can become unwieldy for more complex state management needs.

While useReducer can be more efficient than useState, it requires additional boilerplate code to set up the reducer function and manage state updates.

Redux Toolkit provides a more modern and user-friendly approach to managing state in your React application, with a simpler API, better performance, and fewer bugs. It is a great option for developers who want to take advantage of the benefits of Redux, while minimising the complexity and boilerplate code that comes with traditional Redux.

If you're using useReducer in your React application, you may be missing out on the full potential of Redux Toolkit's powerful API.

With features createSlice(Manage creating reducer, creating action and state), Redux Toolkit streamlines the process of managing state in your app, reducing the need for writing custom reducers and actions by hand.

A Practical Example with useReducer

Let's take an example of good old-fashioned Todo app.

In this example, We need below boiler plates for managing tasks.

Action Types

Actions

Reducer

We no longer need this boilerplate code in useReducer

We will add redux-toolkit in this app.

It provides a createSlice function that generates useReducers reducers, action creators, and action types in a concise manner. This simplifies the process of defining and managing state in useReducer.

Creating reducers

By defining the initialState within the slice file useToolKitReducer.js, We centralize the initial state configuration alongside the corresponding reducer logic.

Adding reducer to the component

We can get initial state, reducer and actions from this useToolKitReducer slice.

Redux Toolkit utilizes the immer library internally, enabling you to write code that appears to mutate state directly within the reducers.

Under the hood, immer ensures immutability by producing new immutable states. This simplifies the process of updating state and avoids common pitfalls associated with manual immutability handling.

Avoiding manual dispatch actions and binding

We can use "bindActionCreators" to avoid manually dispatching actions and binding them to the dispatch function in your components.

It simplifies the process and provides a convenient way to use action creators directly as functions, abstracting away the details of dispatching actions in our component code.

Using Action Creator as functions

Now, we can use these action creators as functions in our component.

No need to manually wrap dispatch in action creators.

The Benefits of combining useReducer and Redux Toolkit

1. Minimize Configuration Overhead and Save Time.

2. Streamlined state management.

3. Built-in immutability(immer) and ease of updates.

4. Improve maintainability of our codebase.

For improve maintainability further, you can check our blog

Separation of concerns in React and React Native.

Sathish Kumar N ・ May 9 '23

#react #bestpractice #designpatterns #modularity

Please give your feedback and questions on comments section.

Happy Coding!!

Separation of concerns in React and React Native.

Sathish Kumar N — Tue, 09 May 2023 15:39:15 +0000

As developers, we all know the feeling of adding new feature with screen full of codes which seems to go on forever. Whether you're a seasoned developer or just getting started, this post will give you a deeper understanding of the power of separation of concerns and how you can apply it to your own web and mobile development work.

Separation of concerns is a practice of divide our code into more maintainable, reusable and testable separate sections or modules which is responsible for one single purpose, specific task.

The Power of Separation of Concerns

Increase Cohesion
Reduce Coupling
Clean and Maintainable.
Reusable across different parts of the application.
Easy to test.
Better code quality at all levels.

Overall, by using the separation of concerns in React, we can increase cohesion and reduce coupling, leading to a more maintainable and scalable codebase.

Separation of Concerns in Action: Real-World Examples from Web Development

Let's take an example of good old-fashioned Todo app.

While this simple Todo app may be easy to maintain in its current state, more complex logic and additional requirements could quickly make the codebase difficult to manage.

In such cases, even the most seasoned developers might hesitate to make changes, fearing that they'll break something or unknowingly introduce bugs.

Solution

As our render function grows in size and complexity, it can become difficult to read and maintain. In order to improve code clarity and separation of concerns, it's a good idea to split the render function into separate UI elements.

By doing so, we can compartmentalise different aspects of the UI and more easily make changes or updates. Additionally, this can lead to better code reusability and testability, as each UI element can be individually tested and reused in other components as needed.

We will explore some strategies and best practices for managing a complex app and keeping your codebase clean, maintainable, and bug-free.

1. Separate JSX File.

Responsible for for displaying UI elements only.

We will create a Todo.jsx file that exclusively contains JSX elements.

Consider creating a separate function specifically for rendering the input, button and list elements,

Input element

Button Element

List Element

We will split the todo item into separate component for improve maintainability.

Todo Item

2. Custom Hooks

Responsible for handling Logics, UI events and callbacks.

For handling Logics, UI Events and Callbacks related to Todo.jsx, We will create a custom hook called useTodo.js

This will improved the maintainability and readability.

We can now test each function in isolation with any Node.js testing library, regardless of whether it supports React components or not.

Let's Add State Logic,

If this component only has a few states, it can be managed within the custom hook itself. However, if the number of states increases, it's best to create a separate file for a reducer and handle the states in that file to avoid cluttering the custom hook.

Let's Add UI Events and Callbacks,

If a component only has a few lines of JS code, it may not be necessary to separate the logic as it can be easily managed within the same file.

3. Utils File

Responsible for logic and helper functions as needed.

To keep our custom hooks clean and organised, we can add any additional logic or helper functions in the todoUtils.js utils file.

4. Reducer File

Responsible for managing and manipulating data (if necessary).

Discover how combining the power of useReducer with the efficiency of Redux Toolkit can help you take your React app's performance and code quality to the next level. Check out our latest blog!

Using useReducer and Redux Toolkit Together: A Powerful Combination for State Management

Sathish Kumar N ・ May 12 '23

#react #reducer #redux #bestpractice

5. Api File

Responsible for connecting to servers.

Separating our API calls into separate files can make our code more modular, allowing you to easily add or remove functionality without affecting other parts of your application.

This can also make it easier to write unit tests for our code. We can add test each component individually, without having to worry about the larger application as a whole.

We can use Redux toolkit - RTK Query's createApi is a powerful feature of the React-Redux Toolkit that provides more number of benefits.

6. Style File

Responsible for styling JSX elements.

When our styles are organised into separate files based on functionality, it is easier to follow the flow of our application and understand how different parts of our code interact with each other.

For React, we can add css, scss and css modules in this styles file.

For React Native, we can add component styles here instead of using in component file itself.

Finally, our todo app will look like this,

Key Learnings: Implementing Separation of Concern

By separating concerns in this way, we have made testing our code much more manageable. Instead of testing the entire component's code, we can now test each function in isolation with any Node.js testing library, regardless of whether it supports React components or not.

This also means that we can reuse these functions in other parts of our application, making them more flexible and maintainable.

By keeping our framework-specific code in the component and the hook, and our business logic in separate functions, we have created a more modular and extensible codebase that is easier to reason about and maintain.

If a component only has a few lines of JS code, it may not be necessary to separate the logic as it can be easily managed within the same file.

You can check this entire code in Code sandbox and GitHub.

Please give your feedback and questions on comments section.

Happy Coding!!