Forem: Ayako yk

Exploring PL/SQL Collection Methods: DELETE, TRIM, and Their Best Practices

Ayako yk — Sun, 30 Nov 2025 03:21:39 +0000

In my previous blog post, I covered the fundamentals of PL/SQL collections, focusing on the different types: Associative Arrays, Nested Tables, and VARRAYs. While there’s much more to explore about collections, in this post, I’ll focus on two important collection methods: DELETE and TRIM.

Collection Methods
PL/SQL provides a variety of functions and procedures known as collection methods.

They are called methods because they use member method syntax, unlike functions or procedures, which require passing collections as parameters. The syntax is similar to other programming languages, such as JavaScript.

For example:
COUNT function: Returns the current number of elements in a collection.

Wrong Syntax

COUNT(book_table)

Correct syntax

book_table.COUNT

Note that collection methods are available only in PL/SQL, not within SQL.

While I’m not listing and explaining all the collection methods, let’s focus on DELETE and TRIM, as they have interesting behaviors we should know.

DELETE Method

DELETE

(without any arguments)
Deletes all the rows from the collection.

DELETE(i)

Removes the i-th element from a nested table or associative array.
(Note: VARRAYs do not allow deleting specific elements.)

DELTE(i, j)

Removes all elements in an inclusive range starting from i and ending at j.

Important Note: When you use parameters with DELETE, a placeholder is kept for the “removed” element.

TRIM Method
TRIM removes n elements from the end of a nested table or VARRAY. Using TRIM with an associative array will raise an error. Without arguments, TRIM pops one element from the end of an array.

Do Not Use DELETE and TRIM on the Same Collection
If you use DELETE on an element at the end of a collection and then use TRIM on the same collection, it might seem like you’ve removed two elements. However, as mentioned earlier, the DELETE method places a placeholder for the removed element, so it only actually removes one element. Oracle recommends avoiding the use of both methods on the same collection.

PL/SQL offers powerful and useful methods, but it’s important to pay close attention to how each one is used.

Understanding PL/SQL Collections: Associative Arrays, Nested Tables, and VARRAYs

Ayako yk — Sun, 23 Nov 2025 03:03:09 +0000

In the last blog post, I discussed a record, which is a composite data type. In this blog, I’ll talk about another composite data type: a collection.

According to Oracle documentation, “A collection is an ordered group of data elements, all of the same type.” A collection is a data structure similar to a list or array in other programming languages.

PL/SQL supports three types of collections: Associative arrays, Nested tables, and Varrays.

Associative Arrays
These were called index-by tables in Oracle8 and Oracle8i databases. Associative arrays use arbitrary numbers or strings to look up elements, much like hash tables. They are *single-dimensional, *unbounded, and sparse collections. Associative arrays are available only in PL/SQL.

Nested Tables
Nested tables are also single-dimensional, unbounded collections of elements. They must be initially bounded but are allowed to be sparse, such as through deletion. Nested tables can be stored in database tables and manipulated through SQL.

VARRAYs
VARRAYs (variable-sized arrays) are single-dimensional, but they are always bounded and never sparse. VARRAYs can be used both in PL/SQL and in a database.

*single-dimensional: A PL/SQL collection always has just a single column of information in each row.

*bounded and unbounded: A collection is bounded if it has predetermined limits for the number of rows. An unbounded collection has no upper or lower row limits.

Let’s take a closer look at each type.

Associative Arrays
Syntax (to define a collection type):

TYPE type_name IS TABLE OF element_type [NOT NULL]

    INDEX BY [BINARY_INTEGER | PLS_INTEGER | VARCHAR2(size_limit)];

    INDEX BY key_type;

The key_type can be either numeric or string. As they were previously called index-by tables, elements can be looked up by key-value pairs, which can save code and time because they don’t require loops. However, associative arrays are intended to be used only for temporary storage. To make an associative array persistent throughout the life of a database session, declare it in a package specification and populate it in the package body. Note that associative arrays cannot be used with SQL operations, such as INSERT or SELECT INTO.

Nested Tables
Syntax (to define a collection type):

TYPE type_name IS TABLE OF element_type [NOT NULL];

Here, type_name is a type specifier used later to declare collections.

To store nested tables in database tables, you must declare SQL types.
Syntax (for SQL):

CREATE TYPE type_name IS TABLE OF element_type;

VARRAYs
Syntax:

TYPE type_name IS {VARRAY | VARYING ARRAY} (size_limit)

    OF element_type [NOT NULL];

Where type_name is a type specifier used later to declare collections, and size_limit must be specified to indicate the maximum size.

To store VARRAYs in database tables, you must declare SQL types.
Syntax (for SQL):

CREATE TYPE type_name IS TABLE OF element_type;

Collection Constructors
A collection constructor is a system-defined function with the same name as a collection type.

When a collection has no elements during initialization, it is considered an empty collection. However, a null collection does not exist, so it must be initialized --- either as empty or with non-NULL values.

Syntax:

collection_type([value [, value] ... ])

If the parameter list is empty, the constructor returns an empty collection. Otherwise, the constructor returns a collection containing the specified values.

Example (from a documentation):

TYPE Foursome IS VARRAY(4) OF VARCHAR2(15);
team Foursome := Foursome();

VARRAYs and Nested Tables must be initialized; otherwise, they are null collections.
Associative arrays are considered empty, not null, until populated.

When to Use Which Type

Associative Arrays:

When you need a relatively small lookup table.
When passing collections to and from the database server.

Varrays:

When you know the maximum number of elements.
When you usually access the elements sequentially.

Nested Tables:

When the number of elements is not fixed.
When the index values are not consecutive.
When you need to delete or update some elements, but not all elements simultaneously.
When you would create a separate lookup table with multiple entries for each row of the main table, and access it through join queries.

The Difference Between a Collection and a Record
In a collection, the internal components, called elements, are always the same data type:

variable_name(index)

In a record, the internal components, called fields, can have different data types.

variable

These are the fundamentals of collections. I’ll dive deeper into collections and share more details in the next blog post.

Understanding Records in PL/SQL: Benefits and Limitations

Ayako yk — Sat, 01 Nov 2025 08:05:06 +0000

In the past blog post, I discussed scalar data types (An Introduction to Commonly Used PL/SQL Data Types). In this blog post, I’ll move on to composite data types, with a focus on records.

Here’s a quick review:
Scalar data types store single values without internal components. They represent one value, such as a number, string, or date.
Composite data types can store multiple values, such as records and collections.

A record is a composite data structure, meaning it is made up of multiple related elements or components. According to the Oracle documentation, a record is a group of related data items stored in fields, where each field corresponds to a table column.

The %ROWTYPE attribute lets you declare a record that represents a row in a database table. This makes your code more flexible — even if the table structure changes (for example, if new columns are added), your record declaration remains valid.

Defining and Declaring Records
Here’s an example from the documentation:

DECLARE
-- Declare a record type with 3 fields.
  TYPE rec1_t IS RECORD (field1 VARCHAR2(16), field2 NUMBER, field3 DATE);
-- For any fields declared NOT NULL, we must supply a default value.
  TYPE rec2_t IS RECORD (id INTEGER NOT NULL := -1, name VARCHAR2(64) NOT NULL := '[anonymous]');

-- Declare record variables of the types declared above.
  rec1 rec1_t;
  rec2 rec2_t;

-- Declare a record variable that can hold a row from the EMPLOYEES table.
-- The fields of the record automatically match the names and types of the columns.
-- Don't need a TYPE declaration in this case.
  rec3 employees%ROWTYPE;

-- Or we can mix fields that are table columns with user-defined fields.
  TYPE rec4_t IS RECORD (first_name employees.first_name%TYPE, last_name employees.last_name%TYPE, rating NUMBER);
  rec4 rec4_t;

BEGIN
-- Read and write fields using dot notation
  rec1.field1 := 'Yesterday';
  rec1.field2 := 65;
  rec1.field3 := TRUNC(SYSDATE-1);

-- We didn't fill in the NAME field, so it takes the default value declared above.
  dbms_output.put_line(rec2.name);
END;
/

There are actually three ways to declare a record in PL/SQL.

Table-Based Record
You can create a record based on an existing table by using the %ROWTYPE attribute. Each field in the record automatically corresponds to a column in that table.

Example:

CREATE TABLE employees (
    emp_id          INTEGER,
    emp_name        VARCHAR2(200),
    emp_department  VARCHAR2(200)
);

DECLARE
    employees_rec    employees%ROWTYPE;
BEGIN
    ...
END;

Cursor-Based Record
First of all, a cursor is like a pointer to a result set (the rows returned by a query).

You can declare a record based on a cursor using the %ROWTYPE attribute, where each field corresponds to the columns in the cursor’s SELECT statement.

Example:

DECLARE
    CURSOR employees_cur IS
        SELECT * 
        FROM employees
        WHERE emp_department = 'marketing';

    emp_in_marketing_rec employees_cur%ROWTYPE;
BEGIN
    ...
END;

Programmer-Defined Record
If you don’t need a record that exactly matches a table or cursor, you can define your own custom record type using TYPE...RECORD.

Example:

DECLARE
    TYPE employees_rectype IS RECORD (
        emp_id        employees.emp_id%TYPE,
        emp_name      employees.emp_name%TYPE,
        emp_address   VARCHAR2(200)
    );

    employees_info_rec employees_rectype;
BEGIN
    ...
END;

Operations on Records
Working with records instead of individual fields allows you to write cleaner and more concise code.

Here are some operations that are currently supported by PL/SQL.

Record-Level Operations

Copying: Contents can be copied from one record to another.
NULL Assignment: A NULL value can be assigned to a record.
Passing Records: A record can be defined and passed as an argument to procedures or functions.
Returning Records: A record can be returned from a function.

However, some limitations exist. For example, the IS NULL condition does not work on entire records. You need to check each field individually to determine if it contains a NULL value.

Field-Level Operations
When accessing a field within a record (either to read or update its value), you must use dot notation.

Syntax
record_name.field_name

If you are referencing a record from a package, you can include the package name before the record name:

package_name.record_name.field_name

Records offer significant advantages by allowing us to work with related data more concisely and efficiently, rather than handling individual fields. However, it’s important to keep their limitations in mind and use them carefully, leveraging the available methods to achieve optimal results.

Understanding Oracle Datetime Datatypes: DATE, TIMESTAMP, and INTERVAL

Ayako yk — Sun, 26 Oct 2025 08:23:58 +0000

In this blog post, I’ll explore some fundamental concepts of Oracle’s datetime datatypes---specifically, the DATE, TIMESTAMP, and INTERVAL datatypes. Time-based data is at the core of many applications, from tracking transactions to logging events, so understanding how Oracle handles dates and times is crucial for managing and manipulating this kind of information effectively.

DATE and TIMESTAMP
Oracle used to have only one datatype for date and time, which was DATE. Starting with Oracle 9i, three new TIMESTAMP datatypes were introduced.

The four datetime datatypes:
DATE
TIMESTAMP
TIMESTAMP WITH TIME ZONE
TIMESTAMP WITH LOCAL TIME ZONE

DATE
The DATE datatype stores a date and time, resolved to the second. It does not include time zone information. For each DATE value, Oracle stores century, year, month, date, hour, minute, and second.

You can specify a DATE value by:

Specifying the date value as a literal.
Converting a character or numeric value to a date value with the TO_DATE function.

Examples:

-- Literal (’YYYY-MM-DD’):
DATE ‘1995-10-31’

-- Oracle date values:
TO_DATE(’1995-OCT-31 15:30’, ‘YYYY-MON-DD HH24:MI’, ‘NLS_DATE_LANGUAGE=AMERICAN’)

TIMESTAMP
The TIMESTAMP datatype is an extension of the DATE datatype. It stores year, month, date, hour, minute, and second values. Additionally, it stores fractional seconds, which the DATE datatype does not.
The TIMESTAMP datatype does not store time zone information.

_TIMESTAMP [(fractional_seconds_precision)] _

Where fractional_seconds_precision is optional and specifies the number of digits (0 to 9). The default is 6.

Example

--TIMESTAMP literal (TIMESTAMP ‘YYYY-MM-DD HH24:MI:SS.FF’):
TIMESTAMP ‘1995-10-31 12:34:56.78’

TIMESTAMP WITH TIME ZONE
The TIMESTAMP WITH TIME ZONE datatype stores the time zone along with each date and time value. This makes it possible to manage date and time values in different time zones.

The time zone offset represents the difference between local time and UTC (Coordinated Universal Time).

TIMESTAMP [(fractional_seconds_precision)] WITH TIME ZONE

Where fractional_seconds_precision is optional and specifies the number of decimal places for seconds.

Example:

TIMESTAMP ‘1995-10-31 12:34:56.78 +03:00’

TIMEZONE WITH LOCAL TIME ZONE
The TIMEZONE WITH LOCAL TIME ZONE datatype stores a date and time that is assumed to be in the local time zone. The data is normalized to the database’s time zone (the time zone of the server).

TIMESTAMP [(fractional_seconds_precision)] WITH LOCAL TIME ZONE

Where fractional_seconds_precision is optional and specifies the number of decimal places for seconds.

The difference between TIMESTAMP WITH TIME ZONE and TIMEZONE WITH LOCAL TIME ZONE can be explained in this example:

Let’s say we have an employee clock-in application. The company is based in Tokyo, the employee works in Tokyo, and the database server is also in Tokyo. The employee then goes on a business trip to New York and clocks in from there.

With TIMESTAMP WITH TIME ZONE, the clock-in time is stored in New York time (Eastern Time).

With TIMEZONE WITH LOCAL TIME ZONE, the clock-in time is always stored in Tokyo (Japan) time, regardless of the employee’s actual location.

Interval Datatypes
Oracle9i introduced Interval datatypes, which are used to record and compute quantities of time.

DATE and all TIMESTAMP datatypes represent instances of time (a specific point in time). INTERVAL datatypes, on the other hand, refer to a specific amount or duration of time.

There are two interval datatypes:

INTERVAL YEAR TO MONTH
The INTERVAL YEAR TO MONTH datatype stores a period of time in terms of years and months.

INTERVAL YEAR [(year_precision)] TO MONTH

Where year_precision specifies the number of digits in the YEAR field (from 0 to 9). The default is 2.

