标签：#Web

Building rich, collaborative web interfaces today requires much more than simply rendering components to the DOM. It demands rigorous planning around rendering performance, deterministic state management, and network resilience. In this article, I will break down the architectural decisions and trade-offs behind a real-time, enterprise-grade Kanban Board. Built with React 19, Vite, TypeScript, and Tailwind CSS, this application is designed to handle high data volumes via virtualization while maintaining a bulletproof, offline-first architecture. 🚀 Live Demo System Architecture: The Smart/Dumb Paradigm To guarantee scalability and testability, the application strictly adheres to the Container/Presentational (Smart/Dumb) design pattern. This ensures absolute separation of concerns. Containers (Smart): Orchestrate state access via Zustand, handle asynchronous actions, and manage event listeners. Presentational Components (Dumb): Pure, stateless functions exclusively concerned with UI rendering and accessibility. They receive data strictly via props. Unidirectional Data Flow: State mutations propagate downward from the global store, ensuring predictable render cycles. Here is the architectural topography of the system: Quality Attributes (NFRs) and Technical Decisions To ensure this MVP could scale into a production-ready product, the system was designed around strict Non-Functional Requirements (NFRs). Performance: DOM Virtualization & React 19 Paradigms Rendering 1,000+ DOM nodes concurrently destroys the framerate of standard React applications. We implemented client-side virtualization via @tanstack/react-virtual. By recycling DOM nodes and dynamically measuring element heights, the browser only renders the exact cards visible within the viewport, maintaining a steady 60fps during complex Drag-and-Drop operations. Furthermore, this codebase natively embraces React 19. It intentionally omits manual memoization (useMemo, useCallback, React.memo), relying entirely on t

The mental model that fixes everything JWT is just a token format . It is not authentication, not a session, and not a database. Once you separate those ideas, most of the pain disappears. A JWT is a JSON object that is signed. That's it. The payload holds claims like sub (subject) and exp (expiration). The signature proves the token wasn't tampered with. What JWT is not Not a session store : You can't revoke a JWT before it expires. If you need revocation, you need a blocklist or short expiry. Not a database : Don't stuff heavy data in the payload. It gets sent on every request. Not a magic bullet : It's a way to pass claims between parties without a shared server-side state. The three flows that matter 1. Access token only Simplest flow: login returns a JWT, client sends it in the Authorization header, server verifies it on every request. // server middleware (Express example) const jwt = require ( ' jsonwebtoken ' ); function auth ( req , res , next ) { const header = req . headers . authorization ; if ( ! header ) return res . status ( 401 ). json ({ error : ' No token ' }); const token = header . split ( ' ' )[ 1 ]; // Bearer <token> try { req . user = jwt . verify ( token , process . env . JWT_SECRET ); next (); } catch ( err ) { res . status ( 401 ). json ({ error : ' Invalid token ' }); } } Works fine for small apps, but every request hits your auth logic and the token can't be invalidated early. 2. Access + refresh token Common pattern for SPAs. Access token lives 15 minutes, refresh token lives 7 days. The refresh token is stored securely (httpOnly cookie) and used only to get a new access token. // issue tokens on login const accessToken = jwt . sign ({ userId }, process . env . JWT_SECRET , { expiresIn : ' 15m ' }); const refreshToken = jwt . sign ({ userId }, process . env . REFRESH_SECRET , { expiresIn : ' 7d ' }); res . json ({ accessToken }); res . cookie ( ' refreshToken ' , refreshToken , { httpOnly : true , secure : true , sameSite : ' strict ' })

When a user closes a tab, submits a form, or clicks an external link, you often need to send one last...

When I first started testing APIs, Postman was one of the first tools I reached for. It was...

