DEV Community: Ulad Ramanovich

Spec-Driven Development: The Key to Aligning Team and Improving Code Quality

Ulad Ramanovich — Sat, 07 Sep 2024 12:53:33 +0000

Introduction

In the fast-paced world of software development, teams are constantly striving to deliver high-quality features and products to their users. However, with pressure to move quickly and deadlines it's easy to overlook a better solution, and under the pressure usual “hacks” and “fast solutions” appear in the codebase. Many developers are eager to jump straight into implementation, believe that investigations are not required and team can understand and discuss everything during the Code Review process.

Imagine this scenario: a developer has a great idea of how to implement a new feature and immediately starts coding, without discussing the details with the rest of the team. Days later, after presenting their work during a code review or showing the final result to the team lead after a week of development, they discover that it doesn't align with the project's goals, conflicts with other features, or requires significant rework due to architectural limitations.

In this article, we’ll explore how to address this problem and why technical specs are essential for effective collaboration. We’ll discuss the benefits of technical specs for the team, communication, and the success of your software projects.

The Role of Technical Specs

A technical specification, also known as a technical spec or spec document or tech spec, is a detailed description of the requirements, design, implementation, and testing plans for a software feature or system.

They serve as a detailed description of the feature plan and ensure all stockholders have a clear and shared understanding of the project's goals, requirements, and approach.

Technical spec is a communication tool. This is the place where you can bring all your ideas, and spend some time on feature investigation and how to integrate it into the current software. A place to discuss with your team or cross-team discussions. Also, clearly defining the problem being solved, the proposed solution, and the implementation details and technical specs help to align the team and prevent misunderstandings or miscommunications that can lead to wasted time and effort.

Tech specs are not only about communication, and also they also bring important functions in the development process:

Validation - the opportunity to discuss and validate your idea with stockholders. This validation could include not only technical side, but the project can also validate requirements and implementation plan.
Planning - after investigation and clearly describing and agreeing on implementation it’s much easier to get an estimation rather than try to guess. It breaks down the work into manageable tasks with a description of the development scope and milestones.
Collaboration - it’s a good place to collaborate among team members. By providing shared understanding you simplify of the feature process of Code Review.
Documentation - technical specs serve as a form of documentation where you describe technical aspects where developers can learn about the project. They provide a historical record of the project's evolution, allowing new team members to quickly get up to speed and enabling the team to refer back to earlier decisions or rationale when needed.

In short, technical specs are an essential tool for managing complex software development projects. They provide structured, validated, plan and document the work being done.

However, despite their importance, many teams struggle with creating and maintaining effective technical specs. In the next section, we'll explore some of the common challenges that popup when developing features without the guidance of a well-crafted technical spec.

Challenges of Developing Features Without Technical Specs

“When we expect the feature in production?”, “Why do you implement this abstraction, when we already have the library/class that solves the problem?”, “Why this project takes 2 weeks????”, “This project does not align with the company's technical strategy, who developed it this way and why?”. This is an example of questions that many of the software developers hear and not once. Every time when a feature doesn’t have a Technical Specification discussed and aligned there is a big risk to face with these questions one more time and start describing a long unstructured summary of the project answering these questions.
When development starts in a hurry without a clear vision and understanding, many developers go directly to the development process, because they think there is no time for the Tech Spec. However, this approach often leads to a variety of challenges and problems that can hinder the success of the project:

Miscommunication and misalignment - without a clear and comprehensive technical spec, team members may have different understandings of what needs to be built and how it should be implemented. This could lead to confusion and even arguing about implementation when it already done.
Scope creep and feature bloat - over-engineering leads to bloated, difficult-to-maintain code. This can also result in delays and budget overruns as the expanding scope.
Quality issues - without a clear development plan it becomes hard to specify testing requirements and the feature goal. It can be challenging to determine whether a feature is working as intended or meeting the original goals.
Difficulty in collaboration and code review - technical specs provide a common reference point for team members to discuss and review code changes. Without sharing understanding code reviews can become more time-consuming and takes days, or even weeks.
Lack source of true - it critical to have one place where team can find all information about the projects, all links, design, related features.
Technical debt and maintenance challenges - without a clear understanding of the original design and rationale, future developers may struggle to modify or extend the code, leading to further complexity and fragility.

These challenges underscore the importance of investing time and effort into creating Tech specs before starting the development process.

In the next section, we'll explore how technical specs can help teams overcome these challenges and build better software.

Benefits of Sharing Technical Specs Before Writing Code

Preparing and Sharing Technical Specs before development offers numerous benefits:

Validation of ideas and solutions - presenting all your ideas in a structure way can gather feedback and insights from your team.
Alignment with project goals and system architecture - tech Specs ensure that the proposed feature aligns overall with the system in the way it should be implemented.
Identification of dependencies and potential roadblocks - discussing technical solutions and investigation needed for the Technical Spec required deep analysis of the system and how new features can be integrated. It’s a good way to spot dependencies and potential blockers which you can add to the spec.
Collaboration and knowledge sharing - sharing technical strategy could be a good knowledge sharing session, or become an education session where you can show Junior developers which factors you are using during technical decisions. It provides an opportunity for developers to learn from each other, share best practices, and leverage the collective knowledge of the team.
Efficient allocation of resources - by breaking down the work into smaller, well-defined tasks, developers can better assess the time and resources needed. With better estimation, it becomes more clear when a project can be finished and the potential risks.
Improved documentation and knowledge transfer - when developers go on vacation it could be a challenge to fix and navigate inside the problem from not your code. By sharing the spec with the team, everyone has access to a single source of truth that captures the key decisions and all important points of the feature.
Enhanced communication with non-technical stakeholders - for Product Manager, clients or Team lead could benefit from presenting the spec in a clear and accessible format. Developers can help these stakeholders understand the technical aspects of the project and how it aligns with business goals.

In the next part, I’ll share the key aspects of creating Effective Technical Specs.

How to Create Effective Technical Specs

Technical specs could include several parts and depends on your role and company. Try to use one template for all Technical spec as it is easier to navigate and everybody knows where to find parts they are interested in.

The main parts of all technical spaces remain the same:

