لماذا تحتاج العناصر الفرعية إلى @Binding

When a parent owns a value and a child needs to change it, they must share one source of truth. Otherwise they drift apart. 🔗

If you just pass a value into a child, the child gets a copy. Editing that copy never touches the parents original data.

A @Binding is a two-way connection. The child reads and writes the parents value directly, with no copy in between.

Think of a binding as a remote control. The child does not own the data; it just holds a reference to where it lives.

The parent owns the state with @State. The child only borrows it through @Binding. Ownership stays in one clear place.

With a binding, changes flow both ways. The parent updates the child, and the child can update the parent. Everything stays in sync.

A child view declares a binding for the value it needs to mutate, marked with the @Binding property wrapper.

You have used bindings already. Toggle, TextField, and Slider all take a binding so they can write back the value you change.

Bindings let you split a big screen into small, focused child views without losing shared state. This keeps your code reusable. ✨

Never copy the same value into both parent and child as separate @State. That creates two truths that quietly disagree.

One value, many views editing it safely: that is the promise of @Binding. The next lessons show how to wire it up.

Quick check on shared state.

A parent owns state; a child borrows it with @Binding for safe two-way edits. One source of truth keeps every view in sync. 🎉