Small business websites rarely fail because of one catastrophic bug. They fail from an accumulation of small, fixable problems — a slow hero image here, an unlabeled form field there, a broken tab order that quietly locks out keyboard users. None of it looks dramatic in a screenshot. All of it adds up to lost conversions. Working across client rebuilds and audits at Alynox, the same handful of issues show up repeatedly, regardless of industry. Here are ten of the most common, with the practical, mostly low-effort fixes that address them. Unoptimized Images Dragging Down Load Time The single most common performance killer on small business sites is still oversized images — a 4MB PNG hero banner exported straight from a design tool, served at full resolution to a phone screen 400px wide. Fix: html src="hero-800.webp" srcset="hero-400.webp 400w, hero-800.webp 800w, hero-1600.webp 1600w" sizes="(max-width: 600px) 400px, (max-width: 1200px) 800px, 1600px" alt="Interior of the workshop showing custom furniture in progress" loading="lazy" width="1600" height="900" /> Convert to WebP or AVIF, generate a handful of responsive sizes, lazy-load anything below the fold, and always set explicit width/height to reserve space and avoid layout shift. No Real Mobile-First Design A lot of "responsive" small business sites are really desktop layouts that get squeezed with media queries until they technically fit a phone screen. Buttons end up too small to tap accurately, text wraps awkwardly, and nav menus overlap content. Fix: Design and build mobile-first — base styles for small screens, then progressively enhance with min-width media queries for larger viewports: css .card { padding: 1rem; } @media (min-width: 768px) { .card { padding: 2rem; } } Tap targets should be at least 44×44px (per WCAG and Apple/Google HIG guidance), with enough spacing between interactive elements to prevent mis-taps on smaller screens. Accessibility Treated as an Afterthought Missing alt text, low-contras

Variable-size nodes break dagre's centering, first paint flickers, and straight chains render with kinked edges. Here is the why and the fix for each. Every React Flow and dagre tutorial shows the same thing: uniform gray boxes, laid out in a neat tree, everything centered. You copy the pattern, wire it up, and it works. Then you replace the gray boxes with real cards. A title that wraps to two lines. A card with a description and one without. And the layout starts to look subtly wrong: a parent sits off-center from its children, edges bend where they should be straight, and everything flashes in the top-left corner for a frame before jumping into place. I hit all three building an approval-workflow graph for a fintech app. The nodes were cards with variable content, so none of the fixed-size assumptions held. It took a while to understand that these are three separate bugs with three separate causes. So here is each one, why it happens, and the fix. At the end: the small package where I put all of it, so you do not have to rebuild this. Why dagre centers nodes off-balance (and the bounding-box fix) dagre centers a parent on the barycenter of its children, meaning the average of their center positions. That is correct when every child is the same size. It is visibly wrong when they are not. Concrete numbers from a graph I probed. A parent with two children, one 40px tall and one 200px tall. dagre puts the children at centers y=20 and y=180, so the parent lands at their average, y=100. But the visual middle of that group, the midpoint of the bounding box from the top of the small child to the bottom of the tall one, is y=140. The parent is 40px off from where your eye says it should be, and the taller the imbalance, the worse it gets. The fix is a post-pass on dagre's output: for every parent with two or more children, recompute its cross-axis position as the midpoint of the children's bounding box, walking deepest rank first so children settle before their parents.

Someone asked me to share meeting notes in Slack yesterday. I pasted the markdown. Slack ate the table. The code block lost its indentation. The task list rendered as literal [ ] characters. I spent five minutes reformatting something that already looked perfect in my editor. So I sent a link instead. Not to Notion — they would have to sign up. Not to Google Docs — same problem, plus I did not want this living in someone's Drive forever. Not to a pastebin — those are single blobs of text with no structure, no pages, no way to come back and fix a typo tomorrow. I wanted: one link, multiple pages, markdown that actually renders, no account required, and a way for me to edit it later without the URL changing. I have built sharing tools before. FreeShare for files. NotePage for single-page text. SharePad is what I wished existed when I needed something in between a pastebin and a wiki — but without the signup wall. Live here: https://sharepad.in Source: https://github.com/Varshithvhegde/sharepad SharePad — Share notes with one link, no signup Write a notebook of markdown pages and share it with a single link. Password lock, expiry dates, comments and PDF export. Free, and no account needed. sharepad.in The Idea Most "share your notes" products follow the same playbook. Create an account. Verify your email. Create a workspace. Invite people. Configure permissions. By the time you are done, the meeting is over and nobody cares about the notes anymore. SharePad skips all of that. You write markdown. You get two links: View link — /n/kitchen-reno — hand this out freely Edit link — /e/{secret-token} — this is your ownership credential. Do not share it. No account. No password to create (unless you want to lock the view link). No "upgrade to share with more people." The edit token is your identity for that notebook. That one decision — token-based ownership instead of user accounts — simplified everything else. No auth flows. No session management. No "forgot password" for th

