DEV Community: Bruno Henrique

React, we need to talk about Derived States!

Bruno Henrique — Tue, 10 Dec 2024 17:54:54 +0000

When working with React, you’ll often encounter situations where you need to transform or derive values based on other state or props. This concept is known as derived state, and it's one of the most powerful tools in your React toolkit—if used correctly.

“Derived State: State that can be computed from existing piece of state or prop is called derived state.”

So, let’s dive into it and have a bit of fun while we’re at it.

The Bad Practice: Filtering the Product List

Let’s start with a typical "oops, I didn’t think this through" example. Imagine we have a list of products, and we want to filter them based on what the user types into a search input. In an ideal world, our search should update dynamically and be super snappy. But, let’s take a quick look at the bad practice approach first.

Here’s how we shouldn’t be handling things:

import React, { useState } from 'react';

const ProductList = () => {
  const [searchQuery, setSearchQuery] = useState('');
  const [products, setProducts] = useState([
    { id: 1, name: 'Laptop' },
    { id: 2, name: 'Smartphone' },
    { id: 3, name: 'Headphones' },
    { id: 4, name: 'Smartwatch' },
  ]);
  const [filteredProducts, setFilteredProducts] = useState(products);

  const handleSearch = (e) => {
    const query = e.target.value;
    setSearchQuery(query);
    setFilteredProducts(
      products.filter(product =>
        product.name.toLowerCase().includes(query.toLowerCase())
      )
    );
  };

  return (
    <div>
      <input
        type="text"
        value={searchQuery}
        onChange={handleSearch}
        placeholder="Search for a product"
      />
      <ul>
        {filteredProducts.map((product) => (
          <li key={product.id}>{product.name}</li>
        ))}
      </ul>
    </div>
  );
};

export default ProductList;

Why is this bad practice?

It looks like it works, right? The search input is hooked up, and it filters the products as expected.

But here’s the problem: we’re storing the filtered products as a separate state. This causes unnecessary duplication of data. We already have products in state, and we’re storing the result of the filter operation in another state, which leads to potential bugs, increased memory usage, and makes it harder to keep everything in sync.

Basically, we’re making things more complicated than they need to be.

The Good Practice: Using Derived State

Now, let's apply a bit of React wisdom and fix the above code using derived state.

This time, instead of keeping two separate state variables (products and filteredProducts), we'll derive the filtered products directly from the products array based on the searchQuery. This way, we avoid redundancy and keep our state clean.

Here’s the improved version:

import React, { useState } from 'react';

const ProductList = () => {
  const [searchQuery, setSearchQuery] = useState('');
  const products = [
    { id: 1, name: 'Laptop' },
    { id: 2, name: 'Smartphone' },
    { id: 3, name: 'Headphones' },
    { id: 4, name: 'Smartwatch' },
  ];

  // Derived state: filter products based on the search query
  const filteredProducts = products.filter(product =>
    product.name.toLowerCase().includes(searchQuery.toLowerCase())
  );

  const handleSearch = (e) => {
    setSearchQuery(e.target.value);
  };

  return (
    <div>
      <input
        type="text"
        value={searchQuery}
        onChange={handleSearch}
        placeholder="Search for a product"
      />
      <ul>
        {filteredProducts.map((product) => (
          <li key={product.id}>{product.name}</li>
        ))}
      </ul>
    </div>
  );
};

export default ProductList;

What’s the improvement?

No extra state for filtered products: We no longer store a separate list of filteredProducts. Instead, we directly compute the filtered list from the products array and searchQuery on every render.
Cleaner code: The component is simpler, with fewer states to manage. This makes it easier to read and maintain.
Performance boost (sort of): React doesn’t need to track extra state variables. It just derives the filtered list directly from the existing data, making the code leaner and faster (even though React optimizes updates, fewer state changes are always better).

This approach takes advantage of derived state, where the filtered products are computed from existing data, instead of storing an additional copy of the filtered data.

When Not to Use Derived State

While derived state is often the best choice, it’s not the silver bullet for everything. If your component is dealing with complex calculations or state that’s needed across multiple parts of the application, it might be better to use memoization or store that derived state in a higher-level component or context.

But for simple filtering, sorting, or other lightweight derived values, the example above should be your go-to approach.

Conclusion

To sum up, derived state in React is all about keeping things DRY—don’t repeat yourself. Instead of keeping unnecessary copies of the same data in state, calculate values on the fly based on existing state and props. This leads to cleaner, more efficient code that’s easier to maintain. So, the next time you’re tempted to duplicate data in React, think about whether you can calculate it directly from other sources. Your future self will thank you!

Why You Should Learn Entity Relationship Diagrams Before ORMs and Specific Databases

Bruno Henrique — Tue, 10 Dec 2024 00:32:25 +0000

In the fast-paced world of software development, data modeling often takes a backseat to implementation. Many developers dive straight into tools like Object-Relational Mappers (ORMs) or specific databases, such as PostgreSQL or even MongoDB, aiming to build functional systems quickly.

However, skipping the foundational knowledge of Entity Relationship Diagrams (ERDs) can lead to flawed data models, which can propagate bugs and security vulnerabilities throughout an application.

Here’s why mastering ERDs should be a priority for developers before working with ORMs and databases.

