Phoenix Refactor
When to Use
- •Moving logic from controllers or LiveView into context functions.
- •Simplifying functions or replacing conditionals with pattern matching or
with. - •Applying style or idiom rules (pipe, naming, module structure).
- •Extracting components or context functions to reduce complexity.
- •Improving error handling or boundaries without changing observable behaviour.
Principles
- •Preserve behaviour: Do not change inputs/outputs or side effects. Rely on existing tests; run
mix testafter each logical step. - •Context boundaries: When refactoring, ensure business logic ends up in contexts and web layer stays thin. Do not push web concerns (conn, socket, flash) into context.
- •Small steps: Prefer a sequence of small, testable refactors over one large change. Commit or checkpoint when tests pass.
- •Idioms: Prefer pipe where data flows through transformations; use
withfor multi-step success/failure; replace nestedif/casewith pattern matching in function heads where appropriate. - •Verification: After refactor, run
mix testandmix credoand confirm no new failures or warnings. Do not suppress Credo without justification.