fix(learn): Clear form error on new input in City Quiz examples

[isaacbernat]

What is the current behavior?

In the "City quiz" examples found on both the learn/managing-state and learn/reacting-to-input-with-state pages, submitting a wrong answer causes an error message to appear. This error message then persists indefinitely, even when the user starts typing a new answer or resubmits the form, creating a confusing user experience.

What is the new behavior?

This PR fixes the UX bug in both examples by clearing the error state whenever a new user action (onChange or onSubmit) is initiated. This ensures the UI provides timely and relevant feedback, which better reflects modern form handling best practices.

How to test:

1. Navigate to the "City quiz" example on the learn/managing-state page.
2. Submit an incorrect answer (e.g., "test"). The error message appears.
3. Start typing a new answer in the text area.
4. Expected: The error message immediately disappears.
5. Repeat the test on the learn/reacting-to-input-with-state page to confirm the fix in both locations.

[meta-cla[bot]]

Hi @isaacbernat!

Thank you for your pull request and welcome to our community.

Action Required

In order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you.

Process

In order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA.

Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with CLA signed. The tagging process may take up to 1 hour after signing. Please give it that time before contacting us about it.

If you have received this in error or have any questions, please contact us at [email protected]. Thanks!

[github-actions[bot]]

Size changes

📦 Next.js Bundle Analysis for react-dev

This analysis was generated by the Next.js Bundle Analysis action. 🤖

Five Pages Changed Size

The following pages changed size from the code in this PR compared to its base branch:

Page	Size (compressed)	First Load
/404	127.9 KB (-1 B)	238.44 KB
/500	127.91 KB (-1 B)	238.45 KB
/[[...markdownPath]]	130.34 KB (-1 B)	240.88 KB
/errors	128.15 KB (-1 B)	238.69 KB
/errors/[errorCode]	128.13 KB (-1 B)	238.67 KB

Details

Only the gzipped size is provided here based on an expert tip.

First Load is the size of the global bundle plus the bundle for the individual page. If a user were to show up to your website and land on a given page, the first load size represents the amount of javascript that user would need to download. If next/link is used, subsequent page loads would only need to download that page's bundle (the number in the "Size" column), since the global bundle has already been downloaded.

Any third party scripts you have added directly to your app using the <script> tag are not accounted for in this analysis

Next to the size is how much the size has increased or decreased compared with the base branch of this PR. If this percentage has increased by 10% or more, there will be a red status indicator applied, indicating that special attention should be given to this.

[meta-cla[bot]]

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Meta Open Source project. Thanks!

[rickhanlonii]

I'm skeptical that this is much better, but in order to change it, we would need to: a) update the vanilla example at the beginning to support this behavior b) if this is the way the UX should be, the you shouldn't be able to "forget" to clear the error in every place (which is a point explained in this guide).

[isaacbernat]

Thanks for the quick feedback @rickhanlonii . My primary goal with this PR is to fix what I believe is a UX bug: the error message persists incorrectly. This may confuse users and doesn't reflect modern form handling.

I agree with you that a useEffect would be the most robust, production-grade solution. However, useEffect hasn't been introduced at this stage of the tutorial, so using it here might break the learning flow for a beginner.

Therefore, I believe the best path forward is a simple, targeted fix that uses only the concepts already taught. I intent to: a) Apply the equivalent fix to the initial vanilla JS example for behavioral consistency (good catch!). b) Apply the setError(null) fix to the final React examples (as already committed in the PR).

This approach solves the UX bug while respecting the tutorial's step-by-step structure. I'll push these changes shortly unless you have further concerns.

Thanks again for the insights and raising great points about the implementation.

[rickhanlonii]

I think if you can't address point b) I wouldn't spend any more time on this

[isaacbernat]

@rickhanlonii Thanks for pushing for a better solution on point (b)! This led me to a fully declarative implementation which respects the tutorial's learning flow (no useEffect needed).

It uses a "smarter" error state that stores the failed answer. The decision to display the error is then derived on every render, checking if the current input matches the failed answer and the form isn't actively submitting.

This systemically solves the issue:

• The error disappears the moment the user types or resubmits.
• It requires no manual setError(null) calls, eliminating the anti-pattern you pointed out.
• It uses only the concepts introduced to the reader at this stage of the docs.

I've pushed up a single, amended commit that implements this improved logic consistently across all relevant examples.

This was a great learning experience. Let me know what you think.

[isaacbernat]

@rickhanlonii , just checking in on this. I've rebased the branch on the latest main to resolve any potential conflicts. Let me know if anything else is needed from my side. Thanks!