DEV Community: Michael Gustus

useStateDebounced: debounced state in React

Michael Gustus — Tue, 14 Feb 2023 13:10:42 +0000

Simple yet powerful solution for debounced state in react. This hook is based on the standard react hook useState. useStateDebounced provides a similar functionality. It returns the same array of [value, setValue] plus debounced value.

useStateDebounced hook

function useStateDebounced(delay, initialState)) {
  const [value, setValue] = useState(initialState);
  const [debouncedValue, setDebouncedValue] = useState(value);

  useEffect(() => {
    const timer = setTimeout(
      () => setDebouncedValue(value),
      delay
    );

    return () => {
      clearTimeout(timer);
    };
  }, [value, delay]);

  return [value, debouncedValue, setValue];
}

Usage

Usually we need debounced state to delay some costly operation execution until user interaction finished. In this example we wait for the user to finish typing in the search dialog before fetching a new list of recipes. So 700 ms after the last user's keystroke debouncedTerm is updated and the server query is executed.

import React, { useEffect, useState } from 'react';
import { useStateDebounced } from 'use-state-debounced';


export const RecipesList = () => {
  const [recipes, setRecipes] = useState([]);
  const [term, debouncedTerm, setTerm] = useStateDebounced(700, 'pizza');

  useEffect(() => {
    const filteredList = await fetchRecepiesFromServer(debouncedTerm);
    setRecipes(filteredList);
  }, [debouncedTerm]);

  return (
    <>
      <input value={term} onChange={e => setTerm(e.target.value)} />

      <ul>
        {recipes.map((r) =>
          (<li key={r.id}>{r.name}</li>)
        )}
      </ul>
    </>
  );
};

In the above example we use <input> as a controlled component. For uncontrolled components the first term parameter can be omitted.

const [, debouncedTerm, setTerm] = useStateDebounced(700);

<input onChange={e => setTerm(e.target.value)} />

TypeScript version of useStateDebounced can be found here.

React: different types of state management

Michael Gustus — Thu, 25 Nov 2021 13:15:50 +0000

This is my classification of different types of state management in React.

1. React context

This is a native mechanism in react core.
Actually context is not exactly state management tool, it is kind of Dependency Injection. Context provides a way to pass data through the component tree without having to pass props down manually at every level. It is best used when you have some value that is rarely changed and you want to make it accessible to a portion of your React component tree (without passing that value down as props through each level of components).

Issues:

Making a change in some inner param of the state object that is stored in a context will rerender all the consumers of this context (even if they don't use this specific param). So context can only store a single value, not an indefinite set of values each with its own consumers.
Context hell - using this approach as a state management tool will lead us to many nested contexts in different places in react tree.

2. Global store

redux, zustand
Centralized application state and logic based on Flux architecture model by Facebook. The major idea behind Flux is that there is a single-source of truth (the store) and it can only be updated by triggering actions. The actions are responsible for calling the dispatcher, to which the store is subscribed for changes and updates.

Notes:

redux: One of the most known state management solutions in JS world. Lots of boilerplate - actions, reducers, selectors.
zustand: A small, fast and scalable state-management solution using simplified flux principles. It requires much less boilerplate code due to its opinionated approach. In zustand the store doesn't have to be global, but still..
Complicated store mutation. Need to create immutable path when modifying some nested state. Using utils like immer or immutable may help to manipulate the store.

3. Magic store

MobX, Valtio
This type of state management solution wraps the store params in a proxy. So you deal with a proxy and not with the object directly. You perform some simple operation and magically behind the scene, the shared state changes.

Notes:

Need to be aware of the fact that it is proxy and of the specific rules of this kind of state management.

4. Atomic model

recoil, jotai
A bottom-up approach to React state management with an atomic model. Atoms are units of state. They're updateable and subscribable. One can build state by combining atoms and renders are optimized based on atom dependency. This solves the extra re-render issue of React context and eliminates the need for the memoization technique.

Notes:

A boilerplate-free API where shared state has the same simple get/set interface as React local state (useState/useAtom).
recoil is considered to be experimental project (02/2023).

Network request global cache

These libraries help to perform network requests in React. One of the main features of these libraries is to keep the requests in cache. So next time you perform the same request, you will get a cached response. It doesn't metter where in the react tree you perform this request, the cache is global and behaves like a global state management solution for network requests.

5. REST cache

react-query, swr
These libraries have many features based on their sophisticated cache mechanism like: request retry, revalidation, polling, prefetching and more.

Notes:

SWR (stale-while-revalidate) is a strategy to first return the data from cache (stale), then send the fetch request (revalidate), and finally come with the up-to-date data.

6. GraphQL cache

apollo, urql
These are graphql clients that keep cache of graphql network requests. Their behavior is similar to the REST cache solutions from above. The cache is global and behaves like a global state management solution for graphql requests.

Notes:

Apollo uses normalized cache which reduces data redundancy but is more complicated.

P.S. In my latest project I chose jotai, react-query and apollo.
:)