Glossary (optional) - you can explain some topic related words and abbreviations.
Goal - the project goal, could be the product goal of this project.
Included in this iteration - describe the main point you want to introduce with this tech spec.
Not included in this iteration - something that our of scope or part that will be done in the next iteration.
Timeline - here is the estimation project part. It could start with the project milestones and after you can put the timeline of your feature. Include in this timeline all side events that could effect this project like on-call duties, vacations, other projects if needed. After the project you can use this timeline for analytics on how went the project if it missed the deadline or something went wrong.
Monitoring - this section depends on your position. For Backend developers, it is worth putting in a monitoring strategy. For Frontend it could be Sentry and describe how you can find this error. It could be Sentry tags.
Analytics (optional) - the Analytics section is marked as optional but highly recommended. It’s a good place to answer the question “How we can track the success/usage of this feature?”. It could be Google analytics events or more specific metrics.
Cross team dependencies - describe on which team this project depends.
Technical Strategy - description of how to achieve the project goal with technical tools.
- Technical part is more essay rather than something really structured because that could include database schema, events or frontend description on how to divide design into components.
- Using visualisation could help to understand you’re idea. People are meant to understand easier pictures than words. Check Mermeid visualizations tool.
- Add more code examples where you can discuss the solution with the team. If you want to add migration, there is a good opportunity to add SQL code for this migration.
- Create subcategory. You can divide technical strategy into smaller features and describe each of them.
Public endpoint changes (optional) - the section describing if your public API can change and how
Instructions - as a last section it’s good to add a checklist of what to do before publishing this Technical spec and where and after.

When you prepare the template now I'll try to share some insights on how to implement this process in your team.

Implementing a Technical Spec-Driven Development Process

The idea of using Technical Specs could be scary firstly. It’s good If only one team uses Technical Specs, but for more efficient processes it is better to encourage to use Technical Specs by all teams.

Creating effective technical specs is only half the battle. To truly reap the benefits of a spec-driven development process, you need to ensure that specs are consistently used, maintained, and integrated into your team's workflow.

Here are a few suggestions on how to do this:

Make specs a required part of the development process - establish a clear development policy where Technical Specification is required for all projects.
Create task for Technical Spec and track them as a normal task - for clear communication with management, it is better to allocate some time for working on Technical Spec. To do it transparently it is better to create tasks for investigating and documenting a solution.
Continuously update and refine specs - remember to update your spec if something Changes during the development process.
Use specs as a tool for knowledge sharing - instead of describing the feature and why you did this, try to share the Tech Spec. Use it for onboarding new developers in your project.

By implementing these strategies and making technical specs a core part of your development process, you can ensure that your team is consistently producing high-quality software that meets the needs of your stakeholders. Spec-driven development may require an initial investment of time and effort, but the long-term benefits - in terms of improved communication, collaboration, and code quality - are well worth it.

Conclusion

In today's fast-paced software development, it's easy to feel pressure to jump straight into coding and skip the critical step of writing technical specs. However, as we've seen throughout this article, taking the time to create clear, comprehensive specs can pay enormous dividends in terms of improved communication, collaboration, and code quality.

Ultimately, the goal of technical specs is not to create more paperwork or bureaucracy, but to enable teams to build better software, faster, and with fewer headaches along the way. By embracing a spec-driven approach, teams can unlock new levels of efficiency, quality, and collaboration, and set themselves up for long-term success.

So if you're not already using technical specs in your development process, now is the time to start. Begin by having a conversation with your team about the benefits and challenges of spec-driven development, and work together to define a process that makes sense for your unique context and goals. It may take some trial and error, but with persistence and iteration, you can make technical specs a key driver of your team's success.

Fullstack Development: Learning Python as JavaScript Developers

Ulad Ramanovich — Fri, 30 Aug 2024 13:42:28 +0000

The Journey Begins

I have been working as a frontend developer for more than 8 years, and in the last 2 years, I decided to rethink my career and how I can grow. I found that frontend technology changes frequently: different frameworks, concepts, and the gap between React class components and hooks. I realized that all of this is just abstraction used to express business needs and personal vision. From this point, I decided to change my career path and become a full-stack developer slightly.

As we all know, frontend development is all about JavaScript nowadays, which is why I decided to learn Node.js and its main frameworks. All frontend developers encounter Node.js in one way or another, and as a Senior Frontend Developer, you should be able to write basic endpoints in Node.js with Express or another library. After 2 years of active development on the Node.js side, when my job became 50/50 between frontend and backend, I discovered that most projects don’t limit themselves to just one language.

Node.js is not the ideal tool for everything, especially when you’re working in a larger company. Different languages provide different solutions or are more optimal for solving specific business cases. This is why I started researching what I could learn as my second backend language and how I could utilize it in the future.

I want to share my experience and why I decided to stick with Python after trying to learn Rust (mostly not for web development), Swift (which is primarily a mobile-first solution), and Golang. Here, you’ll find out why I believe Python is a great opportunity for frontend developers to learn and how to start using it.

Why Python?

Nowadays, AI is something that everyone is talking about. Mentioning it in an interview as part of your experience always gives you extra points. Almost all companies are trying to incorporate AI into their products, and Python goes hand in hand with AI and Machine Learning. By learning Python, you not only gain the opportunity to write web applications with frameworks like Django, Flask, and FastAPI, but you can also start working with Machine Learning and AI services.
On one hand, learning more complex languages like Rust, Go, or Elixir is a good idea if you want to become a better programmer. However, from a career perspective, it's not an easy transition to becoming a backend developer with a completely different language that you're less familiar with.

Python is a dynamically typed programming language. As a JavaScript developer who has spent a significant part of your career in a similar environment, this shouldn't intimidate you, as you already know what kinds of issues to expect in the code.
With Python, you can not only start writing web applications but also leverage your skills in AI-related fields, which gives Python a significant advantage as a second language.

The Learning Curve

The learning curve was straightforward. In Python, you need to learn some basic concepts for sure. If you have experience with JavaScript it shouldn't be a big deal.

Here is the code example in Python:

import random

def guess_the_number():
    number_to_guess = random.randint(1, 100)
    attempts = 0
    guessed = False

    print("Welcome to the Number Guessing Game!")
    print("I'm thinking of a number between 1 and 100. Can you guess what it is?")

    while not guessed:
        user_guess = int(input("Enter your guess: "))
        attempts += 1

        if user_guess < number_to_guess:
            print("Too low! Try again.")
        elif user_guess > number_to_guess:
            print("Too high! Try again.")
        else:
            print(f"Congratulations! You guessed the number {number_to_guess} in {attempts} attempts.")
            guessed = True

guess_the_number()

I don’t think you’ll find anything too complex here. Even if you haven’t learned Python before, you can understand almost all the lines without reading the documentation.

The biggest difference you’ll notice is that Python uses indentation to define code blocks instead of curly braces. That might seem strange, and I still find it a bit unusual, but after a while, you get used to it, and reading code becomes easier.

Apart from that, many concepts in Python are similar to those in JavaScript. Instead of console.log, you can use print, and for string interpolation, you can add f at the beginning of the string and use almost the same syntax as in JavaScript.

Here is the JavaScript version of the code above:

function guessTheNumber() {
    const numberToGuess = Math.floor(Math.random() * 100) + 1;
    let attempts = 0;
    let guessed = false;

    console.log("Welcome to the Number Guessing Game!");
    console.log("I'm thinking of a number between 1 and 100. Can you guess what it is?");

    while (!guessed) {
        const userGuess = parseInt(prompt("Enter your guess: "), 10);
        attempts++;

        if (userGuess < numberToGuess) {
            console.log("Too low! Try again.");
        } else if (userGuess > numberToGuess) {
            console.log("Too high! Try again.");
        } else {
            console.log(`Congratulations! You guessed the number ${numberToGuess} in ${attempts} attempts.`);
            guessed = true;
        }
    }
}

guessTheNumber();

Overcoming Obstacles: Key Concepts

You can learn a lot of different concepts in Python. I showed the most confusing for me as a JavaScript developer.

Indentation-Based Syntax

As a JavaScript developer, you might be familiar with how to use code blocks with if/else and other operators. In most of the cases you just add {} and that’s it. Python's indentation-based system can be tricky.

Let’s see the JavaScript code:

if (role === "admin") {
    const posts = getDraftPosts()

    if (posts.length === 0) {
        throw NotFound()
    }   

    return posts
}

Python analog:

if role == "admin":
    posts = get_draft_posts()

    if posts.length == 0:
        raise NotFound()

    return posts

As you can see readability of blocks in Python could be challenging from the first view. This is why for me it was important to avoid deeply nested blocks because it is hard to read and easy to miss correct indention. Keep in mind that Python could attach your code to a wrong code block because of missed indention.

Type system

Python is a dynamic typing language but I was surprised to find Python built-in Types annotation.

def add(x: int, y: int) -> int:
    return x + y

You don’t need to install additional features, only what you need in Python *3.5 and above.*

Even more complex types could be described as equal to Typescript:

# enums
from enum import Enum # import enum for built in lib

class Season(Enum): # extend class to mark it as enum
    SPRING = 1
    SUMMER = 2
    AUTUMN = 3
    WINTER = 4

print(Season.SPRING.name) # SPRING
print(Season.SPRING.value) # 1

# or generics
def first(container: List[T]) -> T:
    return container[0]

list_two: List[int] = [1, 2, 3]
print(first(list_two)) # 1

For using these types you are not required to install something or transpile this code. This is something I missed in JavaScript, at least Node.js. I know Node.js is adding some basic types in the nearest version (see Medium post about node.js built-in types support) but it looks poor now if you compare it with Python.

Python’s Global Interpreter Lock (GIL)

JavaScript uses an event-driven, non-blocking model, while Python's Global Interpreter Lock (GIL) can be a confusing concept in multi-threaded programs.
The Python Global Interpreter Lock (GIL) is a mechanism that ensures only one thread executes Python code at a time. Even if your Python program has multiple threads, only one thread can execute Python code at a time due to the GIL.
With JavaScript, you can achieve multithreading with web workers, but in Python, you need to use additional libraries to accomplish this.

A Pythonic Mindset