What Are Entity Relationship Diagrams (ERDs)?

Well they look like this:

Entity Relationship Diagrams (ERDs) visually represent the structure of a database, mapping entities, attributes, and the relationships between them. They function as blueprints for the logical organization of data and provide a clear representation of:

Entities: Core objects or concepts (e.g., users, products, orders).
Attributes: Details describing each entity (e.g., name, price, status).
Relationships: Connections between entities (e.g., a user places an order).

By understanding ERDs, developers gain insight into how data is interconnected and how it should flow within an application.

Experienced developers can even understand the business logic when they see an ERD diagram in less time than others.

Why ERDs Reduce Bugs in Business Logic

1. Relationships Reflect Business Rules

Every application has business logic that governs how data interacts. For example:

A user must have a valid subscription to access premium content.
An order must belong to a valid user and contain at least one product.

When developers map these relationships in an ERD, they make the business rules explicit. This clarity ensures that:

Constraints (like foreign keys and cardinality rules) are correctly implemented in the database.
Edge cases are considered during the design phase, reducing the likelihood of unexpected bugs.

Skipping ERDs often results in vague or incorrect mappings, where relationships don’t align with the business logic. This leads to runtime bugs, such as orphaned records or inconsistent data.

2. Improved Data Integrity

ERDs enforce relationships between entities, ensuring data consistency. For example:

A many-to-many relationship between users and roles prevents duplication or missing assignments.
A one-to-many relationship between customers and orders ensures every order is tied to an existing customer.

When these rules are defined and implemented correctly, they eliminate classes of bugs caused by inconsistent or invalid data.

Why ERDs Help Secure Client Data

1. Ensures Proper Data Segmentation

By mapping out entities and relationships, ERDs make it easier to enforce data segmentation and access controls. For instance:

Sensitive data, such as customer payment details, can be isolated into separate entities.
Relationships can enforce limited exposure, such as ensuring that an admin can only view or modify specific records.

This systematic organization reduces the risk of data breaches caused by poorly designed schemas where unrelated data is inadvertently exposed.

2. Supports Auditability

ERDs inherently promote a structured approach to data design. By clearly defining relationships, developers can ensure that every action is traceable:

Foreign keys and constraints prevent unauthorized or accidental deletions.
Audit trails can be tied to entity relationships, ensuring every piece of data has an accountable origin and purpose.

This structure is crucial for securing client data, especially in compliance-heavy industries like finance and healthcare.

The Ripple Effects of Mastering ERDs

Fewer Runtime Bugs

Applications often fail at the intersection of data relationships. Bugs like null pointer exceptions, inconsistent query results, and cascading delete failures often arise from poorly defined relationships. ERDs address these issues by defining and enforcing how entities interact before a single line of code is written.

Streamlined Business Logic

With ERDs as a reference, developers can implement business rules more effectively. They can identify where constraints should be applied (e.g., maximum number of items in a cart, unique email addresses for users) and avoid redundant or conflicting logic.

Secure and Scalable Systems

Security: By clearly defining relationships and data boundaries, ERDs help developers design systems with minimal attack surfaces.
Scalability: As applications grow, well-structured ERDs simplify the process of adding new features without disrupting existing functionality.

Real-World Example Bug

Context

Imagine an e-commerce platform where users can place orders. The relationships might be described as follows:

A User can place many Orders (one-to-many relationship).
Each Order must be associated with exactly one User (foreign key in the Orders table pointing to the Users table).

Scenario: Order Deletion Cascade

If the relationship between users and orders is incorrectly configured (e.g., no ON DELETE CASCADE or improper handling of dependencies), deleting a user could leave their orders in the database. This leads to:

Data Inconsistencies: Orphaned orders exist, which no longer belong to any user.
Business Logic Errors: The system might continue to show these orders in sales reports or dashboards, but they cannot be attributed to any user.

Fix with Proper ERD Design

Define the relationship:
- User (UserID) → Primary Key
- Order (OrderID, UserID) → Foreign Key with NOT NULL constraint.
Use ON DELETE CASCADE to ensure that if a user is deleted, their orders are also removed.
Verify constraints in the ERD to match real-world business rules:
- Each order must have exactly one user.
- A user can place multiple orders.

How to Start Leveraging ERDs

1. Learn Core Concepts

Understand:

Key attributes (primary and foreign keys)
Types of relationships (one-to-one, one-to-many, many-to-many)
Normalization to avoid redundancy

2. Practice with Tools

Start with tools like:

Lucidchart or Draw.io for general diagramming.
dbdiagram.io or MySQL Workbench for database-specific modeling.

3. Apply ERDs to Projects

Before coding, create an ERD for every new project. Revisit and refine your diagrams as business requirements evolve.

Conclusion

Mastering Entity Relationship Diagrams is more than just a technical skill—it’s a mindset shift toward structured and intentional system design if you want to be a real Senior Software Engineer.

By understanding how relationships dictate business logic, developers can avoid common pitfalls like inefficient queries, data corruption, and security vulnerabilities. ERDs lay the groundwork for scalable, maintainable, and secure systems, giving developers the tools to design systems that meet both technical and business needs.

Invest in learning ERDs first, and you’ll not only write better code but also deliver systems that are reliable, secure, and future-proof.