$ cd ./topics/frontend-craft
Component architecture, React patterns, security and testing strategies that give teams confidence rather than ceremony.
28 notes🌱 1 seed🌿 20 growing🌳 7 evergreen
Good frontend work is mostly invisible: components that compose, data that’s validated at the edge, and tests that fail for the right reasons. This hub gathers how I structure React apps, design components other teams can actually reuse, and test them, from unit tests with a mocked network to end-to-end suites that whole departments share.
hover to explore · click to open
Case study — raising coverage with network-level mocks instead of brittle ones, shipping features test-first, speeding up quality checks, and getting Playwright adopted across several teams.
Case study — designing and shipping a React network-graph library for several teams, and why rendering tech, API shape and Storybook mattered most.
Case study — leading the UI of a low-code network automation platform where workflows are drawn as BPMN diagrams. Model-driven editing, server-side permissions and a catalogue of reusable building blocks.
Case study — UI engineers were scattered across backend-shaped scrum teams, under-used and unaware of each other. Making the case for a UI community, then chairing it across departments.
Case study — taking a large React codebase from a long backlog of TypeScript errors to zero with months of small, non-functional merge requests, so the build could finally enforce types.
Case study — building a broadcaster's streaming app for many TV platforms at Accedo. Memory and performance work for slow devices, a back-navigation model that finally made sense, a full rebrand, and a knowledge-sharing culture.
Put a layer between external APIs and your UI that parses raw responses into your own domain models, so a backend change touches one adapter instead of forty components.
One working directory per branch means no stashing, no reinstalling and no committing to the wrong branch — and it turns out to be exactly what parallel coding agents need too.
Intercept HTTP at the network layer so tests, Storybook and local development all hit realistic mocked APIs while your real fetching and parsing code runs.
React escapes what you put in JSX, so most XSS comes through the escape hatches — dangerouslySetInnerHTML, direct DOM writes, javascript URLs and third-party scripts. Defend in layers.
Put logic in plain functions and unit-test them; test hooks and pages as integration tests against a mocked network; assert only on what users can observe.
Mocking fetch or your own API modules couples tests to implementation and quietly re-implements your backend in every test file. Mock the network boundary instead.
For high-frequency socket data, write messages into a store and let only the leaf components subscribe — or skip React rendering entirely for the hottest values.
Not a boilerplate but a showcase of architecture patterns — organise a React app by feature, keep data access out of components, and wire in testing, mocking and error tracking from day one.
A reactive TypeScript backend where your server functions are the API, so front end and back end stay in sync. A natural fit for building with coding agents.
The best developer platforms feel like a good beginner programme — opinionated, safe, explained, and easy to leave once you know why.
For large network graphs, the rendering technology matters more than the API — DOM and SVG struggle past a few thousand nodes, canvas goes further, and WebGL stays interactive at 10k+.
A library shared across products never fits any one of them perfectly — ship structure and behaviour, and let each app own the styling.
End-to-end tests in real browsers with accessible locators, auth handled once via saved storage state, network control for deterministic runs, and traces that make CI failures debuggable.
You don't add 40kg to the bar overnight, and you don't rewrite a system in one go — small, steady, measured increases win both times.
Scan for leaks, rotate first, rewrite history with regex patterns rather than literal lists, and add a pre-commit scanner so it never happens again.
Specific Adaptation to Imposed Demands — you get good at exactly what you train. Systems and test suites do too, so make the training look like production.
Specific Adaptation to Imposed Demands — you get good at exactly what you practise. Tests and staging only prepare a system for the conditions they simulate.
Find defects where they're cheapest to fix, in refinement, the editor and the pull request. But shift-left means early feedback, not running every expensive test at the earliest stage.
SOLID translated into React habits — separate data from rendering, extend through composition, keep props minimal and depend on abstractions you pass in.
Components rendered in isolation, one story per state — living documentation, a test bench and a stakeholder demo in one. Most valuable when every requirement gets a story.
Red, green, refactor is less about tests than about tight feedback — and in the age of coding agents, a failing test is the clearest instruction you can give.
From 60 wpm hunt-and-peck to 100+ touch typing, a detour through Colemak and back, and the split-keyboard, mouse-free setup I use now.