Filtering GraphQL Query using TypeScript and TypeORM

Michael Gustus — Thu, 09 Apr 2020 23:20:38 +0000

This article explores filtering capabilities we can add to the GraphQL API. In some cases we need to filter data by applying one or many matching rules or composition of various rules.

The idea is to expose an ORM-like query-ability through our GraphQL API where we can have flexibility on the client-side to ask for complex pieces of data.

Let's have the following example of tables in the relational database:

Customers

id	name	city	postal_code
11	Harry Ashworth	London	EC2 5NT
12	Patricio Simpson	Buenos Aires	51010
13	Victoria Chang	London	N6 4AL

Orders

id	customer_id	order_date	quantity	product
10289	11	2016-08-26	30	Toys
10290	11	2016-08-27	25	Programming books
10410	12	2017-01-10	49	Programming books
10411	12	2017-03-15	34	Fiction books
10259	13	2016-07-18	10	Toys

TypeORM entity classes

TypeORM is an ORM that can run in various JavaScript platforms (e.g. Node.js) and can be used with TypeScript. These are the TypeORM entity classes matching the tables introduced above:



@Entity("Customers")
export class CustomerEntity {
  @PrimaryGeneratedColumn({ type: "int", name: "id" })
  id: number;

  @Column("varchar", { name: "name", length: 255 })
  name: string;

  @Column("varchar", { name: "city", length: 255 })
  city: string;

  @Column("varchar", { name: "postal_code", length: 255 })
  postalCode: string;

  @OneToMany(() => OrderEntity, order => order.customer)
  orders: OrderEntity[];
}


@Entity("Orders")
export class OrderEntity {
  @PrimaryGeneratedColumn({ type: "int", name: "id" })
  id: number;

  @Column("datetime", { name: "order_date" })
  orderDate: Date;

  @Column("int", { name: "quantity" })
  quantity: number;

  @Column("varchar", { name: "product", length: 255 })
  product: string;

  @ManyToOne(() => CustomerEntity, customer => customer.orders)
  @JoinColumn({name: 'customer_id', referencedColumnName: 'id'})
  customer: CustomerEntity;
}

Note the additional relation field at the end of each class. They describe the relation between these two tables. In our case it is one-to-many relation between Customers and Orders. So one customer can have many orders.

Query Filters

Now let's say that our client-side needs to ask a complex query over the data that was presented above. For example something like this:

Get all orders that: (have quantity >= 20) AND (ordered books) AND [
(order date >= '2016-08-27') OR (customers with ids 11, 12) OR
(customers whose postal code contains '5NT') ]

We can break this complex query to atomic filters in SQL format:



a = (OrderEntity.quantity >= 20)
b = (OrderEntity.product LIKE '%books%')
c = (OrderEntity.orderDate >= '2016-08-27')
d = (CustomerEntity.id IN (11, 12))
e = (CustomerEntity.postalCode LIKE '%5NT%')

So the logical expression will be:



a AND b AND (c OR d OR e)

This logical expression we can represent as expression tree:

Take a look here for more information about expression trees.

GraphQL schema