If you compare live update solutions for long enough, you will run into a security claim that sounds decisive: "end-to-end encrypted." It suggests that solutions offering encryption are more secure than solutions that "only" sign their updates. That framing mixes up what the individual security controls in an update pipeline actually do. In this post, we walk through the threat model of live updates (also known as OTA updates or CodePush): what HTTPS already protects, what code signing guarantees, what encryption adds on top, and which of these properties matter for your app. By the end, you can evaluate the security of any live update solution based on facts instead of buzzwords. Key Takeaways HTTPS protects update bundles in transit. It does not protect against a compromised update service, storage bucket, or CDN. Code signing with a developer-held private key guarantees authenticity and integrity all the way to the device: even a fully compromised update infrastructure cannot inject code into your app. Encrypting bundles adds confidentiality only. It provides no additional protection against malicious updates. Client-side encryption cannot keep app code secret, because the decryption key must ship inside the app binary. The React Native maintainers state it plainly: "Code on the client is not secret." If bundles must stay confidential, for example in privately distributed enterprise apps, self-hosting them is a stronger control than encrypting them. The Trust Chain of a Live Update Every live update passes through the same chain: you build a web bundle in your CI/CD pipeline, upload it to an update service, the service stores and serves it (usually through a CDN), and the Live Update SDK in your app downloads and installs it. Security along this chain means three different properties: Authenticity : The update genuinely comes from you. Integrity : The update was not modified on the way. Confidentiality : No third party can read the update's content. For code that

Marketplace sellers often discover image problems too late. A product photo may look fine in an editor, but after uploading it to a marketplace it can become: cropped in search thumbnails too small for zoom previews the wrong aspect ratio for a sales channel risky for Amazon-style main image requirements awkward when reused across Etsy, Amazon, TikTok Shop, Shopify, eBay, or Walmart I wanted a simple preflight step before publishing product images, so I built ListingPic : 👉 https://listingpic.com/ What it does ListingPic is a browser-based marketplace image checker and resizer. You upload a product photo, choose the marketplaces you care about, and get a readiness report covering things like: image dimensions aspect ratio file type file size thumbnail crop risk safe-area positioning marketplace-specific warnings The goal is not to replace manual review. It is to catch obvious image risks before sellers waste time uploading, previewing, deleting, resizing, and re-uploading. Why local-first? A lot of product photos are sensitive: unreleased SKUs private product photography branded assets client images images sellers do not want copied or stored elsewhere So ListingPic processes images locally in the browser. Your images are not uploaded to our server for analysis. That also makes the tool fast for quick checks: drop in an image, review the warnings, adjust before publishing. Current checkers The MVP includes marketplace-focused checks for: general marketplace readiness Etsy image checks Amazon product image checks TikTok Shop image checks There are also entry points for Shopify, eBay, and Walmart workflows. Example use case Imagine you have one product photo and want to reuse it across multiple channels. ListingPic can help answer: Is the image large enough? Will the product be cut off in thumbnails? Is the image close enough to square for a channel that prefers square previews? Is the product too close to the edge? Do I need a separate crop for Etsy or TikTok Shop? D

Retries are normal in distributed systems. A caller may time out after the server commits a decision, a queue may redeliver a message, or a webhook sender may repeat an event. A decision API that treats every request as new can double-charge, duplicate actions, or record conflicting outcomes. Give each business operation a stable key The idempotency key should identify the logical business request, not a network attempt. Store it with a normalized request fingerprint, processing state, outcome, rule version, and response. If the same key arrives with a different payload, reject it rather than returning an unrelated prior result. Handle concurrent duplicates atomically Two workers can receive the same key before either writes a result. Use a unique constraint, transaction, or compare-and-set operation so only one execution owns the request. Other attempts should wait, return an in-progress response, or read the completed outcome according to the API contract. Choose retention from business risk A short cache may stop immediate duplicates but fail when a delayed queue redelivers. A permanent record may create unnecessary storage or privacy burden. Document key expiry and what happens if a key is reused after that boundary. Put side effects behind the idempotent boundary If rule evaluation triggers a message or database write, use a transactional outbox or equivalent pattern so the decision and pending event are committed together. Consumers still need their own deduplication because downstream delivery is often at least once. Return decision provenance Include the decision ID, status, rule artifact version, timestamp, and whether the response was replayed. Do not regenerate a result under a newer rule version for a duplicate key unless the caller explicitly requests a new business operation. Test the failure modes, not only the happy path Cover concurrent duplicates, payload mismatch, worker crash after commit, delayed redelivery, key expiry, and downstream retry. Obs