You can specify interval values with literals.

Example:

INTERVAL ‘12-3’ YEAR(2) TO MONTH

This specifies an interval of 12 years and 3 months.

INTERVAL DAY TO SECOND
The INTERVAL DAY TO SECOND datatype stores a period of time in days, hours, minutes, and seconds.

INTERVAL DAY [(day_precision)] TO SECOND [(fractional_seconds_precision)]

day_precision specifies the number of digits in the DAY field. Accepted values are 0 to 9, with a default of 2.

fractional_seconds_precision specifies the number of digits in the fractional part of seconds. Accepted values are 0 to 9, with a default of 6.

Example:

INTERVAL ‘2 3:45:10.666’ DAY TO SECOND(3)

This specifies an interval of 2 days, 3 hours, 45 minutes, 10 seconds, and 666 thousandths of a second.

In short, Oracle’s DATE and TIMESTAMP datatypes store and manipulate time-related data, while the INTERVAL datatypes handle periods of time. However, this is just the beginning. In future blog posts, I’ll explore more about these datatypes and their uses.

PL/SQL Program Data: Naming, Declaring, and Best Practices

Ayako yk — Sat, 18 Oct 2025 12:40:25 +0000

When handling data in programming, we need variables or constants to store and manipulate it. In PL/SQL, variables, constants, scalar types, composite types, and containerized types are collectively referred to as program data.

Program data in PL/SQL is defined within a block and exists only for the duration of the PL/SQL session; it is not stored in the database. When working with program data, it’s important to declare its data structure clearly.

In this blog, I’ll discuss the fundamentals of program data and some best practices for managing it in PL/SQL.

Naming Program Data
Double Quotes in Naming
Naming Conventions
Declaring Program Data
Anchored Declarations
Programmer-Defined Subtypes

Naming Program Data
When naming program data, there are a few rules and recommendations:

Length: Names can be up to 30 characters long.
First Character: Names must start with a letter.
Subsequent Characters: After the first letter, names can contain letters, numerals, $, #, and _.
Case Sensitivity: All names are case-insensitive.

Double Quotes in Naming
One interesting thing about PL/SQL’s naming rules is that when using double quotes, all the rules, except the 30-character limit, become flexible.

For example, these names are considered acceptable:
“123@”
“ ”(three spaces)

However, double quotes should generally be avoided for naming program data. They are usually used for table names with lowercase extensions. Using double quotes in variable or constant names can make the code harder to read and maintain.

Naming Conventions
Using prefixes or suffixes can improve the readability and understanding of your variables. Here are some commonly used conventions:

l_ for local variables
g_ for global variables
_rt for record types

Declaring Program Data

Declaring Variables
To declare a variable in PL/SQL, use the following structure:

_name_ _datatype_ [NOT NULL] [_default_assignment_];

[ ] is optional

name: The variable name, following the rules mentioned above.
datatype: Specifies the datatype for the variable, which allocates memory for it.
NOT NULL: If this is used, an exception will be raised if NULL is assigned to the variable.
default_assignment: Optionally assign a default value either by using an assignment operator (:=) or the DEFAULT keyword:

Example

name VARCHAR2(10) := ‘John';
-- or
namd VARCHAR2(10) DEFAULT ‘John';

Declaring Constants
To declare a constant, use the following syntax:

name CONSTANT datatype [NOT NULL] := | DEFAULT default_value;

CONSTANT: The keyword indicating that the variable cannot be reassigned once it’s set.

Constants should be initialized with a value during declaration. They cannot be changed after that.

Anchored Declarations
In PL/SQL, variables can be declared using types that are “anchored” to other sources, such as table columns or other PL/SQL variables. This is done using anchored declarations.

Scalar Anchoring (%TYPE)
You can anchor a variable to a column or another PL/SQL variable’s type using the %TYPE attribute:

variable_name attribute%TYPE [default_value];

Here, attribute can be a column in a database table or a scalar variable in PL/SQL.

Record Anchoring (%ROWTYPE)
You can also anchor a variable to a table row using %ROWTYPE:

variable_name table_name | cursor_name%ROWTYPE [default_value];

In this case, the variable will inherit the structure of a row from the specified table.

Advantages of Anchored Declarations
Hardcoding the datatype when declaring a variable can lead to issues if the data structure changes over time. For example, if you initially declare a variable as NUMBER(5, 2) and later the data grows to $1,000,000, the variable will not work correctly anymore.

By using %TYPE, PL/SQL can automatically adjust to changes in the underlying data type without breaking your code.

NOT NULL with Anchoring
When declaring a variable using %TYPE, you should ensure it is initialized with a default value.

However, if the source of the %TYPE is a database column that already has a NOT NULL constraint, you do not need to specify a default value because the database already guarantees that a value will exist.

Programmer-Defined Subtypes
PL/SQL allows you to create your own subtypes or aliases based on predefined datatypes using the SUBTYPE keyword.

Example

SUBTYPE long_string IS VARCHAR2(10000);

There are two types of subtypes:

Constrained Subtype
A constrained subtype applies specific restrictions to the base type, such as value ranges.

Example

SUBTYPE age_limit IS NUMBER(3) RANGE 0 TO 150;

This restricts the value of age_limit to a number between 0 and 150.

Unconstrained Subtype
An unconstrained subtype does not impose any restrictions on the base type. It is typically used when you simply want to give a more meaningful name to an existing datatype.

Example

SUBTYPE long_string IS VARCHAR2(10000);

In summary, handling program data in PL/SQL requires understanding how to declare variables, constants, and subtypes, and how to use naming conventions and anchored declarations effectively. By following these best practices, we can write more maintainable PL/SQL code.

An Introduction to Commonly Used PL/SQL Data Types

Ayako yk — Sat, 11 Oct 2025 09:05:21 +0000

PL/SQL has two primary categories of data types: Scalar data types and Composite data types.

Scalar data types store single values without internal components. They represent a single value like a number, string, or date.
Composite data types store multiple values, such as records and collections.

Today, I will only discuss Scalar data types.

PL/SQL is an extension of SQL, and many SQL features, including data types, can be used in PL/SQL. However, there are PL/SQL-specific data types as well. It is important to be cautious when using these types, especially when working with database tables, as certain data types in PL/SQL execution blocks may not be directly interpretable in the context of a table (or may need to be handled differently).

Since there are so many data types in both SQL and PL/SQL, including subtypes of scalar data types, deprecated types, and those only maintained for backward compatibility, I will focus on the most commonly used data types as a starting point for beginners like myself.

Scalar data types can be divided into four families, which store numbers, characters, boolean values, and date/time values.

Number Types
NUMBER
PLS_INTEGER
Character Types
CHAR
VARCHAR2
Boolean Type
BOOLEAN
Datetime Types
DATE

Number Types
Number types allow us to store numeric data.

NUMBER
The NUMBER data type stores fixed-point or floating-point numbers. It has a range from 1E-130 to 10E125. You can specify two attributes for the NUMBER type:

Precision: The total number of digits (both to the left and right of the decimal point).
Scale: The number of digits to the right of the decimal point.

Syntax:

NUMBER[(precision, scale)]. *[ ] means optional

