blog main page

In the previous part, we focused on the conceptual shift from DOM-centric scripting to component- and state-driven application design. Now, in this second part, we take that mindset and apply it directly to our teaching example by redesigning the plain JavaScript Task Board as a real Angular application before fully implementing it. We will discuss route boundaries, component taxonomy, communication patterns, state ownership, service responsibilities, TypeScript models, form boundaries, and the anti-patterns from the original app that we intentionally refuse to carry into the Angular version. This part is where the migration becomes a serious architectural redesign rather than a mechanical rewrite.

In this first part, we begin with the most important foundation: the mindset shift required when moving from a plain HTML, CSS, and JavaScript application to Angular and TypeScript. Before talking about components, state, forms, or routing, we first need to understand why a direct syntax rewrite is not enough and why Angular asks us to think in terms of explicit state, typed models, component boundaries, and clear communication contracts. This part introduces the teaching example, explains the architectural weaknesses that often appear in plain JavaScript apps, and sets up the core ideas that the later parts will build on in much more practical detail.

I wrote a short piece on a topic that, in my view, still does not receive enough attention in software teams that rely heavily on AI: AI coding agents can improve output in obvious and immediate ways, while also weakening engineering quality indirectly when their use is not managed with enough discipline. The issue is not only code generation itself. It is also what repeated dependence on these tools can do to problem framing, debugging habits, code review quality, design ownership, and even a team’s ability to keep moving when the agent is unavailable. I also suggest one practical response: keeping at least one no-agent engineering day each week, and using that day to establish the engineering standard for the rest of the week.

Part 1 focused on the foundation: a clear “model is truth” mindset, UI derived from state, and a linear undo/redo timeline that behaves the way people expect. In this follow-up, I take that same baseline and make it production-ready by adding transactions so cancelled or failed operations never pollute history. I walk through three small demos: the core history mechanics (undo/redo stacks, redo cleared on new edits, buttons reflecting capability), then two transaction styles you can standardize on (cancel via throw vs cancel via return value). From there, it’s about the practical decisions that determine whether undo/redo feels trustworthy: when rollback should merely avoid committing history versus when it must restore state, how to keep snapshots fast with caps and smaller payloads, and the pitfalls that show up when mutations bypass the history boundary.