Building a Laravel application involves much more than writing PHP code. A production application needs to solve a real business problem, handle users and data reliably, survive deployments, remain secure, and continue to be maintainable as requirements change. Laravel provides an excellent foundation for building modern web applications, but the framework is only one part of the development process. A successful Laravel project typically moves through several stages, from understanding the original business idea to deploying, monitoring, and improving the application in production. Here is what that process looks like. 1. Start With the Business Problem Before thinking about controllers, models, databases, or cloud infrastructure, the first step is understanding what the application actually needs to accomplish. A project might begin with a simple request: "We need a customer portal." That's a starting point, but it isn't a specification. What should customers be able to do? Create and manage accounts? Upload documents? Manage subscriptions? Make payments? View reports? Communicate with employees? Receive notifications? Manage multiple users within an organization? These questions start turning an idea into actual application requirements. One of the easiest ways for a software project to become unnecessarily expensive is to begin development before the problem has been clearly defined. Laravel can make development faster, but building the wrong application faster doesn't solve the underlying problem. 2. Define the MVP Once the requirements become clearer, the next step is determining what belongs in the first release. I generally separate features into two categories: What does the application need in order to provide value? and What can be added later? The first category becomes the Minimum Viable Product, or MVP. For example, a new SaaS application might initially require: User registration Authentication Account management Subscription billing The application's