NUMBER Subtypes
The following are subtypes of NUMBER that can be used in PL/SQL:
DEC
DECIMAL
DOUBLE PRECISION
FLOAT
INTEGER
INT
NUMERIC
REAL
SMALLINT

These subtypes are useful because they provide names that are compatible with other programming languages. For example, you can use INT in your PL/SQL code, which is also recognized in languages like Java.

PLS_INTEGER
PLS_INTEGER is a PL/SQL-specific data type used to store signed integers. It has a range from -2^31 to 2^31 - 1, or -2,147,483,648 to 2,147,483,647. Since PLS_INTEGER uses machine arithmetic, it requires less storage and is faster than NUMBER for integer operations.

Character Types
Character types allow us to store alphanumeric data.

CHAR
The CHAR data type stores a fixed-length character string, with the maximum size being 32,767 bytes. If the stored string is shorter than the defined length, it will be padded with spaces to the right.

Syntax

CHAR[(maximum_size [CHAR | BYTE])]

If you don’t specify the maximum size, it defaults to 1.

VARCHAR2
The VARCHAR2 data type stores a varying-length character string, with the maximum size also being 32,767 bytes. Unlike CHAR, VARCHAR2 only uses the necessary amount of storage for the string and does not pad with spaces.

Syntax

VARCHAR2(maximum_size [CHAR | BYTE])

Difference Between CHAR and VARCHAR2
The key difference between CHAR and VARCHAR2 is:

CHAR stores a fixed-length string and pads the string with spaces on the right if it is shorter than the defined size.
VARCHAR2 stores a variable-length string and does not pad the string with spaces.

Here’s an example:

str1 CHAR(2) := ‘a’; — This will store ‘a ‘ (with a space)
str2 VARCHAR2(2) := ‘a’; — This will store ‘a’ (no space)

Boolean Type
The BOOLEAN data types store logical values: TRUE, FALSE, and NULL. PL/SQL supports the BOOLEAN type, but SQL does not. This means that BOOLEAN values cannot be used in SQL statements, built-in SQL functions, or PL/SQL functions invoked from SQL.

Datetime Types
DATE
The DATE data type stores date and time values. It includes both the date portion (year, month, day) and the time portion (hours, minutes, seconds).

The time portion is measured in seconds since midnight.
If only the date is specified, the time portion defaults to midnight.
The date portion defaults to the current date when no date is provided.
The SYSDATE function returns the current date and time based on the server’s system clock.

The default date format in Oracle is 'DD-MON-YY' (e.g., ‘01-OCT-25’).

Cutoff Rule
The ‘01-OCT-25’ example represents October 1, 2025. But how does Oracle decide whether it’s 2025 or 1925? Oracle uses a default windowing rule to determine the century. The default cutoff year is 50:

If the year is between 00 and 49, Oracle interprets it as 2000 to 2049.
If the year is between 50 and 99, Oracle interprets it as 1950 to 1999.

To avoid this ambiguity, it’s recommended to specify the year using four digits (e.g., ‘01-OCT-2025’) instead of two digits.

These are the commonly used data types in PL/SQL. As I mentioned earlier, there are other types, including subtypes. Initially, I felt overwhelmed by the vast variety of available types, but now it’s becoming clearer to focus on the fundamental ones to start with. Since PL/SQL is all about handling data, it’s essential to understand the specific data types involved. Expanding our knowledge of each data type will definitely help improve our coding skills.

An Introduction to PL/SQL: How It Works with SQL and Oracle Database

Ayako yk — Sun, 05 Oct 2025 03:24:30 +0000

At a new company, PL/SQL is required to join the team. Although I’ve focused more on the front-end side, to become a full-stack developer, I plan to leverage my knowledge and skills in databases.

I’ll start by covering the fundamentals. As I gain more experience and learn from my mistakes, I’ll dive into more advanced topics and practical cases.

What is PL/SQL?
How It Works
Block-Structured Language
Nesting Blocks
How to Run Blocks
Naming Blocks
SQL Code in PL/SQL Blocks

What is PL/SQL?
PL/SQL is an extension of SQL, designed specifically for the Oracle Database. PL/SQL stands for Procedural Language/ Structured Query Language. While SQL is declarative, meaning SQL itself determines how to execute a command (e.g., when selecting data, we just say SELECT, and SQL returns the result), PL/SQL is imperative. This means we explicitly write the code that tells the system how to execute the command. PL/SQL is a more flexible and powerful data programming language. Note that PL/SQL can only be executed within the Oracle Database and is not designed for standalone languages like Java or C#.

How It Works
PL/SQL code is compiled by the Oracle Database server and stored within the database. At run-time, both PL/SQL and SQL run within the same server process.

Block-Structured Language
PL/SQL is a block-structured language, similar to JavaScript. A PL/SQL block consists of three sections: Declarative, Executable, and Exception Handling, which are separated by the keywords DECLARE, BEGIN, EXCEPTION, and END.

Example from the Oracle Documentation blog:

DECLARE
    l_message
    VARCHAR2 (100) := ‘Hello World!’;
BEGIN
    DBMS_OUTPUT.put_line(l_message);
EXCEPTION
    WHEN OTHERS
    THEN
        DBMS_OUTPUT.put_line(SQLERRM);
END;

Section Explanations:
Declarative: This section contains statements to declare variables, constants, data types, and other code elements.

Executable: This section contains statements that are executed when the block is run.

Exception handling: This section handles errors and catches exceptions when they occur.

The Declarative and exception-handling sections are optional. Only the Executable section is mandatory. Therefore, the following block is perfectly valid.

BEGIN
    DBMS_OUTPUT.put_line(’Hello World!’);
END;

Nesting Blocks
PL/SQL blocks can be nested within other blocks.

How to Run Blocks
There are various tools available for running PL/SQL blocks, and developers often have personal preferences.

SQL*Plus: This is a command-line interface that allows execution of both SQL and PL/SQL. It is often seen as a basic, no-frills tool provided by Oracle for executing SQL statements and PL/SQL blocks.

IDEs: These tools offer more features and enhance productivity. Popular IDEs for PL/SQL development include Oracle SQL Developer and PL/SQL Developer, which provide graphical interfaces that make writing, debugging, and managing PL/SQL code more efficient.

Naming Blocks
The blocks shared above don’t have names. They are called “anonymous blocks” and are often used as temporary PL/SQL units. On the other hand, named blocks, or subprograms, can be useful because they can be called multiple times without needing to declare or write the same repetitive code. They are similar to functions or methods in languages like JavaScript.

Example:

CREATE OR REPLACE FUNCTION
hello_message
    (place_in IN VARCHAR2)
    RETURN VARCHAR2
IS
BEGIN
    RETURN ‘Hello ‘ || place_in;
END hello_message;

The details will be explained later, but for now, it’s important to know that blocks can be named.

SQL Code in PL/SQL Blocks
As mentioned earlier, both PL/SQL and SQL run within the same server process at runtime. Programs written in PL/SQL interact with the Oracle Database using SQL to read from or write to the database. The Oracle Database facilitates this by allowing SQL and PL/SQL to be combined seamlessly.

Example from the Oracle documentation blog.

DECLARE
    l_name employees.last_name%TYPE;
