DEV Community: KyLoc20

Preface to React Practice Discussions

KyLoc20 — Sat, 15 Feb 2025 07:32:48 +0000

How do we describe the process of developing a React app?

First, we prepare something like routing, state management, and network requests.

Then, we write a collection of functions (Functional Component) and compose them into one

These 2 steps reflect the 2 key considerations: architecture and business logic, with most resources devoted to the latter.

React is to enable a team of junior engineers to build a scalable application.

When it comes to:

a polished LandingPage
a survey Form
a financial data analysis Table
a FeedCard list like X
a Button or a line of text

All of them go to writing components.

Here, component refers strictly to React functional components(FC): functions that accept props, manage internal state, and return UI elements based on props and state.

Thus, when delivering a feature, our focus narrows to writing a good component.

The baseline requirement: fulfill the specs.

The advanced goal: ensure the component is reusable or modifiable for future scenarios.

Writing a component typically starts from one of these scenarios:

A detailed figma file.
An existing component.
A prototype with basic requirements.
An idea.

Scenarios 1 and 2 are aiming for 100% fidelity → more like imitation.

Scenarios 3 and 4 demand clarifying requirements, gathering inspiration, designing, and implementing → more like creation.

Whether imitating or creating, every component follows two steps:

Draw visual elements → Make it look right.
Inject Data/state → Make it interactive.

Rarely do we build components from scratch. Leveraging existing UI libraries is preferred.

This brings us to the familiar topic: What value do UI libraries provide?

Efficiency
Cost reduction
Team confidence and DX (Developer Experience)
User Experience

Most importantly, a component library is a team’s asset. Every iteration is an investment.

Finally, two questions I aim to explore in this series:

How do we establish a design language to improve communication among users, PMs, designers, and developers?

How do we build a component library from real-world needs to enhance human-device interaction?

Write a Form (3): Unified Input Components

KyLoc20 — Wed, 28 Sep 2022 10:15:57 +0000

Everyday we write various input elements to deal with various types like string, number and boolean.

Then we combine them in one component and call it a form component.

Where there is a variety, there is a complexity.

This part talks about that complexities should be placed IN the input components NOT OUT of them.

Messy Input

Suppose we have a form component with 3 input elements:

function MySimpleFormComponent() {
  const refValueList = useRef<any[]>(["", "1", true]);
  const handleChange = (index: number, e: ChangeEvent<HTMLInputElement>) => {
    const updateValueList = (index: number, value: any) => {
      refValueList.current[index] = value;
    };
    updateValueList(index, e.target.type === "checkbox" ? e.target.checked : e.target.value);
  };
  const handleSubmit = (e: FormEvent) => {
    e.preventDefault();
    console.log("Let's Submit: ", refValueList.current);
  };
  return (
    <form onSubmit={handleSubmit}>
      <input type="text" onChange={(e) => handleChange(0, e)} defaultValue={"default"} />
      <input type="number" onChange={(e) => handleChange(1, e)} defaultValue={"1"} />
      <input type="checkbox" onChange={(e) => handleChange(2, e)} defaultChecked={true} />
      <button type="submit">Submit</button>
    </form>
  );
}

Using <input> directly brings issues that make us feel bad:

NOT unified types: defaultValue and defaultChecked
NOT unified handlers: e.target.checked and e.target.value
limited functionalities and validations
messy JSX structures

Unified Component

Eagerly we need clean and tidy Input Components :

function TextInputComponent({ defaultValue, onChange }: { defaultValue: string; onChange: (value: string) => void }) {
  //custom implementation
  const [value, setValue] = useState(defaultValue);
  useEffect(() => {
    onChange(value);
  }, [value]);
  return <div>Your Custom TextInputComponent: {defaultValue}</div>;
}
function NumberInputComponent({ defaultValue, onChange }: { defaultValue: number; onChange: (value: number) => void }) {
  //custom implementation
  // ...
  return <div>Your Custom NumberInputComponent: {defaultValue}</div>;
}
function CheckboxInputComponent({ defaultValue, onChange }: { defaultValue: boolean; onChange: (value: boolean) => void }) {
  //custom implementation
  // ...
  return <div>Your Custom CheckboxInputComponent: {defaultValue}</div>;
}

Each InputComponent has its own states, styles, logic and so on.

They could be implemented as various utilities while be treated as unified input elements because they have props onChange and defaultValue in common.

A Better Practice

Let's write a better form:

function MyBetterFormComponent() {
  const refValueList = useRef<any[]>(["", 1, true]);
  const handleChange = (index: number, value: any) => {
    const updateValueList = (index: number, value: any) => {
      refValueList.current[index] = value;
    };
    updateValueList(index, value);
  };
  const handleSubmit = (e: FormEvent) => {
    e.preventDefault();
    console.log("Let's Submit: ", refValueList.current);
  };
  return (
    <form onSubmit={handleSubmit}>
      <TextInputComponent onChange={(v) => handleChange(0, v)} defaultValue={"default"} />
      <NumberInputComponent onChange={(v) => handleChange(1, v)} defaultValue={1} />
      <CheckboxInputComponent onChange={(v) => handleChange(2, v)} defaultValue={true} />
      <button type="submit">Submit</button>
    </form>
  );
}

Remember: consume <InputComponent>s as if they are <input>s.

Next part will talk about how to customize a useful validator inside a <InputComponent>.

Write a Form (2): Self-hosted States

KyLoc20 — Sat, 17 Sep 2022 05:36:38 +0000

In HTML, form elements such as <input>, <textarea>, and <select> typically maintain their own state and update it based on user input.