What is a Media Query? A media query is basically a condition in CSS. You tell the browser: IF the screen satisfies this condition, THEN apply these CSS rules. For example: @media (min-width: 768px) { .container { display: flex; } } Meaning: "If the viewport is at least 768px wide, make .container a flex container." So think: IF condition is TRUE ↓ apply these CSS rules 2. Why do we need Media Queries? Because users don't have one fixed screen. Your website could be opened on: 📱 Phone 375px wide 📱 Large phone 430px wide 📱 Tablet 768px wide 💻 Laptop 1366px wide 🖥️ Desktop 1920px wide You don't want to create five completely different websites. Instead: ONE HTML + BASE CSS + MEDIA QUERIES ↓ Responsive website 3. What does "Responsive" mean? Responsive means: The website adapts its layout and appearance according to the available screen/device size. `For example: Mobile [ Card ] [ Card ] [ Card ] [ Card ] but on desktop: [ Card ][ Card ][ Card ][ Card ]` Same HTML. CSS changes the layout. 4. The basic Media Query syntax The basic structure is: ``` @media media-type AND (condition) { /* CSS rules */ } For example: @media screen and (max-width: 600px) { body { background: lightblue; } } There are three important pieces: @media ↓ screen ↓ and ↓ (max-width: 600px) ↓ { CSS } Let's understand each one. 5. What is @media? @media tells CSS: "I'm about to write a media query." Example: @media (...) { } It's an at-rule in CSS. Similar CSS at-rules you'll eventually see: @media @import @font-face @keyframes For now, just remember: @media = start a media query 6. What are Media Types? You mentioned: screen / speech etc. YES. 👍 A media type tells CSS what kind of output/device the document is being presented on. Common media types include: screen For screens. Examples: 📱 Smartphone 📱 Tablet 💻 Laptop 🖥️ Desktop Example: @media screen and (max-width: 600px) { ... } print For printed documents / print preview. For example, your webpage looks like: Website [Header] [Navigation] [Button

If you build a full-screen mobile editor as a position: fixed overlay with a fixed toolbar on top and a nav bar on the bottom , iOS Safari will happily scroll your entire chrome off-screen the moment the soft keyboard opens — but only when the content is short . The fix isn't a JavaScript viewport dance. It's one line: .editor .ProseMirror { padding-bottom : 60vh ; } Give the inner scroll container something to scroll , and iOS keeps the scroll inside it instead of falling back to scrolling the document (which drags your "fixed" elements along). No html / body locking required. I hit this while building the mobile editor for PenPage , a local-first WYSIWYG markdown notes app (React + TipTap/ProseMirror). Everything below is verified on a real iOS device. The setup Picture a mobile note editor that takes over the whole screen: ┌──────────────────────────┐ │ Toolbar (absolute,top) │ ← stays put ├──────────────────────────┤ │ │ │ Editable content │ ← scrolls │ (overflow-y: auto) │ │ │ ├──────────────────────────┤ │ Nav bar (absolute,bottom)│ ← stays put └──────────────────────────┘ The outer container is position: fixed; inset: 0 . The toolbar and nav bar are position: absolute inside it. The middle is the only thing that scrolls. Standard app-shell layout. Works great on desktop and Android. The symptom Tap into the editor, the iOS keyboard slides up, and: Long document (taller than the viewport): perfect. The content scrolls under the keyboard, the toolbar and nav bar stay nailed in place. Short document (shorter than the viewport): broken. Trying to scroll drags the whole screen — toolbar and nav bar included — as if the entire fixed overlay were a normal scrolling page. That "only when short" detail is the whole story. The root cause This is the long tail of WebKit bug #191204 : when the soft keyboard appears, iOS Safari's layout viewport gets shorter than the visual viewport , and the document itself becomes scrollable by the keyboard's height. Worse, in that stat

Finding grants means digging through 50 scattered Discords, blogs, websites, and Notion pages. So I built a fix. Meet Web3 Accelerator GrantHub (W3AGH). What is GrantHub? GrantHub is a web app that helps Web3 founders discover funding opportunities without digging through dozens of scattered websites. Grants are listed across ecosystems like Solana, Ethereum, Polygon, BNB Chain, Arbitrum, Base, and more. The idea is simple: instead of spending hours searching for funding opportunities, you should be able to find relevant grants in one place. GrantHub also has AI tools that sit on top of the grant database. You can describe your project once and instantly see which grants fit best. Why GrantHub? Funding is the lifeblood of Web3 startups, but finding grants today is painful. Scattered listings Every ecosystem publishes its own programs on its own website, blog, Discord, or other channels. There is no single source of truth. Stale information Grants expire, close, or change their requirements, while the listings founders rely on can remain outdated. Manual matching A founder has to read through each grant's requirements and figure out whether their project qualifies. With dozens of grants available, that can quickly turn into hours of work. No personal workflow There is no single place to save interesting grants, track applications, or ask questions about a specific program. GrantHub is built around solving these problems. It combines three things: One central catalog of grants stored in a real database. Personal tools: accounts, favorites, and a personal dashboard. AI assistance: a grant ranking engine, an AI assistant, a smart-contract auditor, and context-aware chat on every grant page. Who is this for? Solo builders and startups: looking for funding or ecosystem support. Beginners who don't yet know which ecosystems and grants are right for them. Anyone who would rather spend their time building than hunting for funding. The goal isn't to create another directory o

DASTAN — The Taste of Home 🍲 This is my submission for the Frontend Challenge – Comfort Food Edition, Perfect Landing. What I Built For this challenge, I wanted to create something that felt more like a story than a typical food website. That idea became DASTAN — The Taste of Home . “Dastan” means a story, and the concept behind the project is simple: food is rarely just food. A dish can remind us of a person, a place, a family gathering, or a moment we haven't thought about in years. DASTAN is a visual, editorial-style landing page that explores comfort food from different parts of the world through photography, cultural stories, ingredients, and the people behind the memories. The goal was to make the experience feel warm, premium, and personal from the moment someone opens the page. The Idea The line that shaped the whole design was: Every culture has a taste of home. I wanted the website to communicate that feeling without relying on a traditional recipe-blog layout. Instead, I treated each dish almost like a magazine story. You can discover dishes from different regions, read the story behind them, and explore how food connects people across cultures. The Design I went for an editorial-inspired visual direction rather than a conventional modern dashboard. The design uses: Warm cream backgrounds Deep charcoal sections Muted gold accents Large serif typography Editorial-style food photography Rounded cards Generous spacing Strong visual hierarchy Story-focused content Subtle borders and details I wanted the interface to feel like opening a beautifully designed food magazine. At the same time, I made sure the experience remains comfortable to use on smaller screens. What You'll Find 🌍 Global Comfort Food DASTAN brings together dishes and stories from different parts of the world. Examples include: Tonkotsu Ramen — Japan Hyderabadi Dum Biryani — India Kimchi Jjigae — Korea Lasagna alla Bolognese — Italy Lahori Chicken Karahi — Pakistan Each one is presented as more

TypeScript 6.0 --noPropertyAccessFromIndexSignature : The Flag That Forces Honest API Contracts This article was written with the assistance of AI, under human supervision and review. The Silent Type Hole in Your Codebase Most runtime property access errors stem from index signatures pretending to guarantee properties they don't. Teams define Record<string, T> or { [key: string]: T } for objects where specific properties might not exist, then access those properties with dot notation as if the type system proved their presence. The compiler stays silent. Production crashes follow when the property is undefined. The --noPropertyAccessFromIndexSignature flag eliminates this false confidence. When enabled, TypeScript prohibits dot notation for properties defined only through index signatures. The type system forces bracket notation instead, making the uncertainty explicit at every call site. This distinction is critical—it transforms implicit runtime failures into compile-time enforcement of honest contracts. When developers adopt this flag, the contract becomes explicit. Index signatures signal "this property might not exist" and the syntax enforces that uncertainty. Explicit properties signal "this property is guaranteed" and dot notation confirms the guarantee. The codebase gains honesty. Key Takeaways The --noPropertyAccessFromIndexSignature flag prevents dot notation on properties defined only through index signatures, forcing bracket notation that signals uncertainty. Index signatures ( [key: string]: T ) describe unknown property sets; explicit properties describe guaranteed contracts—the flag enforces this semantic difference. Enabling this flag exposes implicit runtime failures as compile errors, converting production crashes into immediate feedback during development. The migration path involves converting dot access to bracket notation for index-signature properties while keeping dot notation for explicit properties. Combining this flag with --noUncheckedInd

Search "acf_register_block_type to block.json mapping" and you get tutorials. Each one converts a single testimonial block and calls it done. None of them hand you the full key-by-key table: every legacy PHP argument, its block.json destination, and the handful of settings that have no destination at all. I migrated forty-plus blocks across two client themes this year. Some keys moved with zero friction. Others sat in gray areas I only resolved by testing in the block editor and watching what broke. This is the matrix I wish existed before I started. Why the gap exists ACF's own documentation covers acf_register_block_type() on one page and the block.json acf key on another. Both pages are accurate. Neither cross-references the other. A developer migrating a block has to hold both pages open and manually match render_template to renderTemplate , post_types to postTypes , and so on. Miss one, and a block silently loses a feature instead of throwing an error. Three categories of keys make this worse: Renamed keys. Same feature, different casing, different location. snake_case becomes camelCase , and the key moves from the flat settings array into a nested acf object. Relocated keys. Some legacy settings aren't ACF-specific at all. They belong to WordPress's core block registration and move to the top level of block.json, outside the acf object entirely. Orphaned keys. A few legacy settings have no documented block.json equivalent. You either drop the behavior, replicate it with WordPress's native supports API, or handle it in your render template instead. The full matrix Legacy acf_register_block_type() key block.json location Notes name Top-level name Must be namespaced, e.g. acf/testimonial instead of testimonial title Top-level title Direct match description Top-level description Direct match category Top-level category Direct match icon Top-level icon Direct match, including the array form for background/foreground colors keywords Top-level keywords Direct match p

The worst test suite I ever inherited had 400 tests, and I trusted about six of them. The rest were either testing implementation details nobody cared about, duplicating each other, or so tightly coupled to internal function names that a harmless refactor broke thirty tests for no real reason. Reading that codebase taught me more about what not to do than any greenfield project ever has. So when you're starting from zero, the goal isn't "write a lot of tests fast." It's building a suite you'll still trust a year from now. If you're new to this, getting the software testing basics right early matters more than covering everything - learning how to build a first test suite from scratch teaches you what to prioritize in a way that inheriting someone else's bloated suite never will. Here's roughly how I'd approach it. Start with what would actually hurt if it broke Before writing a single test, list the handful of things that would be genuinely bad if they silently broke - checkout completing, auth working, the core thing your product does actually happening. Not every function, not every branch. Just the stuff where a silent failure costs you money, users, or trust. This list is usually shorter than people expect. Five to ten flows for most early-stage products. That's your actual test suite's job in the first few months, not "100% coverage." Unit tests for logic, not for plumbing Unit tests are for things with actual decision-making in them - pricing calculations, validation rules, state transitions, anything where "given this input, is the output correct" is a real question with a wrong answer possible. They're fast, they're cheap, and they should make up the bulk of your suite. Skip unit-testing pure plumbing: a function that just calls another function and returns its result doesn't need its own test. That's the kind of test that pads a coverage number without catching anything real, and it's exactly the kind of test that made that 400-test suite so hard to trust.

This is a submission for Frontend Challenge - Comfort Food Edition, Perfect Landing Most food...

Hoi hoi! I'm @nyaomaru, a frontend engineer who is trying to lose weight. 🐖🙀 I maintain a type...