Add a feature: guarantee setState({}) is a true no-op in Zustand's vanilla store.

[Michealjunior]

Problem Description

Some applications call setState defensively with an empty object ({}), for example when update logic is conditional or composed dynamically.

Currently, there is no explicit contract guaranteeing that calling:

store.setState({})

is treated as a no-op. In practice, this can lead to:

Unexpected subscriber notifications

Unnecessary state identity changes

Subtle performance issues in real-world apps

This feature request proposes a clear and explicit behavior contract for this case.

### Proposed Behavior

When calling setState(partial, replace?):

✅ New Contract (Feature Request)

If partial is an object with no enumerable own keys

And replace is not true

Then:

The update must be treated as a no-op

The store must not notify subscribers

The store must preserve the existing state reference

🚫 Explicitly Out of Scope

This applies only to empty object partial updates ({})

Existing semantics for:

Non-empty partials

Updater functions that return keys

replace: true

must remain unchanged.

Why This Matters

Defensive setState({}) calls are common in application code

Treating empty partials as no-ops avoids unnecessary updates

Makes state updates more predictable and easier to reason about

Aligns with developer intuition: “no keys” → “no change”

Test Coverage / Specification

A comprehensive test suite is provided to define the exact expected behavior, covering:

No notifications for empty object partials

No state identity changes for empty partials

Notifications for:

Non-empty partials (even if values are identical)

Symbol keys

undefined, NaN, -0 / 0

Function references

Preservation of replace: true semantics

Correct subscriber behavior

Test Environment

Package manager: pnpm

Test runner: vitest

Scope: vanilla store

Relevant test file:

tests/vanilla/noop-partial-updates.test.ts

Expected Outcome

By defining this behavior explicitly, Zustand can:

Prevent accidental regressions

Improve performance characteristics

Provide a clearer mental model for setState

Support common defensive update patterns safely

[dbritto-dev]

@Michealjunior tbh, that's on userland not on zustand land

[Michealjunior]

Sorry what do u mean By Userland.

…

________________________________ From: Danilo Britto ***@***.***> Sent: Thursday, December 18, 2025 21:15 To: pmndrs/zustand ***@***.***> Cc: Michealjunior ***@***.***>; Mention ***@***.***> Subject: Re: [pmndrs/zustand] Add a feature: guarantee `setState({})` is a true no-op in Zustand's vanilla store. (Discussion #3328) @Michealjunior<https://github.com/Michealjunior> tbh, that's on userland not on zustand land — Reply to this email directly, view it on GitHub<#3328 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BLSOFGABUUNUIYVL4DRCK7T4CMDPTAVCNFSM6AAAAACPO7PJAWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKMRZGI4TMMA>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[dbritto-dev]

@Michealjunior I mean that should be manage by the user not by Zustand, you can face the same issue by calling setState from useState without making changes and that would trigger a new render

[Michealjunior]

Okay I understand

…

________________________________ From: Danilo Britto ***@***.***> Sent: Thursday, December 18, 2025 21:19 To: pmndrs/zustand ***@***.***> Cc: Michealjunior ***@***.***>; Mention ***@***.***> Subject: Re: [pmndrs/zustand] Add a feature: guarantee `setState({})` is a true no-op in Zustand's vanilla store. (Discussion #3328) @Michealjunior<https://github.com/Michealjunior> I mean that should be manage by the user not by Zustand — Reply to this email directly, view it on GitHub<#3328 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BLSOFGFTIURXYIFIK2LVTIT4CMD4RAVCNFSM6AAAAACPO7PJAWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKMRZGI4TQMI>. You are receiving this because you were mentioned.Message ID: ***@***.***>