End-to-end process for a Modal props API break
the full lifecycle of a breaking API change.
justify and design the change, additive rollout with deprecation, major release plus codemod, comms and adoption tracking.
What's really being asked
This evaluates the complete lifecycle of a breaking change, from why it is needed through to broad adoption, on a high-impact component.
The full answer
Start by validating the need: what problem with the current Modal props forces a break, and is there a non-breaking alternative. Gather input from consumers, then design the new API and circulate an RFC or proposal so affected teams can react before code lands. Implement additively where possible: support both the old and new props, mapping old to new internally, and emit deprecation warnings for the old shape. Release the change as a major version per semver. Provide a codemod to auto-migrate common usage and a migration guide with before-and-after examples. Communicate early and repeatedly through changelog, release notes, direct outreach, and a clear removal timeline. Maintain an adoption dashboard tracking who still uses the old props, support stragglers, and only remove the deprecated API in a later major once adoption is high.
The mistakes people make
Jumping to a hard swap with no rationale or RFC. No deprecation overlap. No codemod or guide. One-shot communication. Shipping the break as a minor.
What usually comes next
When is a parallel new component better than breaking the existing one? How long should the overlap last? How do you handle teams that cannot upgrade?
A concrete example
The Modal moves from onClose plus isOpen booleans to a single open-state controller prop. You publish an RFC, then version 5.0.0 supports both shapes with the old one deprecated. A codemod rewrites common usage and a guide covers the rest. You announce a removal date, track remaining old-prop usage, and version 6.0.0 finally removes the legacy props.
Interview question
Why circulate an RFC before implementing a breaking change to a core component's props API?
- a.It automatically migrates all consumer code
- b.It guarantees no migration guide will be needed
- c.It lets affected teams surface concerns and alternatives before code is committedCorrect
- d.It removes the need for a major version bump
Why? this is the answer
An RFC gathers consumer input early, catching better alternatives and reducing surprise before the change is built. It does not replace semver, migration guides, or codemods, which are still required to ship the change safely.
Just read this? Test yourself on what you have been reading.
Read the original → zeroheight.com
- #breaking-changes
- #rfc
- #migration
- #modal
- #versioning
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles