← Blog

AI coding in React Native: define the Save bug before asking for a fix

3 min read
Watch the walkthrough on YouTube

You press Save, see no response, and press it again. In our prepared example, two requests are now running. Asking an AI assistant to “fix the button” leaves important behavior undecided: should a second call be ignored, can a failed save be retried, and which existing components should the change preserve?

This lesson starts with those decisions. The example is a teaching adaptation, with executable helper tests and an illustrative React Native caller. It is not a complete mobile app or a recorded production incident.

Describe the sequence before the solution

A useful task describes something another developer can reproduce:

  1. Start a save through one owner of the operation.
  2. Keep the first task pending.
  3. Call the same owner's save action again.
  4. Check whether another task starts before the first finishes.

The expected result is one started task. The second attempt returns ignored; it does not report a new successful save.

Recovery matters too. A button that stays blocked permanently prevents duplicates, but fails the user's next attempt. Our task therefore requires release after success, rejection and a synchronous throw. A rejected task must preserve its original error for the caller.

Situation Required result
Another call while pending No new task; return ignored
A later call after success Start a new save
Retry after failure Start a new save
Separate mounted owners Independent admission state
Failed save in the UI Useful localized error and an available retry

The UI row requires checks in a host app. The isolated helper suite cannot establish it.

Set the boundary of the change

One mounted owner retains one gate. A second form may have a separate gate. We are not creating a module-global lock that makes unrelated forms block each other.

This client gate also does not establish server idempotency. A lost response, another device or a new app session introduces a different question: did the server already process the operation? Keep that question outside this small fix rather than implying that one client flag solves it.

Supply files that resolve decisions

The useful context is specific:

The sample uses an existing AppButton with loading, disabled and accessibility state. Labels come from the host's localization system. A proposed fix that installs another button or translation library would expand the task without evidence that it is necessary.

Ask for an explanation you can review

Use the first stage of the prompt pack:

Read task.md and save-gate.before.ts. Explain the triggering sequence,
the expected behavior and the scope of the smallest change.
List any missing information before proposing code. Do not edit yet.

Compare the response with the acceptance cases. Check whether the assistant preserves retry, distinguishes an ignored attempt from success, and understands where the gate must live.

Then explicitly ask it to read the project context and caller. This course does not assume that every tool automatically discovers the same instruction files. Any tool-specific setup belongs in a separately verified example.

Exercise: an upload button

Write the contract for repeated upload presses before choosing code. A useful answer allows one active upload through the owner, permits retry after failure, and preserves the selected file. That last condition can disappear if the task mentions only repeated presses.

Next: implement and explain the retained save gate.

The bilingual storyboard contains the complete spoken lesson. Video narration is English, generated using a clone of Ibrahim Fathi's voice, with English and Arabic subtitle tracks. Watch Episode 1. Releases October 18, 2026 at 4:00 PM Cairo.

Comments

No account needed.

  1. Loading comments…