Now let's create a GraphQL schema that will allow us to make such a query.



    enum Operator {
      AND
      OR
    }

    enum Operation {
      EQ
      IN
      LIKE
      GE
    }

    input Filter {
      op: Operation!
      values: [String!]!
      field: String!
      relationField: String
    }

    input FiltersExpression {
      operator: Operator!
      filters: [Filter!]
      childExpressions: [FiltersExpression!]
    }

The main type here is FiltersExpression which corresponds to a non-leaf node in the expression tree. These are logical operation nodes like 'AND' or 'OR'.
The leaf nodes are represented by Filter type. These are the atomic filters that we named with the lowercase letters (a, b, c, d, e).

FiltersExpression

operator - logical operator ('AND' or 'OR').
filters - descendant atomic filters (leaf nodes) of this node.
childExpressions - descendant sub expressions (sub trees).

* When building the logical expression of the given FiltersExpression node, operator is put between all the descendants of this node.

Filter

GraphQL type for atomic filter (leaf node of the expression tree). For example: CustomerEntity.id IN (11, 12).

op - conditional operation of the atomic filter (op: IN).
values - the values of the filter (values: 11, 12).
field - table field name (field: CustomerEntity.id).
relationField - this optional parameter represents a foreign key in the main table that takes us to the table of the field. In TypeORM we add such a field to the entity class to have a relation between the tables. relationField will be used to join these tables in SQL query. (in this example: relationField: OrderEntity.customer).

Now let's look at the rest of the server side GraphQL schema. Here we have Customer and Order types in accordance with the TypeORM entities, and getOrders query that receives the filters expression and returns all the suitable orders:



    type Customer {
      id: Int!
      name: String!
      city: String
      postalCode: String!
    }

    type Order {
      id: Int!
      customer: Customer!
      orderDate: String!
      quantity: Int!
      product: String!
    }

    extend type Query {
      getOrders(filters: FiltersExpression): [Order!]!
    }

Client Side

On the client side we would like to call the getOrders query using that complex filter expression from our main example. This is the body of the GraphQL query sent by the client:



query getOrders {
  getOrders(filters: {
    operator: AND
    filters: [
      {
        field: "OrderEntity.quantity"
        op: GE
        values: ["20"]
      },
      {
        field: "OrderEntity.product"
        op: LIKE
        values: ["books"]
      }
    ]
    childExpressions: [
      {
        operator: OR        
        filters: [
          {
            field: "OrderEntity.orderDate"
            op: GE
            values: ["2016-08-27"]
          },
          {
            field: "CustomerEntity.id"
            relationField: "OrderEntity.customer"
            op: IN
            values: ["11", "12"]
          },
          {
            field: "CustomerEntity.postalCode"
            relationField: "OrderEntity.customer"
            op: LIKE
            values: ["5NT"]
          }
        ]
      }
    ]
  }) {
    id
    orderDate
    quantity
    product
    customer {
      name
      city
    }
  }
}

Server Side

Now we are ready to implement this filtered query. Please take a look at the graphql resolver of getOrders:

OrderResolvers.ts



import {getRepository} from 'typeorm';
import {SelectQueryBuilder} from 'typeorm/query-builder/SelectQueryBuilder';
import {OrderEntity} from './OrderEntity';