JavaScript's "multiple ways to do it" philosophy doesn't work as well in Python because Python adheres more closely to the concept "There should be one - and preferably only one - obvious way to do it."
In the JavaScript world, every company often creates its own code style guide, and it's fortunate if it follows basic JavaScript style recommendations. In reality, practices like using semicolons can vary widely, to the point where one project might use semicolons and another might not.
In Python, following Pythonic principles from PEP 8 (Python's style guide) is highly recommended. This guide outlines the basic rules of how to write Python code.
To write better code, it's essential to engage with the community and learn idiomatic Python practices that prioritize clarity and simplicity.

Managing Dependencies and Virtual Environments

This part might also be confusing. In JavaScript, you can usually add a package manager and start installing dependencies without any issues. However, Python’s pip and virtual environments may be new concepts.

In Python, when using additional dependencies, it’s highly recommended to use a separate virtual environment. Installing dependencies with pip (the Python equivalent of npm in JavaScript) in your environment could potentially break system utilities or the OS itself, as the system Python interpreter (the one that comes pre-installed with your operating system) is used by the OS and other system utilities.

As a solution, you can create a virtual environment with venv module:

python -m venv myenv
myenv\Scripts\activate # for windows
source myenv/bin/activate # for Mac

After you enter the virtual environment you can install all dependencies without any problem or danger for your root environment.

Finding Support and Resources

How I Learned Python

Learning a new language is always challenging. I started learning Python basics on an online platform, where I also completed some small projects. Here is the plan I used during my learning process:

Python basics.
Advanced Python concepts (module system, types, environment, async code).
Learning the basics of the most popular frameworks like Django, Flask, and FastAPI.
Writing my first API server with FastAPI.
Adding a database and learning how to work with databases in Python.
Deploying the application on a free hosting service.

Where to Find Help

You can find a lot of help in Reddit communities or Discord servers while learning. I’m mostly a Reddit user and would suggest finding subreddits for Python and the framework you decide to use for your first application.

Remember to use the official documentation. In my opinion, it looks overwhelming, and most of the time, I try to find related articles if I get stuck on a concept.

Make sure to read PEP 8 — Style Guide for Python Code, where you can find basic rules on how to write Python code.

Looking Back and Forward

As I reflect on my journey from a JavaScript developer to embracing Python, I have no regrets. This transition has opened up exciting opportunities, particularly in the realms of AI and machine learning, which I now leverage extensively in my projects, especially on the backend.

Looking ahead, the possibilities with Python are vast. Whether it's web development, data science, automation, or delving deeper into AI and machine learning, Python provides a powerful and versatile foundation to build on and explore new horizons.

Mastering React Components with TypeScript Generics

Ulad Ramanovich — Fri, 23 Aug 2024 19:21:17 +0000

Typescript in react ecosystem

In recent years, TypeScript has become an essential part of the React ecosystem. Not too long ago, almost every package required an additional package just for type definitions, like @types/react-select, and those types were sometimes incorrect. In many projects, there were numerous if/else checks just to ensure a property existed before using it, to avoid errors like "Cannot read properties of undefined."

With TypeScript, it has become much easier to maintain large codebases with thousands of lines of code and to create more developer-friendly, reusable functions.

In this article, we’ll discuss one of the most underutilized yet powerful concepts in TypeScript — generics — specifically within the context of React. We’ll explore how you can apply generics in your code to build highly reusable and type-safe components.

What is generics in typescript

Generics in typescript, in simple words, are constructs that allow you to abstract type, making your code more reusable and extensible. Generics are particularly useful when you’re unsure of what specific type might be passed into your function. A common use case for generics is to enhance the reusability of functions.

The syntax for generics looks like this:

function print<Type>(data: Type) {
 console.log(data)
}

print<string>("Hello"); // This works fine because we're specifying 'string' as the type.
print<string>({ message: "Hello" }); // TypeScript error: expected a 'string'.

In this example, the Type generic can be anything, and we're not concerned with what the specific type is. The developer using this function can specify which type to use.

In the React ecosystem, generics are commonly used, though they may not always be visible. Generics are implemented in almost every library because libraries are designed to be reusable. For instance, when you call functions like axios.get(fetchUsers) or use lodash _.groupBy(users, 'role'), these functions are using generics under the hood.

But why don’t you always need to explicitly specify the generic type? This is an important TypeScript concept to understand before diving into React: TypeScript can often infer the type based on the context, which we’ll explore next.

Typescript types inferring magic

What if I told you that if you’re working with TypeScript and React, you’re already working with generics daily — even if you’re not aware of it? Consider hooks like useMemo or useCallback.

You might have a line like this in your code:

const aLotOfData = []; // imagine thousands of elements here

const memoizedHugeArray = useMemo(() => {
  return sortingOfHugeArray(aLotOfData);
}, [aLotOfData]);

memoizedHugeArray.length; // Works! TypeScript knows this is an array.

You might think that Typescript is smart enough to understand types just by reading your code, but in reality, even you can’t understand your own code after a while. So, how typescript can do this?

This concept in TypeScript is known as type inference. Type inference in TypeScript is a feature where the compiler automatically finds out the type of a variable or expression without you explicitly specifying it. In simple terms, TypeScript "compiles" part of your code and, using typeof and other constructs, can understand what type you have assigned.

Here’s a simple example:

let message = "Hello, TypeScript!"; // type of message is string

The same principle applies to generics. TypeScript can infer the type for generics automatically:

function print<Type>(data: Type) {
  console.log(data);
}

print("Hello"); // Works
print({ message: "Hello" }); // Also works

This brief introduction to type inference sets the stage for understanding how to use generics effectively in our React code.

Where to use generics in react

Imagine we have a task to create an Autosuggestion component where you can pass a list of agents or merchants and filter them by a specific property as you type in the input field. Here is UI example:

This might sound like a simple task, but with TypeScript, it becomes more challenging. Here are the types of agents and merchants:

type Agent = {
    firstName: string
    secondName: string
}

type Merchant = {
    companyName: string
    companyId: number
}

These are two different types that share a common trait: they are both objects. This is a perfect scenario where TypeScript and generics can help us solve the problem and create a single, reusable component.

Basic component

Let’s start with a basic annotation of our Autosuggestion component:

type Props = {

}
const Autosuggestion = ({}: Props) => {
    const [search, setSearch] = useState("")

    const onChange = (e) => {
        const newSearch = e.currentTarget.value

        setSearch(newSearch)
    }

    return (
        <div>
            <input value={search} onChange={onChange} />
        </div>
    )
}

At first glance, the code above might seem fine, but it won’t work correctly in TypeScript because TypeScript cannot infer the type of e in the onChange function. To properly annotate it, we need to use Generic from React SyntheticEvent (a React abstraction for most events in JSX) along with the predefined TypeScript type HTMLInputElement for input DOM elements. This tells TypeScript that we expect a "synthetic React event" for an "input element."

  const onChange = (e: SyntheticEvent<HTMLInputElement>) => {
    const newSearch = e.currentTarget.value;

    setSearch(newSearch);
  };

Adding list and more properties

As our next step let’s add a list with items. For now, we simplify the solution and pass an array of string for this component:

type Props = {
  items: string[];
};

export const Autosuggestion = ({ items }: Props) => {
  const [search, setSearch] = useState("");

  const onChange = (e: SyntheticEvent<HTMLInputElement>) => {
    const newSearch = e.currentTarget.value;

    setSearch(newSearch);
  };

  return (
    <div>
      <input value={search} onChange={onChange} />

      {items.length > 0 && (
        <ul>
          {items.map((item) => (
            <li>{item}</li>
          ))}
        </ul>
      )}
    </div>
  );
};

After this, we can add some basic search. As a first step, we need to copy the items list and filter it by text (and add toLocaleLowerCase for a better experience):

  const [filteredItems, setFilteredItems] = useState(items);

  const onChange = (e: SyntheticEvent<HTMLInputElement>) => {
    const newSearch = e.currentTarget.value;

    setSearch(newSearch);
    setFilteredItems(
      filteredItems.filter((item) =>
        item.toLocaleLowerCase().includes(newSearch.toLocaleLowerCase())
      )
    );
  };

Generics and arrow functions in react

Before we bring Generics to our code we should talk about one problem with generics. It’s not obvious how to use it with arrow function when you try first time.

export const Autosuggestion = <Item>({ items }: Props<Item>)  => {}

The code above doesn’t work in typescript because of a limitation in the use of <Item> for generic type parameter declarations combined with JSX grammar.

There are two ways to solve this issue:

// Extend from object or unknown
export const Autosuggestion = <Item extends Object>({ items }: Props<Item>) => {}

// Put comma after Generic and typescript can't understand that this is ts annotation and not JSX
export const Autosuggestion = <Item,>({ items }: Props<Item>) => {}

I prefer the second solution as it is easier to understand. However, you can use any option that fits your case.

Made component reusable with Generics

With our knowledge of Generics let’s make this component more reusable:

// First pass generics to your type
type Props<Item> = {
  items: Item[];
};

export const Autosuggestion = <Item,>({ items }: Props<Item>) => {
     // Remember type infering? This is why you don't need to change anything here
    const [filteredItems, setFilteredItems] = useState(items);
}

After this, we should decide our filtering strategy for items in the component. There are plenty of different solutions but let's say we want to pass the filter function and render function to make this component more reusable and utilize more power of Generics.

type Props<Item> = {
  items: Item[];
  filterFn: (item: Item, search: string) => Boolean;
};

export const Autosuggestion = <Item,>({ items, filterFn }: Props<Item>) => {
  const onChange = (e: SyntheticEvent<HTMLInputElement>) => {
    const newSearch = e.currentTarget.value;

    setSearch(newSearch);
    setFilteredItems(filteredItems.filter((item) => filterFn(item, search)));
  };
}

After this, we want to display the result. As we don’t know the type of the item in advance we can move this logic to the parent too. In React this is a common pattern named “render item” when the parent provides the function of how to render a specific item. Here is the implementation:

type Props<Item> = {
  items: Item[];
  filterFn: (item: Item, search: string) => Boolean;
  renderItem: (item: Item) => ReactNode;
};

export const Autosuggestion = <Item,>({ items, renderItem }: Props<Item>) => {
    const [filteredItems, setFilteredItems] = useState(items);

    return (
      {filteredItems.length > 0 && (
        <ul>
          {filteredItems.map((item) => (
            <li>{renderItem(item)}</li>
          ))}
        </ul>
      )}
    )
}

Finalise the component

Let's put everything together:

type Props<Item> = {
  items: Item[];
  filterFn: (item: Item, search: string) => Boolean;
  renderItem: (item: Item) => ReactNode;
};

export const Autosuggestion = <Item,>({
  items,
  filterFn,
  renderItem,
}: Props<Item>) => {
  const [search, setSearch] = useState("");
  const [filteredItems, setFilteredItems] = useState(items);

  const onChange = (e: SyntheticEvent<HTMLInputElement>) => {
    const newSearch = e.currentTarget.value;

    setSearch(newSearch);
    setFilteredItems(filteredItems.filter((item) => filterFn(item, search)));
  };

  return (
    <div>
      <input value={search} onChange={onChange} />

      {filteredItems.length > 0 && (
        <ul>
          {filteredItems.map((item) => (
            <li>{renderItem(item)}</li>
          ))}
        </ul>
      )}
    </div>
  );
};

And example of usage:

type Agent = {
  firstName: string;
  lastName: string;
};

const agents: Agent[] = [
  {
    firstName: "Ethan",
    lastName: "Collins",
  },
  {
    firstName: "Sophia",
    lastName: "Ramirez",
  },
  {
    firstName: "Liam",
    lastName: "Carter",
  },
];

export default function App() {
    return (
        <div className="App">
          <Autosuggestion
            items={agents}
            filterFn={(agent, search) => agent.firstName.includes(search)}
            renderItem={(agent) => (
              <div>
                {agent.firstName} {agent.lastName}
              </div>
            )}
          />
        </div>
    );
}

If you mentioned we didn't provided any Generics itself. Typescript infer all types just for us by the matching items={agents} with type Props<Item> = { items: Item[]; } and add corresponding types for filterFn and renderItem. This is where true power of Generics.

As you can see component itself reusable and could be extended with various of functionality.

Full code you can find in the Sandbox.

Conclusion

In this article, we’ve explored the power of TypeScript generics, what is type inferring in Typescript, and how this is connected with Generics and build our reusable component based on generics.

We’ve seen how TypeScript’s type inference works hand-in-hand with generics to automatically determine types, making your code more robust without the need for excessive type annotations. Whether you’re building simple utilities or complex UI components, generics offer a way to ensure your code is both scalable and easy to understand.

Mastering React Query. Simplifying Data Management in React with Separation Patterns

Ulad Ramanovich — Fri, 16 Aug 2024 13:07:10 +0000

Using React Query to Sync with the Server

In most frontend applications, React Query acts as a bridge between the server and the frontend. With it, you can not only read data but also mutate server data. The more we use React Query, the more we should think about abstraction for the simplification and encapsulation of code.

A few years ago, with Redux, we stored most of the business logic for fetching data at the reducer level, which provided a good abstraction layer where we could separate application business logic from components. However, with React Query, components started to grow with logic about how and when to fetch data, what to do when updating server state, and so on. This has reintroduced the problem of encapsulation and simplification.

This article describes methods for returning your components to a clearer state and how to manage fetching logic, specifically discussing how we can use the "Common Query Separation" and "Separation of Concerns" patterns with React.

Custom Hooks as a New Layer for Abstracting Logic

Custom hooks were introduced in React as a solution for abstracting logic from functional components. They allow you to move part of the state management or business logic into reusable hooks. However, without a clear purpose, creating many custom hooks can complicate the project. On the other hand, the wise use of custom hooks can bring significant benefits to your codebase.

In React, the difference between a custom hook and a regular function lies in the use of React hooks like useState, useEffect, etc. Simply put, custom hooks leverage React's lifecycle methods, whereas regular functions do not.

export const useFetchUsers = () => {
  const [users, setUsers] = useState([]);
  const [isLoading, setIsLoading] = useState(true);
  const [error, setError] = useState(null);

  useEffect(() => {
    // Function to fetch users from the API
    const fetchUsers = async () => {
      try {
        const response = await axios.get('https://jsonplaceholder.typicode.com/users');
        setUsers(response.data);
        setIsLoading(false);
      } catch (err) {
        setError(err);
        setIsLoading(false);
      }
    };

    fetchUsers();
  }, []);

  return { users, isLoading, error };
};

This is why we can start treating custom hooks as functions and think about how to abstract logic into them, just as we do with classes or regular functions.

Why to store React Query in custom hooks and Separation of Concerns

React Query hooks provide extensive functionality and can replace the example below with just a few lines of code:

export const useUsersQuery = () => {
  return useQuery(
      queryKey: usersQueryKeys.list(),
      queryFn: fetchUsers
  );
};

If you're interested in creating queries and making them more reusable, you can find more details in my article Mastering React Query. Structuring Your Code for Scalability and Reusability

In reality, working with React Query often requires additional logic after fetching data. For example:

Nested queries: where one query depends on another.
Data transformation.
Validation of data from the server.
Refetching data when something changes (like filter changes).

Of course, you could store all this logic within the component where you call the React Query hook, but this approach often leads to components with a lot of complex logic, making them difficult to follow and reducing reusability.

Let's see an example of a component using React Query without custom hooks:

const UsersComponent = () => {
  const { data: users, error, isLoading } = useQuery(['users'], fetchUsers, {
    staleTime: 30000,  // Cache data for 30 seconds
    refetchOnWindowFocus: false, // Disable refetch on window focus
  });

  // Data transformation
  const activeUsers = users?.filter(user => user.isActive);

  if (isLoading) return <p>Loading...</p>;
  if (error) return <p>Error loading users: {error.message}</p>;

  return (
    <ul>
      {activeUsers.map(user => (
        <li key={user.id}>
          {user.name} ({user.email})
        </li>
      ))}
    </ul>
  );
};

At first glance, this code looks fine, but in a complex project, the logic in this component can grow quickly, making it harder to follow and reducing reusability.

Now, let's look at this example with custom hook abstraction:

const useFetchActiveUsers = () => {
  const query = useQuery(['users'], fetchUsers, {
    staleTime: 30000,  // Cache data for 30 seconds
    refetchOnWindowFocus: false, // Disable refetch on window focus
  });

  // Additional logic: filtering active users
  const activeUsers = query.data?.filter(user => user.isActive);

  return { ...query, data: activeUsers };
};

const UsersComponent = () => {
  const { data: activeUsers, error, isLoading } = useActiveUsersQuery();

  if (isLoading) return <p>Loading...</p>;
  if (error) return <p>Error loading users: {error.message}</p>;

  return (
    <ul>
      {activeUsers.map(user => (
        <li key={user.id}>
          {user.name} ({user.email})
        </li>
      ))}
    </ul>
  );
};

We applied the "Separation of Concerns" or "Single Responsibility Principle" pattern, where we moved all fetching logic outside of the UI component. Now, the component is focused solely on rendering the UI.

React Query and the Common Query Separation Pattern

When working with an API and React Query, there are two main hooks: useQuery and useMutation. The useQuery hook fetches data and uses caching to optimize fetching logic. The useMutation hook is primarily for data mutation. These hooks work differently, and the separation of these hooks is intentional.

In real-world codebases, when abstracting React Query, it's common to have one hook where both fetching and mutating data happen:


export const useUser = (userId) => {
  const queryClient = useQueryClient();

  // Fetch all users
  const usersQuery = useQuery(['users'], fetchUsers, {
    staleTime: 30000,  // Cache data for 30 seconds
    refetchOnWindowFocus: false, // Disable refetch on window focus
  });

  // Fetch a single user by ID (optional)
  const userQuery = useQuery(['user', userId], () => fetchUserById(userId), {
    enabled: !!userId, // Only run this query if a userId is provided
  });

  // Mutation for updating user data
  const mutation = useMutation(updateUser, {
    onSuccess: () => {
      // Invalidate and refetch users data after a successful update
      queryClient.invalidateQueries(['users']);
      if (userId) {
        queryClient.invalidateQueries(['user', userId]);
      }
    },
  });

  // Function to update a user
  const updateUserDetails = (userId, updatedData) => {
    mutation.mutate({ userId, updatedData });
  };

  return {
    users: usersQuery.data,
    isLoadingUsers: usersQuery.isLoading,
    isErrorUsers: usersQuery.isError,
    user: userQuery.data,
    isLoadingUser: userQuery.isLoading,
    isErrorUser: userQuery.isError,
    updateUserDetails,
    isUpdating: mutation.isLoading,
    updateError: mutation.isError,
  };
};

At first glance, there is nothing wrong with this hook, but "updating" data often requires more logic, such as preparing data for the server, handling specific errors like validation, etc.

One pattern we can apply here is "Common Query Separation," which is commonly used on the backend side.

Command Query Separation (CQS) is a design principle used in software development, particularly in object-oriented programming, that distinguishes between methods that perform actions (commands) and methods that return data (queries).

The main principle here is separating get logic from mutation (or commands in the original context). In React, we don't directly mutate API data, but with React Query, we handle this separation using the useQuery and useMutation hooks.

After applying this pattern, we can divide the useUser hook into two separate hooks:

const useUserQuery = (userId) => {
  // Fetch a single user by ID (optional)
  const {data: user, isLoading, isError} = useQuery(['user', userId], () => fetchUserById(userId), {
    enabled: !!userId, // Only run this query if a userId is provided
  });

  return {
    user,
    isLoading,
    isError,
  };
};

const useUserMutation = () => {
  const queryClient = useQueryClient();

  // Mutation for updating user data
  const mutation = useMutation(updateUser, {
    onSuccess: (_, { userId }) => {
      // Invalidate and refetch users data after a successful update
      queryClient.invalidateQueries(['users']);
      if (userId) {
        queryClient.invalidateQueries(['user', userId]);
      }
    },
  });

  return {
    updateUserDetails: mutation.mutate,
    isUpdating: mutation.isLoading,
    isError: mutation.isError,
  };
};

This separation bring us benefits like:

Modularity: Each hook is focused on a single responsibility, making the logic easier to manage and test.
Reusability: You can reuse useUserQuery and useUserMutation independently in other parts of your application.
Scalability: As your application grows, separating concerns helps in maintaining and scaling the codebase efficiently.

For showing other developers what this hooks doing it's better to add postfix with description what this hook doing. It could be Query and Mutation or more related postfixes to your codebase.

Conclusion

Developers could face the problem of complex components where mix of the different logic and rendering UI is not a biggest part of it. By leveraging patterns like Separation of Concerns and Common Query Separation, you can create a clean and modular architecture that keeps your components focused on rendering the UI while delegating data-fetching and mutation logic to custom hooks.

Incorporating these principles into your React development workflow will help you manage the complexity of state and server synchronization effectively, ensuring your application remains easy to understand and extend as it evolves.

Mastering React Query. Structuring Your Code for Scalability and Reusability

Ulad Ramanovich — Fri, 09 Aug 2024 11:30:36 +0000

Understanding React Query: The Basics and Benefits of Using It

React Query is a library that helps you manage your requests with caching. It simplifies how you can fetch data from the server and store it on the client side without needing additional state management tools like useState or redux.

const {data} = useQuery({
    queryKey: ['posts'],
    queryFn: () => {
        return getPosts()
    }
})

React Query is excellent for both fetching and mutating data. By mutating most of the time we mean doing “non-GET” requests to update, delete, or create new entities. With useMutation, you can also simplify the logic for handling these types of requests.

const {mutate} = useMutation({
    mutationFn: updatePost,
})

const onSubmit = (post) => {
    mutate(post)
}

When your project starts to grow and more developers begin reusing the same queries in different parts of the app, you may encounter typical issues common to most growing projects.

In every project I've seen, the same typical problems with React Query. often due to a luck of experience of because we tend to skip reading the full documentation. In this article, I'll discuss advanced React Query techniques based on my personal experience and share how you can create more efficient code with React Query.

Typical structure of react query usage

When you start work with react query it always two basic things:

Query keys
Query function

const {data} = useQuery({
    queryKey: ['posts'], // query key for query identification
    queryFn: () => { // query function for calling the API
        return fetchPosts()
    }
})

Let’s talk about both of this important aspects and why we need to care about them more.

Query Keys

Query keys allow us to identify and store queries in the cache, making it crucial to structure your query keys thoughtfully to avoid unnecessary calls.

Another important use of keys is for cache invalidation. For example, if you have a list of articles on your blog and you add or modify a blog post, you’ll want to update all articles across all relevant queries.

Query function

This is part of the logic where we put our fetching logic. The query function also can decide when to throw an error in query if you have additional cases:

const getPosts = async () => {
    const response = await fetch('/api/posts')

    if (response.status !== 200) {
        throw new Error(response.error)
    }

    const data = await response.json()

    return data
}

This means your query function can include logic and be reused between different useQuery calls.

Storing react query keys

In the documentation, you’ll find many examples where query keys are declared directly inside the useQuery hook. This approach can lead to several problems when you need to reuse the same key in different places.

The first think you can do is build a query keys factory for each entity:

const postsQueryKeys = {
    all: ['posts'],
    detail: (postId) => [...postsQueryKeys.all, 'detail', postId],
    list: (filters) => [...postsQueryKeys.all, 'list', {filters}]
}

Every request should start with entity name, followed by what you want to fetch from this entity ("detail" or "list" in example). Now, imagine you have two different hooks with different parameters for this query:

const { data: publishedPosts } = useQuery({
  queryKey: postsQueryKeys.list({ limit: 10 }),
  queryFn: fetchPosts({ limit: 10 }),
});

const { data: unpublishedPosts } = useQuery({
  queryKey: postsQueryKeys.list({ limit: 5, favourites: true }),
  queryFn: () => fetchPosts({ limit: 5, favourites: true }),
});

At first, this might seem like over-engineering, but when it comes to reusing your queries in different parts of your application, it becomes clear why this is an important step to optimize your codebase when working with React Query. You can store all query key factories in a file named query-keys.

One common use case for query keys factory when you need to call useMutation and than invalidate all queries with the specific keys:

const queryClient = useQueryClient()

const {mutation} = useMutation({
    queryFn: updatePost,
    onSuccess: (post) => {
        queryClient.invalidateQueries({ queryKey: postsQueryKeys.detail(post.id) })
    }
})

Abstract for query function

When query keys could be used as part of the query factory let’s think how we can abstract query functions and why we need to do so.

If you take a look on example above you can see the we don’t abstract the logic of query functions and put them in the useQeury . The good practice here is also abstract all of the query functions as a separate functions. You can name them as resources .

const getPosts = async () => {
    const response = await fetch('/api/posts')

    if (response.status !== 200) {
        throw new Error(response.error)
    }

    const data = await response.json()
    const posts = data.posts

    return posts
}

Now you can reuse resources in the different queries and test them separately from react-query logic.

Put all things together

Now that you have your query keys and functions set up for React Query, let's talk about how to organize and put everything together.

First and foremost is naming. I usually create an additional file named queries where I combine query keys with query functions to create reusable hooks.

For example:

import { useQuery } from 'react-query';
import { postsQueryKeys } from './query-keys';
import { fetchPosts } from './api';

export const usePostsQuery = (filters) => {
  return useQuery({
    queryKey: postsQueryKeys.list(filters),
    queryFn: () => fetchPosts(filters),
  });
};

When naming reusable hooks, it's important to provide context for developers who may reuse them. It's a good practice to follow React Query's naming conventions by adding a query or mutation postfix. For example, usePostsQuery or usePostsMutation. This way, you can easily identify what the hook does, as the behavior of useQuery and useMutation is different.

Here’s an example:

// api.js
export const fetchPosts = async (filters) => {
  // Fetch logic for posts
};

// Another file where you use the custom hook
const { data: posts } = usePostsQuery({ published: true });

By using descriptive names and consistent naming conventions, your code becomes more intuitive and easier to navigate, making it clear whether a hook is responsible for querying or mutating data.

Conclusion

Of course, if your project is small and doesn't require a lot of reusability between queries, you don't need to apply all of these suggestions. However, it's important to consider these practices before integrating React Query into a project where multiple developers will be working on it. By following these standards, you can avoid issues like double-fetching the same data and inconsistencies across different pages of your application.

Creating Autoresizeble textarea with hidden input technique

Ulad Ramanovich — Sat, 14 Oct 2023 10:56:49 +0000

The unusual HTML input behaviour

In the modern UI a lot of time you can see unusual HTML input behaviour. One of these unusual behaviour is autoresize. By autoresize I mean changing the input height while the user typing. In this article let’s talk about creating autoresizable textarea in React.

There is a few different way ho you can achieve this:

You can use <div contenteditable="true"> and manipulate with the editable div input. This is not the usual approach and can be done for very specific cases (you can see it for example in almost all online regexp editors when they highlight text inside input). It requires replication full input behaviour because div works completely differently.
You can change input height while the user typing. This can simplest way to implement expected results but this approach is not the best if you want to handle more cases.
You can create one more hidden input. Hide it and do all calculations with this “hidden” input and just apply the expected height on the “visible” input. This is a good approach from my perspective as with this approach you can handle a lot of cases.

Let’s talk more about the “hidden input” approach and try to create an autoresize textarea.

Let's create our own resizeable textarea

For this project, I use typescript + react + emotion css. You can replicate this code without any problem with any framework or plain css + js.

Let's start with the creation of 2 textareas and add ref as we need it in the feature.

const Textarea = (props: InputHTMLAttributes<HTMLTextAreaElement>) => {
    const innerTextAreaRef = useRef<HTMLTextAreaElement>(null);
    const shadowTextAreaRef = useRef<HTMLTextAreaElement>(null);

    reutrn (
        <textarea {...props} ref={innerTextAreaRef} />
        {/* We use only neccecery fields to our shadow input */}
        <textarea
            ref={shadowTextAreaRef}
            placeholder={props.placeholder}
            value={props.value}
            className={props.className}
        />
    )
}

Now we have 2 elements and let's add some styles and make 1 textarea hidden.

import styled from "@emotion/styled";

const StyledInput = styled.textarea`
    vertical-align: top;
    resize: vertical;
    overflow: hidden;
    resize: none;
    width: 100%;
`;

const StyledShadowTextarea = styled(StyledInput)`
    // Visibility needed to hide the extra text area on iPads
    visibility: hidden;
    // Remove from the content flow
    position: absolute;
    // Ignore the scrollbar width
    overflow: hidden;
    height: 0;
    top: 0;
    left: 0;

    // Create a new layer, increase the isolation of the computed values
    transform: translateZ(0);

    // Rewrite all horizontal paddings
    // We do so because we don't need them for height calculation
    padding-top: 0 !important;
    padding-bottom: 0 !important;
`;

// ...code

    reutrn (
        <StyledInput {...props} ref={innerTextAreaRef} />
        <StyledShadowTextarea
            placeholder={props.placeholder}
            value={props.value}
            className={props.className}
            ref={shadowTextAreaRef}
            {/* Add more props for accesability */} 
            aria-hidden
            readOnly
            tabIndex={-1}
        />
    )

Now we have a simple textarea and you can drag it but this is not what we expected because you can set only a static amount of rows and it can't change dynamically based on the input. To do so let's start with creating simple functionality to change the height of the textarea.

// Helper
    const getStyleValue = (value: string) => {
      return parseInt(value, 10) || 0;
    };

    const adjustRowHeight = useCallback(() => {
      if (!innerTextAreaRef.current || !shadowTextAreaRef.current) {
        return;
      }

      const shadowInput = shadowTextAreaRef.current;
      const input = innerTextAreaRef.current;
      const computedStyle = window.getComputedStyle(input);

      // Adjust shadow input width
      shadowInput.style.width = computedStyle.width;

      const paddings =
        getStyleValue(computedStyle.paddingTop) +
        getStyleValue(computedStyle.paddingBottom);
      const border =
        getStyleValue(computedStyle.borderBottomWidth) +
        getStyleValue(computedStyle.borderTopWidth);
      const innerHeight = shadowInput.scrollHeight;

      // Set height to visible input
      input.style.height = `${innerHeight + paddings + border}px`;
    }, []);

Now we need to trigger this function every time when value changes. Sounds like a good task to use useEffect.

    useEffect(() => {
      adjustRowHeight();
    }, [props.value, adjustRowHeight]);

Now we have a simple implementation that dynamically changes our input based on user input.

You can simply implement this with one input (almost, there is one problem if you try to change height for a calculated element but this is topic for a one more article). But let's start to create more real-world examples when we want to limit the amount of rows.

Let's think first about how we can calculate and restrict the number of rows. If we want to restrict amount of rows this is equal to restricting height size of the input and if input goes over this height we enable default scrollable behaviour with overflow: hidden.

Let's start by adding the new props for our component.

type BasicProps = InputHTMLAttributes<HTMLTextAreaElement>;

export type TextareaProps = BasicProps & {
  maxRows?: number;
};

And now let's change our adjustRowHeight function:

const adjustRowHeight = useCallback(() => {
    const shadowInput = shadowTextAreaRef.current;
    // ...previous code here

    // Measure 1 row height by any symbol to the input
    shadowInput.value = 'x';
    const singleRowHeight = shadowInput.scrollHeight;

    // Calculate outer height
    let outerHeight = innerHeight;

    if (maxRows) {
        const maxHeight = maxRows * singleRowHeight;
        // If outer input height higher than max input we use max input
        outerHeight = Math.min(maxHeight, outerHeight);
    }

    const isInputScrollable = Math.abs(innerHeight - outerHeight) >= 1;

    input.style.overflow = isInputScrollable ? 'auto' : 'hidden';

    // Set height to visible input
    input.style.height = `${outerHeight + paddings + border}px`;
}, [maxRows]);

This brings up one interesting problem. If we change overflow that means scrollbar appears with overflow: hidden. This creates available width change for the input inner width and gives us a weird "content jump". We have two strategies to deal with this:

Hide scrollbar (or create a custom which not change the width)
Always keep space for the scrollbar Both solutions have downsides and you should choose based on your UI requirements. Let's for simplicity just hide the scrollbar.

const StyledInput = styled(Input)`
    // ... previous code

    &::-webkit-scrollbar {
        display: none;
    }
`;

// or if you want to show it and keep space
const StyledInput = styled(Input)`
    // ... previous code

    // scrollbar-gutter property reserve space for the scrollbar.
    scrollbar-gutter: stable;
`;

Now we are almost done with our functionality. Let's assume we want to add more functionality and now we want to support minimum rows count. With shadow input we can easily add this.

export type TextareaProps = BasicProps & {
  maxRows?: number;
  minRows?: number;
};

// ...pervious code
const adjustRowHeight = useCallback(() => {
    // ...pervious code

    if (minRows) {
        const minHeight = minRows * singleRowHeight;
        outerHeight = Math.max(minHeight, outerHeight);
    }

    // calculate max rows and set it to the input
}, [maxRows, minRows])

Now we have a fully working autoresizeble textarea!
We can make some improvements to the component and add passing ref support.

export const Textarea = forwardRef<HTMLTextAreaElement | null, TextareaProps>(
  (
    { minRows, maxRows, ...props },
    ref: Ref<HTMLTextAreaElement | null> | null,
  ) => {
        // Magic happens here. Now your component support ref and you can trigger events like "onFocus" from parent component
        useImperativeHandle(ref, () => innerTextAreaRef.current);

        // other component code
  }
)

Full code you can find in the codesandbox.

Conclusion

The default browser input is limited by browser API and to be able to create beautiful and smooth UI sometimes you need to use "hacks". Every hack has its own disadvantage and can bring unusual problems every time you go beyond the Browser API.

In this article, we tried to deal with the most common problems you can face when working with custom teaxtarea. We focused not on the "theoretical problem" but we solved real-world problems and built autoresizable components in the pure react (and a little bit of css in js). Now your component is ready to use and only you need to do is to apply your styles.

Adding a library can limit you and confuse you when you are faced with unusual problems but with your solution where you fully understand the code you can deal with it and expand the solution in the way you want. You can always use the Material UI autoresize component (which use this technic too!) and not spend time on your own implementation but it always bring restriction for your project.

With the "shadow input" technique you can do more with your input. It shouldn't hurt the user experience or performance and also remove browser restrictions from your input.

Now you know more about how input works and probably discovered new css/react features!

DEV Community: Ulad Ramanovich

Spec-Driven Development: The Key to Aligning Team and Improving Code Quality

Introduction

The Role of Technical Specs

Challenges of Developing Features Without Technical Specs

Benefits of Sharing Technical Specs Before Writing Code

How to Create Effective Technical Specs

Implementing a Technical Spec-Driven Development Process

Conclusion

Fullstack Development: Learning Python as JavaScript Developers

The Journey Begins

Why Python?

The Learning Curve

Overcoming Obstacles: Key Concepts

Indentation-Based Syntax

Type system

Python’s Global Interpreter Lock (GIL)

A Pythonic Mindset

Managing Dependencies and Virtual Environments

Finding Support and Resources

How I Learned Python

Where to Find Help

Looking Back and Forward

Mastering React Components with TypeScript Generics

Typescript in react ecosystem

What is generics in typescript

Typescript types inferring magic

Where to use generics in react

Basic component

Adding list and more properties

Generics and arrow functions in react

Made component reusable with Generics

Finalise the component

Conclusion

Mastering React Query. Simplifying Data Management in React with Separation Patterns

Using React Query to Sync with the Server

Custom Hooks as a New Layer for Abstracting Logic

Why to store React Query in custom hooks and Separation of Concerns

React Query and the Common Query Separation Pattern

Conclusion

Mastering React Query. Structuring Your Code for Scalability and Reusability

Understanding React Query: The Basics and Benefits of Using It

Typical structure of react query usage

Query Keys

Query function

Storing react query keys

Abstract for query function

Put all things together

Conclusion

Creating Autoresizeble textarea with hidden input technique

The unusual HTML input behaviour

Let's create our own resizeable textarea

Conclusion

Links