BEGIN
    SELECT last_name
        INTO l_name
        FROM employees
        WHERE employee_id = 138;

    DBMS_OUTPUT.put_line(l_name);
END;

The SELECT, FROM, and WHERE classes are SQL statements but can be used within PL/SQL blocks.

In this blog post, I discussed what PL/SQL is, how it works, and its relationship with SQL and the Oracle Database. As I continue to learn, I may discover additional insights that I initially missed. I’ll revisit and update this post to ensure it provides the best possible understanding.

The Lifecycle of useEffect: Synchronization in React

Ayako yk — Tue, 16 Sep 2025 01:20:06 +0000

In previous blog posts, I discussed the foundation of the useEffect hook and when not to use it. In this post, I'll explore its lifecycle.

useEffect is primarily used to synchronize React components after side effects, which are operations outside of React's main rendering system. The Effect runs after the component mounts, so we should consider React's component lifecycle and useEffect's lifecycle separately. The React documentation mentions this in bold, which I'll share after this brief explanation.

React components go through three stages: mount, update, and unmount. However, useEffect needs to synchronize less frequently or more frequently than the component's cycle.

Here's an example from the React documentation. This component has a dropdown menu, where a user can choose a room ID: general, travel, or music.

function ChatRoom({ roomId /* "general" */ }) {
  useEffect(() => {
    const connection = createConnection(serverUrl, roomId); // Connects to the "general" room
    connection.connect();
    return () => {
      connection.disconnect(); // Disconnects from the "general" room
  };
}, [roomId]);

Every time the roomId changes, the Effect stops synchronizing with the old roomId and starts synchronizing with the new one. React calls the cleanup function.
Therefore, we should consider React's components and useEffect independently.

The React documentation says:

[A]lways focus on a single start/stop cycle at a time. It shouldn’t matter whether a component is mounting, updating, or unmounting. All you need to do is to describe how to start synchronization and how to stop it. If you do it well, your Effect will be resilient to being started and stopped as many times as it’s needed.

How to Tell React to Re-Synchronize
We can tell React when to re-synchronize by providing props or state in the dependency array. An empty dependency array means useEffect runs only when the component mounts.

Each Effect Should Represent a Separate Synchronization Process
We might be tempted to simplify code by combining functions to make it "cleaner." However, we should keep in mind that we will likely add more features and functions later on. So, each useEffect should contain only one logical operation.

The ChatRoom component has two distinct operations: one is logging the user's visit to the page, and the other is connecting to the server. Currently, it might be fine to combine them, as both are triggered when the roomId changes. However, as the component gains more features and the dependency array grows, this could lead to undesired behavior.

function ChatRoom({ roomId }) {
  useEffect(() => {
    logVisit(roomId);

    const connection = createConnection(serverUrl, roomId);
    connection.connect();
    return () => {
      connection.disconnect();
    };
  }, [roomId]);
  ...
}

Instead, we should separate them:

function ChatRoom({ roomId }) {
  useEffect(() => {
    logVisit(roomId);
  }, [roomId]);

  useEffect(() => {
    const connection = createConnection(serverUrl, roomId);
    ...
}, [roomId]);
  ...
}

Effect Should Re-Synchronize Whenever Reactive Values Change
Values declared in a component are all "reactive." This includes not only props and state but also variables that are calculated based on the change of props and state.

Reactive values should re-synchronize with the effect because they change over time. Therefore, we should include those values in the dependency array.

Here's an example from the React documentation:

function ChatRoom({ roomId, selectedServerUrl }) { // roomId is reactive
    const settings = useContext(SettingsContext); // settings is reactive
    const serverUrl = selectedServerUrl ?? settings.defaultServerUrl; //    serverUrl is reactive
    useEffect(() => {
      const connection = createConnection(serverUrl, roomId); // Your Effect reads roomId and serverUrl
      connection.connect();
      return () => {
        connection.disconnect();
      };
    }, [roomId, serverUrl]); // So it needs to re-synchronize when either of them changes!
  ...
}

Linter Will Warn You
When a linter is configured for React, it will throw an error if a dependency array is missing values. The linter isn't perfect and won't automatically fix the issue, but we should carefully read the error message and fix the code.

To recap, we should consider the lifecycle of useEffect separately from the lifecycle of React components. Think of useEffect as handling two tasks: starting synchronization and stopping synchronization. Additionally, we should leverage the linter to catch potential issues, ensuring that we don't miss any bugs when building our application.

When Not to Use useEffect in React

Ayako yk — Sat, 06 Sep 2025 07:59:42 +0000

In the last blog post, I discussed the foundation of useEffect. It is used to synchronize the React component with external systems. However, it's essential to understand that synchronization via useEffect should only occur after side effects have been executed. Unnecessary use of useEffect can lead to slow performance and potential errors. Below are some cases and examples where the unnecessary use of useEffect should be avoided.

The content and examples are taken from the React documentation.

Updating State Based on Props or State
React re-renders whenever there's a state change, so using useEffect to update the state based on a change in props or state is often unnecessary.

Here's an example from the React Documentation, where fullName should be updated whenever firstName and lastName change:

function Form() {
  const [firstName, setFirstName] = useState('Taylor');
  const [lastName, setLastName] = useState('Swift');

  const [fullName, setFullName] = useState('');
  useEffect(() => {
    setFullName(firstName + ' ' + lastName);
    }, [firstName, lastName]);
  ...
}

Instead, fullName can be calculated during rendering:

function Form() {
  const [firstName, setFirstName] = useState('Taylor');
  const [lastName, setLastName] = useState('Swift');

  const fullName = firstName + ' ' + lastName;
  ...
}

Caching Expensive Calculations
When calculations are expensive --- meaning they take a significant amount of time to compute --- caching and avoiding unnecessary re-renders are recommended. We can achieve this by using useMemo.

Here's an example where we filter a to-do list based on the passed props. By using useMemo, the calculation will only be re-rendered if the props change.

function TodoList({ todos, filter }) {
  const [newTodo, setNewTodo] = useState('');
  const visibleTodos = useMemo(() => {
    return getFilteredTodos(todos, filter);
  }, [todos, filter]);
  ...
}

Resetting All State When a Prop Changes
When we have a state, such as comments for each user, and we need to reset the state every time the userId changes (because we don't want to display the comment for other users), we might be tempted to use useEffect. However, the code below is incorrect:

export default function ProfilePage({ userId }) {
  const [comment, setComment] = useState('');

  useEffect(() => {
    setComment('');
    }, [userId]);
    ...
}

The issue is that React first renders the comment, and then the useEffect runs. This means the comment will be displayed before it's reset.
We can fix this by passing the userId as a key in the parent component:

export default function ProfilePage({ userId }) {
  return (
    <Profile
      userId={userId}
      key={userId}
    />
  );
}

function Profile({ userId }) {
  const [comment, setComment] = useState('');
  ...
}

Passing a key tells React to treat each Profilecomponent as independent, ensuring it resets properly when the userId changes.

Adjusting Some State When a Prop Changes
When we want to reset or adjust a part of the state when a prop changes, but not all of it, we might be tempted to use useEffect.

Here's an example from the React documentation. When the items prop changes, the selection should be reset, while isReverse should remain the same:

function List({ items }) {
  const [isReverse, setIsReverse] = useState(false);
  const [selection, setSelection] = useState(null);

  useEffect(() => {
    setSelection(null);
    }, [items]);
    ...
}

With this code, React first renders the selection, and then it is set to null.

One solution is to create an additional state to store the previous value:

function List({ items }) {
  const [isReverse, setIsReverse] = useState(false);
  const [selection, setSelection] = useState(null);

  const [prevItems, setPrevItems] = useState(items);
    if (items !== prevItems) {
      setPrevItems(items);
      setSelection(null);
    }
  ...
}

The React documentation mentions that this approach is better than using useEffect, but there's an even more efficient way:
The following code calculates the state directly during rendering.

function List({ items }) {
  const [isReverse, setIsReverse] = useState(false);
  const [selectedId, setSelectedId] = useState(null);

  const selection = items.find(item => item.id === selectedId) ?? null;
  ...
}

Sharing Logic Between Event Handlers
This code from the React documentation shows how to display a notification when a user buys a product by clicking either a "buy" button or a "checkout" button:

function ProductPage({ product, addToCart }) {
  useEffect(() => {
    if (product.isInCart) {
      showNotification(`Added ${product.name} to the shopping cart!`);
    }
  }, [product]);

  function handleBuyClick() {
    addToCart(product);
  }

  function handleCheckoutClick() {
    addToCart(product);
    navigateTo('/checkout');
  }
  ...
}

In this code, product is declared in the dependency array, so every time the user visits or refreshes the page, the notification is displayed. This is incorrect. The notification should only be shown as a result of a user action (like clicking a button). Therefore, it should be triggered inside an event handler, not in the useEffect.

Here's how you can fix it:

function ProductPage({ product, addToCart }) {
  function buyProduct() {
    addToCart(product);
    showNotification(`Added ${product.name} to the shopping cart!`);
  }

  function handleBuyClick() {
    buyProduct();
  }

  function handleCheckoutClick() {
    buyProduct();
    navigateTo('/checkout');
  }
  ...
}

Sending a POST Request
How should we handle these two kinds of POST requests?
One is to send an analytics event when the page mounts, and the other is to send a form submission when a submit button is clicked.

Here's an example from the React documentation:

function Form() {
  const [firstName, setFirstName] = useState('');
  const [lastName, setLastName] = useState('');

// Correct
  useEffect(() => {
    post('/analytics/event', { eventName: 'visit_form' });
  }, []);

// Incorrect
  const [jsonToSubmit, setJsonToSubmit] = useState(null);
  useEffect(() => {
    if (jsonToSubmit !== null) {
      post('/api/register', jsonToSubmit);
    }
  }, [jsonToSubmit]);

  function handleSubmit(e) {
    e.preventDefault();
    setJsonToSubmit({ firstName, lastName });
  }
  ...
}

In the first case, useEffect is appropriate because the POST request should be sent when the page is displayed or mounted. In the second case, however, the POST request should be sent only when the user clicks the submit button. Therefore, it should be handled inside an event handler, not useEffect.

Here's a correct version:

function Form() {
  const [firstName, setFirstName] = useState('');
  const [lastName, setLastName] = useState('');

  useEffect(() => {
    post('/analytics/event', { eventName: 'visit_form' });
  }, []);

  function handleSubmit(e) {
    e.preventDefault();
    post('/api/register', { firstName, lastName });
  }
  ...
}

Chains of Computations
The code below uses multiple useEffect hooks, which trigger another useEffect when one state changes:

function Game() {
  const [card, setCard] = useState(null);
  const [goldCardCount, setGoldCardCount] = useState(0);
  const [round, setRound] = useState(1);
  const [isGameOver, setIsGameOver] = useState(false);

  useEffect(() => {
    if (card !== null && card.gold) {
      setGoldCardCount(c => c + 1);
    }
  }, [card]);

  useEffect(() => {
    if (goldCardCount > 3) {
      setRound(r => r + 1)
      setGoldCardCount(0);
    }
  }, [goldCardCount]);

  useEffect(() => {
    if (round > 5) {
      setIsGameOver(true);
    }
  }, [round]);

  useEffect(() => {
    alert('Good game!');
  }, [isGameOver]);

  function handlePlaceCard(nextCard) {
    if (isGameOver) {
      throw Error('Game already ended.');
    } else {
      setCard(nextCard);
    }
  }
...

This approach is not only inefficient but also prone to errors as the logic evolves (e.g., when tracking past state changes).
It's better to calculate and adjust the state within the event handler, rather than using useEffect.

function Game() {
  const [card, setCard] = useState(null);
  const [goldCardCount, setGoldCardCount] = useState(0);
  const [round, setRound] = useState(1);

  const isGameOver = round > 5;

  function handlePlaceCard(nextCard) {
    if (isGameOver) {
    throw Error('Game already ended.');
  }

  setCard(nextCard);
  if (nextCard.gold) {
    if (goldCardCount <= 3) {
      setGoldCardCount(goldCardCount + 1);
    } else {
      setGoldCardCount(0);
      setRound(round + 1);
      if (round === 5) {
        alert('Good game!');
      }
    }
  }
} 
...

In some cases, such as when showing a dropdown menu, we might still need a chain of useEffect hooks. However, we should first consider whether it can be calculated directly in the event handler instead of relying on multiple useEffect hooks.

Initializing the Application
When you have logic that should run only once when an app is initially loaded, you might be tempted to include a useEffect hook at the top level in App.js.

function App() {
  useEffect(() => {
    loadDataFromLocalStorage();
    checkAuthToken();
  }, []);
  ...
}

However, React runs twice in Strict Mode, which can lead to unexpected behavior. Even though the code runs only once in production, it's still best to avoid this pattern.

One solution is to declare a variable that tracks whether the initialization has already occurred:

let didInit = false;

function App() {
  useEffect(() => {
    if (!didInit) {
      didInit = true;
      loadDataFromLocalStorage();
      checkAuthToken();
    }
  }, []);
  ...
}

Notifying Parents of State Changes
If you have a toggle that is triggered by either clicking or dragging, you might want to use the useEffect hook to change the state when the props change. However, this approach is incorrect because the state is rendered first, and then useEffect is run.

function Toggle({ onChange }) {
  const [isOn, setIsOn] = useState(false);

  useEffect(() => {
    onChange(isOn);
  }, [isOn, onChange])

  function handleClick() {
    setIsOn(!isOn);
  }

  function handleDragEnd(e) {
    if (isCloserToRightEdge(e)) {
      setIsOn(true);
    } else {
      setIsOn(false);
    }
  }
  ...
}

Rather than using useEffect, we should have an updating function and include it in both handlers:

function Toggle({ onChange }) {
  const [isOn, setIsOn] = useState(false);

  function updateToggle(nextIsOn) {
    setIsOn(nextIsOn);
    onChange(nextIsOn);
  }

  function handleClick() {
    updateToggle(!isOn);
  }

  function handleDragEnd(e) {
    if (isCloserToRightEdge(e)) {
      updateToggle(true);
    } else {
      updateToggle(false);
    }
  }
...
}

Alternatively, we can lift the state up and let the parent component control the state:

function Toggle({ isOn, onChange }) {
  function handleClick() {
  onChange(!isOn);
}

function handleDragEnd(e) {
  if (isCloserToRightEdge(e)) {
    onChange(true);
  } else {
    onChange(false);
  }
}

Passing Data to the Parent
In this example, the child component is trying to fetch data and pass it to its parent component.

function Parent() {
  const [data, setData] = useState(null);
  ...
  return <Child onFetched={setData} />;
}

function Child({ onFetched }) {
  const data = useSomeAPI();

  useEffect(() => {
    if (data) {
      onFetched(data);
    }
  }, [onFetched, data]);
...
}

However, this approach goes against React's general pattern of data flow. In React, data typically flows downward from parent to child components, not the other way around. Instead, the parent should pass the data down to its child components.

Subscribing to an External Store
In some cases, you might need to subscribe to data outside of React's state, such as data from a third-party library or a built-in API. Since this data can change without React's knowledge, you need to manually subscribe to it. This is typically done using the useEffect hook.

function useOnlineStatus() {
  const [isOnline, setIsOnline] = useState(true);
  useEffect(() => {
    function updateState() {
      setIsOnline(navigator.onLine);
    }

    updateState();

    window.addEventListener('online', updateState);
    window.addEventListener('offline', updateState);
    return () => {
      window.removeEventListener('online', updateState);
      window.removeEventListener('offline', updateState);
    };
  }, []);
  return isOnline;
}

function ChatIndicator() {
  const isOnline = useOnlineStatus();
...
}

This is a common pattern for subscribing to external data, but React provides a purpose-built hook for subscribing to external stores: useSyncExternalStore. This approach is less error-prone than manually subscribing to mutable data in useEffect.

function subscribe(callback) {
  window.addEventListener('online', callback);
  window.addEventListener('offline', callback);
  return () => {
    window.removeEventListener('online', callback);
    window.removeEventListener('offline', callback);
  };
}

function useOnlineStatus() {
  return useSyncExternalStore(
    subscribe,
    () => navigator.onLine,
    () => true
  );
}

function ChatIndicator() {
  const isOnline = useOnlineStatus();
  ...
}

Fetching Data
The SearchResult component fetches data when the query or page prop changes. This logic should be placed inside useEffect, not an event handler.

While the user types a search query, there's a risk of a race condition. This happens because each character typed triggers a new fetch request, and responses might come back in an unexpected order. For example, if the user types quickly, the requests may arrive out of order, leading to incorrect results being displayed. This is called a "race condition":

two different requests 'raced' against each other and came in a different order than you expected.

To fix this issue, a cleanup function is needed to ignore outdated responses. This ensures that only the results of the last requested fetch are displayed.

function SearchResults({ query }) {
  const [results, setResults] = useState([]);
  const [page, setPage] = useState(1);
  useEffect(() => {
    let ignore = false;
    fetchResults(query, page).then(json => {
      if (!ignore) {
      setResults(json);
      }
    });
    return () => {
      ignore = true;
    };
  }, [query, page]);

  function handleNextPageClick() {
    setPage(page + 1);
  }
  ...
}

With this cleanup function in place, only the latest search query or the last fetch request will update the state, ensuring the user sees the correct results.

In the previous blog post, we explored the fundamental uses of useEffect, and it's easy to feel tempted to use it whenever it seems applicable. However, it's important to fully understand why and when the useEffect hook is necessary, and to use it correctly.

Understanding useEffect in React: Managing Side Effects and Cleanup

Ayako yk — Mon, 25 Aug 2025 01:15:22 +0000

React often requires us to manage and synchronize operations outside of its rendering process. In the upcoming blogs, we'll dive into how useEffect helps handle side effects in React.

React has two types of core logic, which are important to understand before diving into Effects:

Rendering Code:
This sits at the top level of a component and returns JSX. It must be pure --- like a mathematical formula, it only calculates and returns a result without causing any side effects.

Event Handlers:
These are nested functions that respond to user interactions, such as button clicks. Event handlers can change state or perform other actions, causing side effects (e.g., updating an input, making a network request, or navigating to another page).

React mounts on initial rendering and whenever there is a change in state. However, there are cases when a render is needed even without a state change or event handler. This can happen due to side effects that require a re-render.

Side effects are operations that happen outside of the main rendering process. They might include modifying non-local variables, raising errors, modifying the DOM, or interacting with external systems (like connecting to a server).

To synchronize React components after side effects, the Effect hook comes into play.

useEffect
useEffect delays the execution of the code inside it.
First, a component or a page is rendered.
After that, the code inside the useEffect is executed.

Here's an example from the React Documentation:

function VideoPlayer({ src, isPlaying }) {
  const ref = useRef(null);

  if (isPlaying) {
    ref.current.play();  // Calling these while rendering isn't allowed.
  } else {
    ref.current.pause(); // Also, this crashes.
  }

  return <video ref={ref} src={src} loop playsInline />;
}

export default function App() {
  const [isPlaying, setIsPlaying] = useState(false);
  return (
    <>
      <button onClick={() => setIsPlaying(!isPlaying)}>
        {isPlaying ? 'Pause' : 'Play'}
      </button>
      <VideoPlayer
        isPlaying={isPlaying}
        src="https://interactive-examples.mdn.mozilla.net/media/cc0-videos/flower.mp4"
      />
    </>
  );
}

This code won't work because it tries to access the ref while the component is being rendered before the DOM element is available. The ref of the DOM element doesn't exist yet. To fix this, we need to let the component render first and then execute the side effects using useEffect:

useEffect(() => {
  if (isPlaying) {
    ref.current.play();
  } else {
    ref.current.pause();
  }
});

The Importance of Cleanup
When code that connects to a server is placed inside useEffect, it is executed when the component is mounted. If a user navigates to another component and then returns to the original one, this code is executed again, causing new connections to be queued. This can lead to bugs.

To fix this, we need to disconnect the server or perform a cleanup of the connection.

Here's an example from the React Documentation:

export default function ChatRoom() {
  useEffect(() => {
    const connection = createConnection();
    connection.connect();
    return () => connection.disconnect();
  }, []);
  return <h1>Welcome to the chat!</h1>;
}

In React Strict Mode (enabled by default in development), React intentionally runs certain lifecycle methods, like useEffect, twice to help developers identify issues and ensure code behaves correctly.

There's much more to learn about useEffect in React. While the React documentation categorizes some of these concepts as "advanced," it's essential for developers to gain a deep understanding of how React works.

Understanding State Management with useReducer in React

Ayako yk — Sun, 17 Aug 2025 22:13:31 +0000

In the previous blog posts, I discussed state management and how it works with useState. In this post, I'll cover useReducer and how to manage state in React.

What is a Reducer?
Why do we use it?
How Reducer Works

What is a Reducer?
A reducer is a function used with the useReducer hook, which needs to be imported at the top of your file.

const [state, dispatch] = useReducer(reducer, initialArg, init?)

Why do we use it?
As an app grows larger and more state variables are required across multiple components, it becomes harder to manage, test, and debug them. While useState and useReducer are similar in functionality, useReducer can make our code easier to handle. By using a reducer, we can create a separate file that contains only the reducer function instead of writing it in each component. This reduces the amount of code within individual components, which is one of the reasons why it is called a "reducer."

How Reducer Works
With useState, we update the state by using an updater function (e.g., setUser in the example below):

const [user, setUser] = useState('');

With useReducer, we dispatch an action that describes what the user did, along with the current state. The reducer function then processes the action and returns the updated state.

Let's take a look at the example shared in the React Documentation.

This app contains a TaskApp component that handles adding, editing, and deleting tasks for a trip to Prague.

This component has three event handlers (for adding, editing, and deleting) to update the state (setTasks).

export default function TaskApp() {
  const [tasks, setTasks] = useState(initialTasks);

  function handleAddTask(text) {
    setTasks([
      ...tasks,
      {
        id: nextId++,
        text: text,
        done: false,
      },
    ]);
  }

  function handleChangeTask(task) {
    setTasks(
      tasks.map((t) => {
        if (t.id === task.id) {
          return task;
        } else {
          return t;
        }
      })
    );
  }

  function handleDeleteTask(taskId) {
    setTasks(tasks.filter((t) => t.id !== taskId));
  }

It's better to write these functions in a separate file, so here's the tasksReducer.js file:

function tasksReducer(tasks, action) {
  switch (action.type) {
    case 'added': {
      return [
        ...tasks,
        {
          id: action.id,
          text: action.text,
          done: false,
        },
      ];
    }
    case 'changed': {
      return tasks.map((t) => {
        if (t.id === action.task.id) {
          return action.task;
        } else {
          return t;
        }
      });
    }
    case 'deleted': {
      return tasks.filter((t) => t.id !== action.id);
    }
    default: {
      throw Error('Unknown action: ' + action.type);
    }
  }
}

A reducer function needs two parameters: one is the current state (tasks) and the other is the action. The action is an object that contains a type (which describes the action the user performed) and additional data, such as id or task, that the reducer function needs. The reducer function returns the updated (or next) state.

In each component, we declare useReducer at the top of the file:

const [tasks, dispatch] = useReducer(tasksReducer, initialTasks);

We then use the dispatch function in an event handler.

import { useReducer } from 'react';
import AddTask from './AddTask.js';
import TaskList from './TaskList.js';
import tasksReducer from './tasksReducer.js';

export default function TaskApp() {
  const [tasks, dispatch] = useReducer(tasksReducer, initialTasks);

  function handleAddTask(text) {
    dispatch({
      type: 'added',
      id: nextId++,
      text: text,
    });
  }

  function handleChangeTask(task) {
    dispatch({
      type: 'changed',
      task: task,
    });
  }

  function handleDeleteTask(taskId) {
    dispatch({
      type: 'deleted',
      id: taskId,
    });
  }

  return (
    <>
      <h1>Prague itinerary</h1>
      <AddTask onAddTask={handleAddTask} />
      <TaskList
        tasks={tasks}
        onChangeTask={handleChangeTask}
        onDeleteTask={handleDeleteTask}
      />
    </>
  );
}

let nextId = 3;
const initialTasks = [
  {id: 0, text: 'Visit Kafka Museum', done: true},
  {id: 1, text: 'Watch a puppet show', done: false},
  {id: 2, text: 'Lennon Wall pic', done: false},
];

Two important rules when we use useReducer:

Reducers must be pure: This means that for the same inputs, the reducer must always return the same outputs, with no side effects.
Each action describes a single user interaction: This means one action should handle one specific task or change, even if that task leads to multiple changes in the data.

Even though useReducer may seem more complex at first glance due to its additional code and structure compared to useState, it ultimately makes the code more readable and manageable in larger applications.

Understanding State in React: Managing State Between Components

Ayako yk — Tue, 12 Aug 2025 15:19:59 +0000

In my previous blog post, I covered the fundamentals of state in React, including concepts like state as a snapshot, batching, and updating states. In this post, I'll dive deeper into state management, focusing on how to manage state between components.

Declarative vs. Imperative
Lifting State Up
React's State and the Render Tree
Component State and React's Behavior
State Preservation
State Destruction
Rendering Different Components
Using "key" to Preserve State

Declarative vs. Imperative
React is declarative, not imperative. This means that instead of telling React exactly how to update the UI, you simply declare what the UI should look like based on the current state. React then takes care of the rest.

For example, if the state isOpen is true, React will display a hamburger menu; if the state is false, it will hide the menu.

Lifting State Up
When two separate components need to share and manage the same state, it's a good practice to "lift" the state up. This means moving the state to their closest common parent component and passing it down to the child components via props. This achieves a single source of truth for the state.

Components with props passed down are called controlled, while components that manage their own states are called uncontrolled.

Component State and React's Behavior
When you render the same component multiple times, each instance of the component is independent and holds its own state, which doesn't affect the other instances.

Here's an example from React's documentation:
(The code has been simplified for clarity.)

export default function App() {
  const counter = <Counter />;
  return (
    <div>
      {counter}
      {counter}
    </div>
  );
}

function Counter() {
  const [score, setScore] = useState(0);
  return (
    <div>
      <h1>{score}</h1>
      <button onClick={() => setScore(score + 1)}>
        Add one
      </button>
    </div>
  );
}

Here's an image of the React component tree.

State Preservation
React keeps the state for as long as the same component is re-rendered at the same position in the render tree.

State Destruction
When the component is unmounted, the state is destroyed. When it is mounted again, the state is initialized.

The "Render the second counter" checkbox removes the second component and creates a new one.

Example:

If the same component is rendered at the same position (e.g., by conditional state), the state is preserved.

Example:

export default function App() {
  const [isFancy, setIsFancy] = useState(false); // Fancy adds fancy styles
  return (
    <div>
      {isFancy ? (
        <Counter isFancy={true} /> 
      ) : (
        <Counter isFancy={false} /> 
      )}
    </div>
  );
}

Rendering Different Components
Rendering different components at the same position resets the state, as React treats them as separate instances.
In this example, different components are rendered depending on the condition: one is <p>, and the other is <Count />. This will reset the state.

export default function App() {
  const [isPaused, setIsPaused] = useState(false);
  return (
    <div>
      {isPaused ? (
        <p>See you later!</p> 
      ) : (
        <Counter /> 
      )}
    </div>
  );
}

Using key to Preserve State
To preserve the state for each component, we can either render them at different positions in the tree or assign a unique key to each component.

The use case is when we want to keep separate counters for different people: Person A's counter and Person B's counter. We don't want to display Person A's counter for Person B. By giving a unique key to each component, React can distinguish between them.
Here's an example from the React documentation:

export default function Scoreboard() {
  const [isPlayerA, setIsPlayerA] = useState(true);
  return (
    <div>
      {isPlayerA ? (
        <Counter key="Taylor" person="Taylor" />
      ) : (
        <Counter key="Sarah" person="Sarah" />
      )}
      <button onClick={() => {
        setIsPlayerA(!isPlayerA);
      }}>
        Next player!
      </button>
    </div>
  );
}

Note that when switching from Person B back to Person A, the state is reinitialized.

The latest React documentation explains things so well that it gave me a much clearer understanding of how React treats state. I only wish I had known this when I first started learning React. I hope you found this article helpful, and I encourage you to visit the React documentation for more details and further practice (it also offers challenges to deepen your understanding).