React key Is Not Just a List Optimization

While debugging a Mini Program form renderer, I ran into a familiar problem: the component kept too much internal state, and after switching to a different data object, the safest short-term fix was sometimes to destroy and recreate the component.

In a Mini Program, the direct approach is usually conditional rendering. Make the component disappear, then show it again in the next tick. For example, set a:if to false, then set it back to true. That forces an unmount and a new creation.

This naturally leads to a React comparison: in React, changing key can recreate a component. Does that mean key is a general refresh button?

Not exactly. key is most often seen in list rendering, but in React its role is not only “helping list diffing.” It participates in deciding whether something is still the same component.

Chinese version of this article

key Participates in Component Identity

React associates state with a position in the render tree. In most cases, if the same component type stays in the same position, React preserves its state.

When a component has a key, that key becomes part of its identity:

<Editor key={articleId} article={article} />

When articleId changes, React does not treat this as “the same Editor received new props.” It treats it as “the old Editor was removed, and a new Editor was created.”

The result is:

useState inside the component initializes again.
State inside the child tree is reset too.
Effects run through cleanup and setup as an unmount and mount.
DOM nodes may be recreated instead of reused.

So changing key is not an ordinary re-render. It is closer to replacing one component instance with another.

Re-rendering and Recreating Are Different

When a React component re-renders because props or state changed, its identity remains the same. Internal state is preserved. Effects run according to dependency changes. The DOM is reused where possible.

When key changes, something else happens: React sees a different identity. The old component goes through unmounting, and the new component starts from its initial state.

That is why changing key can reset a component. It does not refresh the component in place. It tells React to stop preserving the old subtree.

When key Is a Good Tool

The best case is when internal state should naturally belong to a business identity.

For example, after switching contacts in a chat window, the draft for the previous contact should not remain in the input:

<Chat key={to.id} contact={to} />

Or after switching articles in an editor, local draft state, validation state, and cursor-related state may all need to start from the new article:

<ArticleEditor key={article.id} article={article} />

In these cases, using key is natural because the object in the user’s mind has changed. The component state should change with it.

Forms, editors, wizards, and preview components often fall into this category. If the internal state belongs to a stable business object, using that object’s id as the key aligns component identity with business identity.

When key Is the Wrong Tool

Do not use key as a universal way to hide state bugs.

If a component breaks unless it is destroyed and recreated, the relationship between internal state and external data is probably unclear. Maybe props changed but internal caches did not synchronize. Maybe a form renderer mixed schema, initial values, user input, and reset behavior into one state model. Changing key can make the symptom disappear, but it may only bypass the real issue.

Avoid code like this:

<Form key={Date.now()} />

or:

<Form key={Math.random()} />

This makes React think the component identity changed on every render. Inputs lose content, focus disappears, effects run repeatedly, and performance gets worse.

List keys follow the same principle. Prefer stable business ids. Array indexes are not always wrong, but if a list can insert, delete, or reorder items, index keys can make state follow the wrong item.

Back to the Form Renderer

For the Mini Program form renderer problem, changing key in React is indeed a possible tool. But its meaning is not “refresh this component.” Its meaning is “this is a different component now.”

In Mini Program or Vue contexts, key does not behave exactly the same as React. If the goal is to force recreation, conditional rendering is often more direct. The more durable fix is to clean up the data flow so the component responds correctly when external data changes.

If a form renderer must rely on destruction and recreation to work, it probably holds too much uncontrolled state. The long-term design should make several things explicit:

What identifies the schema.
How initial values differ from current user input.
Who owns validation state, dirty state, and submitting state.
Whether external data changes should synchronize existing state or explicitly trigger a reset.

After these questions are clear, key can still be used for reset behavior. But it becomes an expression of identity change rather than a patch over state design problems.

Summary

React key is not just a list optimization. It participates in component identity. The question it answers is: is this component at this position still the same component?

If the answer is no, a stable business id as key can reset state cleanly. If the only reason to change key is that internal state has become hard to reason about, the data flow and state boundaries need another look.

The React documentation has two related sections: