Protected vs. #[Locked] Public Properties: Which Keeps Internal State Safe in Livewire?

Preventing Accidental Public Exposure

The core goal is to shield internal counters, caches, or derived values from being sent to the browser while still allowing UI‑bound fields to remain reactive.

Two Documented Approaches

Protected/Private Properties are omitted from hydration, so they never appear in the initial payload and cannot be mutated via wire:model. They also cannot be invoked as actions.

#[Locked] Public Properties keep the property on the component but mark it as invisible to the frontend; it is not serialized, yet the property can be mutated server‑side and reused across requests.

Unresolved Decision Point

Livewire offers no enforced convention to distinguish helper methods from intentionally exposed actions. Teams must choose between relying solely on PHP visibility, adding explicit markers, or adopting naming conventions, and the interaction between #[Locked] and server‑side mutation during the same request remains undocumented across versions.

Questions

• When a component mixes UI‑bound fields with internal counters, does using protected properties or #[Locked] public properties yield equivalent security for the internal state?
• What is the effect of mutating a #[Locked] property during a request on subsequent hydration cycles?
• How can a team reliably enforce a boundary between helper methods and exposed actions without relying on fragile conventions?