We can exploit this feature. But fist thing first, talk about controlled component.

Controlled Component

function FreeInput({ defaultValue }: { defaultValue: string }) {
  const handleChange = (e: ChangeEvent<HTMLInputElement>) => {
    console.log(e.target.value);
  };
  return <input type="text" onChange={handleChange} defaultValue={defaultValue} />;

It is always available to access the value of <input> from e.target.value of onChange because the value is self-hosted.

This FreeInput only expose the prop defaultValue to receive a initial value.

However it tends to combine this self-hosted value with a React state, by sending a state to input.value as a property:

function ControlledInput({ defaultValue }: { defaultValue: string }) {
  const [value, setValue] = useState(defaultValue);
  const handleChange = (e: ChangeEvent<HTMLInputElement>) => {
    console.log(e.target.value);
    setValue(e.target.value);
  };
  return <input type="text" value={value} onChange={handleChange} />;
}

In most situations, the state of value is sent from parent component as a prop:

function FormAsController() {
  const [value1, setValue1] = useState("1");
  const [value2, setValue2] = useState("2");
  const [value3, setValue3] = useState("3");
  const handleSubmit = (e: FormEvent) => {
    e.preventDefault();
    console.log("Let's Submit: ", [value1, value2, value3]);
  };
  return (
    <form onSubmit={handleSubmit}>
      <InputControlledByParent value={value1} onChange={setValue1} />
      <InputControlledByParent value={value2} onChange={setValue2} />
      <InputControlledByParent value={value3} onChange={setValue3} />
      <button type="submit">Submit</button>
    </form>
  );
}

function InputControlledByParent({ value, onChange }: { value: string; onChange: (value: string) => void }) {
  const handleChange = (e: ChangeEvent<HTMLInputElement>) => {
    console.log(e.target.value);
    onChange(e.target.value);
  };
  return <input type="text" value={value} onChange={handleChange} />;
}

Both ControlledInput and InputControlledByParent are called controlled component because their self-hosted values are controlled by React states.

This is to obey the principle of "single source of truth", you can refer to React Docs.

A Potential Problem

You may notice that putting value states of components InputControlledByParent into the component FormAsController could bring a Re-Render issue:

Once an InputControlledByParent updates its value, the whole FormAsController including all the InputControlledByParents will get Rerendered.

Oh, that's a little sick, especailly there are other components which should not be influenced.

Certainly we can wrap each InputControlledByParent with React.useMemo, but not today, I prefer to React.useRef.

A Better Practice

Still remember we gonna use the feature of self-hosted? Here we are.

With React.useRef, each Input is allowed to host its own value and send its latest value to Form only when updates:

function DemocraticForm() {
  const refValueList = useRef(["", "", ""]);
  const updateValueList = (index: number, value: string) => {
    refValueList.current[index] = value;
  };
  const handleSubmit = (e: FormEvent) => {
    e.preventDefault();
    console.log("Let's Submit: ", refValueList.current);
  };
  return (
    <form onSubmit={handleSubmit}>
      <SelfHostedInput defaultValue={"0"} onChange={(v) => updateValueList(0, v)} />
      <SelfHostedInput defaultValue={"1"} onChange={(v) => updateValueList(1, v)} />
      <SelfHostedInput defaultValue={"2"} onChange={(v) => updateValueList(2, v)} />
      <button type="submit">Submit</button>
    </form>
  );
}

function SelfHostedInput({ defaultValue, onChange }: { defaultValue: string; onChange: (value: string) => void }) {
  const handleChange = (e: ChangeEvent<HTMLInputElement>) => {
    console.log(e.target.value);
    onChange(e.target.value);
  };
  return <input type="text" defaultValue={defaultValue} onChange={handleChange} />;
}

Now SelfHostedInput is truly self-hosted, and its update won't cause its Form to re-render.

This way only works in the situation where the Form's UI is NOT dependent on any input value.

Next part will talk about how to unify various input elements.

Write a Form (1): Understand its Functionality

KyLoc20 — Thu, 15 Sep 2022 05:54:30 +0000

Basically, a Form consists of a smart container and its elements.

<form>
    <input type="text" name="name" />
    <input type="email" name="email" />
    <input type="password" name="password" minlength="8" required>
    <input type="submit" value="Submit" />
</form>

Overview

Usually form elements handle input from users while form container do these things:

Keep mutable states and handle updates from form elements.
Render a friendly form-like UI.
Handle Validation before Submitting.
Handle Submit event.

In the following parts, these 4 jobs above will be discussed.

Here is a simple form component in React:

function Form() {

    const [value1,setValue1] = useState("")
    const [value2,setValue2] = useState("")
    const [value3,setValue3] = useState("")

    const handleSubmit = (event) => {
        event.preventDefault();
        //do something mutating or uploading
    }

    return (
        <form onSubmit={handleSubmit}> 
            <InputElement1 value={value1} onChange={setValue1}/>
            <InputElement2 value={value2} onChange={setValue2}/>
            <InputElement3 value={value3} onChange={setValue3}/>
            <SubmitButton />
        </form>
    );
}

Benefiting from using <form>, this HTML tag provides us with some default behavior:

Listen to Submit Event from its elements. <input type="submit" /> or <button type="submit" /> both could trigger this event so that you don't bother to define an extra event handler.
Validate input data before onSubmit which is quite useful.
Browse to a new page defined in the attribute of action, however, often we need do more things in handleSubmit so block it by event.preventDefault().

Next part let's talk about how to optimize our Form using the intrinsic controlled feature.