Write an AngularJS to React Migration Prompt That Maps Every Concept

An AngularJS app is held together by things React doesn't have: $scope, two-way binding, dependency-injected services, and directives that mutate the DOM directly. Migrating it isn't translation. It's a concept-by-concept remap, and the failure mode is React that renders but silently loses the binding behavior the old app depended on. An AngularJS to React migration prompt makes that remap explicit: inventory first, map each concept, emit one component against a contract.

Most write-ups online show someone pasting a single component into ChatGPT and pasting the React back. That works for a contact form. It falls apart on component number forty, when a service the model didn't know about gets reinvented three different ways across three files.

The fix isn't a smarter model. It's a prompt that plans the remap once and reuses it.

Why "convert this component" misses the hard parts

Hand a model one AngularJS component and it'll give you plausible React. The problem is what it can't see: the shared service injected into half your controllers, the $rootScope event two components communicate through, the directive that reaches into the DOM on link. Convert components in isolation and each one reinvents those shared pieces.

Here's the take worth defending. The hard part of an AngularJS migration isn't JSX. It's the cross-cutting concerns AngularJS made invisible. $scope inheritance, DI singletons, digest-cycle side effects. A migration prompt earns its keep by surfacing those first, before a single component gets rewritten, so the same service becomes one React context instead of three copies.

What an AngularJS to React migration prompt does

An AngularJS to React migration prompt is a staged remapper that reads your AngularJS source, builds a concept map (directives, controllers, services, bindings), and emits React one component at a time against a fixed output contract. It plans the shared pieces before it touches a component.

Run it to:

• Inventory every directive, controller, service, and filter in scope
• Map each AngularJS concept to its React equivalent once, in a shared table
• Convert ng-model bindings to useState plus explicit handlers
• Turn injected services into hooks or context, named once and reused
• Flag DOM-mutating directives that need a manual useRef decision
• Emit one component per pass so nothing exceeds the context budget

That shared concept map is the difference between a clean migration and forty inconsistent rewrites.

Anatomy of the prompt

Variables
  {{angular_source}}       → the AngularJS component/module to convert
  {{shared_services}}      → injected services in scope (or let it derive)
  {{target_react_version}} → e.g. React 19 with hooks
  {{concept_map}}          → optional: a pre-agreed mapping to reuse

Prompt
  Role: you are an AngularJS-to-React migration planner.
  Task: convert {{angular_source}} to {{target_react_version}}.
  Rules:
    - Build the concept map before emitting any component.
    - Map ng-model to useState + handler; $watch to useEffect deps.
    - Flag $scope mutation and DOM-touching directives for review.

Output contract
  Return: concept map + per-component React + a review-needed list.

1. Inventory before converting

The model can't reuse a service it never catalogued. Force the inventory pass as its own section so shared pieces surface before any component is rewritten.

2. Lock the concept map

The concept map (ng-model → useState, service → context, $watch → useEffect) gets agreed once. Feed it back in {{concept_map}} on later passes so every component converts the same way.

3. Convert one component, read the review list

Each pass emits one component plus a list of things the model wouldn't convert blindly. That list is where the real review time goes.

Prompt-craft patterns for framework remaps

Map concepts, don't translate syntax. A prompt that goes line by line produces React that mirrors AngularJS structure instead of idiomatic hooks. Force a concept map so $scope.$watch becomes a real useEffect, not a watcher shim.

Name the binding's new state. ng-model="user.name" has to become a specific useState. Make the contract name it, so you can verify the binding survived rather than trusting the diff.

Quarantine the unconvertible. Directives that mutate the DOM, $rootScope events, digest-cycle hacks. These don't have clean React equivalents. The contract should route them to a review-needed list, not let the model invent a fragile workaround.

Where Claude and ChatGPT diverge on binding conversion

The two models handle two-way binding differently, and it shows. Claude tends to convert ng-model into a useState value with an explicit onChange and comments the original binding inline, which makes the mapping easy to audit. GPT-4o writes terser React but will sometimes collapse a $watch into inline logic that loses the dependency tracking, unless the "map $watch to useEffect with explicit deps" rule sits on the final line where it stays in attention.

Both models will quietly reinvent a shared service per component if the concept map isn't pinned. So pin it, and pass it back every call. Watch the stale-closure trap too: a $scope value read inside a converted callback can capture an old render's state, which AngularJS never had to worry about. Pin the model version, because a converter that started mapping services differently after an update is a regression you'll only catch when a component misbehaves in production.

How this fits the broader migration

An AngularJS-to-React move is one framework migration among many. The staging discipline, inventory and reversible steps, is the same logic that drives any major version bump. For the general structure, the framework migration prompt covers the staged-rollout pattern this builds on. If your migration also changes the language under the framework, the cross-language refactor prompt handles idiom preservation.

Variables you'll set

Getting started

1. Copy the staged structure into ChatGPT, Claude, or Gemini.
2. Paste one component or module into {{angular_source}}, not the whole app.
3. List injected services in {{shared_services}} so the inventory is complete.
4. Run it and read the concept map before any component code.
5. Save the concept map and feed it back via {{concept_map}} next pass.
6. Work the review-needed list by hand before you call a component done.

For a migration spanning many components with the inventory and staging already wired in, the Framework Migration Harness Playbook runs the full sequence.

Once components are converted, you'll want to verify the React actually behaves like the AngularJS it replaced. The Cross-Language Refactor Harness locks an output contract per file for exactly that kind of behavior-preserving check. New to buying packs versus rolling your own? Start with how to choose a reusable AI prompt pack.