export const resolvers = {
  Query: {
    getOrders: (parent, {filters}): Promise<OrderEntity[]> => {
        const ordersRepo = getRepository(OrderEntity);
        const fqb = new FilterQueryBuilder<OrderEntity>(ordersRepo, filters);
        const qb: SelectQueryBuilder = fqb.build();

        return qb.getMany();
    }
}

The resolver uses FilterQueryBuilder to build the TypeORM query. Let's create it.

FilterQueryBuilder.ts



import {Repository} from 'typeorm';
import {SelectQueryBuilder} from 'typeorm/query-builder/SelectQueryBuilder';

export default class FilterQueryBuilder<Entity> {
  private readonly qb: SelectQueryBuilder<Entity>;

  constructor(entityRepository: Repository<Entity>,
              private filtersExpression?: FiltersExpression) {
    this.qb = entityRepository.createQueryBuilder();
  }

  build() {
    const jb = new JoinBuilder<Entity>(this.qb, this.filtersExpression);
    jb.build();

    const wb = new WhereBuilder<Entity>(this.qb, this.filtersExpression);
    wb.build();

    return this.qb;
  }
}

JoinBuilder recursively traverses the FiltersExpression and adds a LEFT JOIN for each relationField.

JoinBuilder.ts



import {forEach} from 'lodash';
import {SelectQueryBuilder} from 'typeorm/query-builder/SelectQueryBuilder';

class JoinBuilder<Entity> {
  private joinedEntities = new Set<string>();

  constructor(private readonly qb: SelectQueryBuilder<Entity>,
              private filtersExpression?: FiltersExpression) {
  };

  build() {
    if (this.filtersExpression)
      this.buildJoinEntitiesRec(this.filtersExpression);
  }

  private buildJoinEntitiesRec(fe: FiltersExpression) {
    forEach(fe.filters, f => this.addJoinEntity(f.field, f.relationField));
    forEach(fe.childExpressions, child => this.buildJoinEntitiesRec(child));
  }

  private addJoinEntity(field: string, relationField?: string) {
    const entityName = field.split('.')[0];

    if (relationField && !this.joinedEntities.has(entityName)) {
      this.qb.leftJoinAndSelect(relationField, entityName);
      this.joinedEntities.add(entityName);
    }
  }
}

WhereBuilder recursively goes over the filters expression tree and builds the WHERE clause of the SQL query.

WhereBuilder.ts



import { isEmpty, map } from 'lodash';
import {SelectQueryBuilder} from 'typeorm/query-builder/SelectQueryBuilder';

type ParamValue = string | number | Array<string|number>;


export default class WhereBuilder<Entity> {
  private params: Record<string, ParamValue> = {};
  private paramsCount = 0;

  constructor(private readonly qb: SelectQueryBuilder<Entity>,
              private filtersExpression?: FiltersExpression) {
  };

  build() {
    if (!this.filtersExpression)
      return;

    const whereSql = this.buildExpressionRec(this.filtersExpression);
    this.qb.where(whereSql, this.params);
  }

  private buildExpressionRec(fe: FiltersExpression): string {
    const filters = map(fe.filters, f => this.buildFilter(f));
    const children = map(fe.childExpressions, child => this.buildExpressionRec(child));

    const allSqlBlocks = [...filters, ...children];
    const sqLExpr = allSqlBlocks.join(` ${fe.operator} `);
    return isEmpty(sqLExpr) ? '' : `(${sqLExpr})`;
  }

  private buildFilter(filter: Filter): string {
    const paramName = `${filter.field}_${++this.paramsCount}`;

    switch (filter.op) {
      case 'EQ':
        this.params[paramName] = filter.values[0];
        return `${filter.field} = :${paramName}`;
      case 'IN':
        this.params[paramName] = filter.values;
        return `${filter.field} IN (:${paramName})`;
      case 'LIKE':
        this.params[paramName] = `%${filter.values[0]}%`;
        return `${filter.field} LIKE :${paramName}`;
      case 'GE':
        this.params[paramName] = filter.values[0];
        return `${filter.field} >= :${paramName}`;
      default:
        throw new Error(`Unknown filter operation: ${filter.op}`);
    }
  }
}

Finally, this is the SQL query that was built by FilterQueryBuilder for our example:



SELECT *
FROM Orders o, 
LEFT JOIN Customers c ON o.customer_id = c.id
WHERE (o.quantity >= 20) AND (o.product LIKE '%books%')
      AND 
      (
        (o.order_date >= '2016-08-27') OR 
        (c.id IN (11, 12)) OR 
        (c.postal_code LIKE '%5NT%')
      )

Conclusion

This kind of GraphQL API offers great flexibility and control for client applications. All this while keeping the type safety and run-time validation that we get out-of-the-box from GraphQL.
With different combinations of rules to filter your data, you can exactly express the data you are interested in and let the backend to fetch it for you.

In a similar way we can also add sorting and pagination to our query enhancing it even more.