# Coding Second Brain: React / TypeScript / Tailwind CSS **Role:** Frontend Developer · **Format:** Obsidian Markdown · **Weekly budget:** 5 hours --- ## 1. Knowledge Architecture ### Folder Structure ``` 📁 00-INBOX/ └── Daily captures (unsorted, triaged weekly) 📁 10-CONCEPTS/ ├── react/ │ ├── patterns/ ← compound components, render props, HOCs, hooks │ ├── performance/ ← memo, useMemo, useCallback, Suspense, transitions │ ├── state/ ← local, lifted, context, external stores │ └── accessibility/ ← ARIA roles, focus management, screen reader testing ├── typescript/ │ ├── generics/ │ ├── type-narrowing/ │ └── utility-types/ └── tailwind/ ├── design-tokens/ └── component-patterns/ 📁 20-PATTERNS/ ├── ui-patterns/ ← reusable UI architecture decisions ├── data-fetching/ ├── form-handling/ └── testing/ ← Vitest patterns, RTL conventions, mocking strategies 📁 30-IMPLEMENTATIONS/ ├── components/ ← specific component notes with code ├── hooks/ └── utilities/ 📁 40-PROJECTS/ ├── _template/ └── [project-name]/ ← ADRs, retrospectives, case study seeds 📁 50-OUTPUTS/ ├── blog-drafts/ ├── interview-prep/ └── portfolio-cases/ 📁 60-RESOURCES/ ├── articles/ ├── docs/ └── videos/ 📁 70-REVIEWS/ └── weekly-synthesis/ ← one file per week, links to processed captures ``` ### Tag Convention | Tag | Meaning | |-----|---------| | `#concept` | Foundational idea, not implementation-specific | | `#pattern` | Reusable solution to a recurring problem | | `#snippet` | Runnable code worth preserving | | `#adr` | Architecture Decision Record | | `#bug` | Debugging session notes | | `#resource` | External material reviewed | | `#gap/performance` | Known knowledge gap: React performance | | `#gap/a11y` | Known knowledge gap: Accessibility | | `#gap/testing` | Known knowledge gap: Vitest / testing | | `#output-ready` | Note mature enough to convert to an output | | `#spaced-rep` | Flagged for active recall review | ### Linking Logic ``` CONCEPT → links to → PATTERN (how it's applied) PATTERN → links to → IMPLEMENTATION (specific code) IMPLEMENTATION → links to → PROJECT (where it was used) PROJECT → links to → OUTPUT (blog, case study, interview card) RESOURCE → links to → CONCEPT or PATTERN (what it taught you) BUG → links to → CONCEPT (root cause) + IMPLEMENTATION (the fix) ``` **Obsidian tip:** Use a `MOC` (Map of Content) note per top-level domain (e.g., `react-MOC.md`) as the index. Link every note in that domain back to its MOC. This prevents orphan notes that never surface again. --- ## 2. Capture Templates ### Template 1 — New Concept Learned ```markdown --- tags: [#concept, #gap/<topic-if-applicable>] date: {{date}} domain: react | typescript | tailwind links: [] status: seedling | evergreen --- # Concept: [Name] ## What it is <!-- One sentence definition in your own words --> ## Why it matters <!-- Practical reason this exists. What problem does it solve? --> ## How it works <!-- Mechanism — code example or mental model --> ```tsx // Example ``` ## When to use vs. avoid | Use when | Avoid when | |----------|-----------| | | | ## Connections - Links to: [[]] - Contrasts with: [[]] ## Open questions - [ ] ## Source <!-- URL, book, video — link to resource note --> ``` **Fill-in example:** ```markdown --- tags: [#concept, #gap/performance] date: 2025-09-14 domain: react links: [react-MOC, useMemo] status: seedling --- # Concept: React.memo Bailout Conditions ## What it is React.memo skips re-rendering a component when its props are shallowly equal to previous render props. ## Why it matters Without it, every parent re-render triggers child re-renders even when child output is identical — wastes CPU on large lists or expensive components. ## How it works ```tsx const Avatar = React.memo(({ userId, size }: Props) => { // only re-renders if userId or size reference changes return <img src={getAvatar(userId)} width={size} />; }); ``` ## When to use vs. avoid | Use when | Avoid when | |----------|-----------| | Component is expensive to render | Props contain new object/array literals from parent | | Parent re-renders frequently | Component renders cheap JSX | ## Connections - Links to: [[useMemo]], [[useCallback]], [[react-performance-MOC]] - Contrasts with: [[PureComponent]] ## Open questions - [ ] Does React 19 compiler eliminate the need for manual React.memo? ## Source [[react-docs-compiler-review]] ``` --- ### Template 2 — Bug Solved / Debugging Session ```markdown --- tags: [#bug, #snippet] date: {{date}} severity: low | medium | high time-to-solve: Xh Ym --- # Bug: [Short description] ## Symptom <!-- What did you see? Error message, visual glitch, wrong value --> ## Environment - React version: - TS version: - Relevant libs: ## Initial hypothesis <!-- What did you think was wrong first? --> ## Root cause <!-- The actual problem — be precise --> ## Fix ```tsx // Before // After ``` ## Why this worked <!-- The mechanism. Don't just describe the fix — explain why it works --> ## Prevention <!-- How to avoid this class of bug in the future --> ## Connections - Root cause concept: [[]] - Related pattern: [[]] ``` **Fill-in example:** ```markdown --- tags: [#bug, #gap/testing] date: 2025-09-20 severity: medium time-to-solve: 0h 45m --- # Bug: Vitest fake timers break React state update assertions ## Symptom `expect(screen.getByText('Saved')).toBeInTheDocument()` fails intermittently when component uses `setTimeout` to show a success message. ## Environment - React version: 18.3 - TS version: 5.5 - Relevant libs: @testing-library/react 16, vitest 2.x ## Initial hypothesis Race condition in the test runner. ## Root cause `vi.useFakeTimers()` intercepts setTimeout but `act()` wrapper doesn't advance fake timers automatically. State updates inside the timeout never flush. ## Fix ```tsx // Before vi.useFakeTimers(); fireEvent.click(saveButton); expect(screen.getByText('Saved')).toBeInTheDocument(); // fails // After vi.useFakeTimers(); fireEvent.click(saveButton); await act(async () => { vi.advanceTimersByTime(500); }); expect(screen.getByText('Saved')).toBeInTheDocument(); // passes ``` ## Why this worked `act()` flushes the React update queue. Advancing fake timers inside `act()` ensures the setTimeout callback fires AND the resulting state update is committed before the assertion. ## Prevention When using `vi.useFakeTimers()`, always advance clocks inside `act()`. Add this to team testing conventions doc. ## Connections - Root cause concept: [[react-act-batching]] - Related pattern: [[vitest-async-testing-patterns]] ``` --- ### Template 3 — Code Snippet Worth Saving ```markdown --- tags: [#snippet, #pattern] date: {{date}} language: tsx | ts | css works-with: [react-18, typescript-5] --- # Snippet: [Descriptive name] ## What this does <!-- One line — the job this code performs --> ## The code ```tsx // Full, runnable snippet with types ``` ## Key decisions <!-- Why it's written this way — non-obvious choices --> ## Usage example ```tsx // How to drop it into a project ``` ## Gotchas <!-- Edge cases, things that break it --> ## Connections - Pattern: [[]] - Used in project: [[]] ``` **Fill-in example:** ```markdown --- tags: [#snippet, #pattern, #gap/a11y] date: 2025-10-01 language: tsx works-with: [react-18, typescript-5, tailwind-3] --- # Snippet: Focus trap hook for modal dialogs ## What this does Constrains keyboard focus inside a container element while mounted, restores prior focus on unmount. ## The code ```tsx import { useEffect, useRef } from 'react'; const FOCUSABLE = 'button,[href],input,select,textarea,[tabindex]:not([tabindex="-1"])'; export function useFocusTrap<T extends HTMLElement>() { const ref = useRef<T>(null); useEffect(() => { const el = ref.current; if (!el) return; const prior = document.activeElement as HTMLElement; const focusable = Array.from(el.querySelectorAll<HTMLElement>(FOCUSABLE)); focusable[0]?.focus(); const onKeyDown = (e: KeyboardEvent) => { if (e.key !== 'Tab') return; const first = focusable[0]; const last = focusable[focusable.length - 1]; if (e.shiftKey ? document.activeElement === first : document.activeElement === last) { e.preventDefault(); (e.shiftKey ? last : first).focus(); } }; el.addEventListener('keydown', onKeyDown); return () => { el.removeEventListener('keydown', onKeyDown); prior?.focus(); }; }, []); return ref; } ``` ## Usage example ```tsx function Modal({ onClose }: { onClose: () => void }) { const trapRef = useFocusTrap<HTMLDivElement>(); return ( <div ref={trapRef} role="dialog" aria-modal="true"> <button onClick={onClose}>Close</button> </div> ); } ``` ## Gotchas - Dynamic content: if focusable children are added after mount, the `focusable` array becomes stale. Re-run query inside handler if needed. - Portals: ensure `ref.current` is the portal container, not its trigger. ## Connections - Pattern: [[a11y-modal-pattern]] - Used in project: [[design-system-v2]] ``` --- ### Template 4 — Architecture Decision Record (ADR) ```markdown --- tags: [#adr] date: {{date}} project: [[]] status: proposed | accepted | deprecated | superseded superseded-by: --- # ADR-[NNN]: [Decision title] ## Context <!-- The situation and forces at play. What made this decision necessary? --> ## Decision <!-- What was decided, stated clearly in one sentence --> ## Options considered ### Option A: [Name] - Pros: - Cons: ### Option B: [Name] - Pros: - Cons: ## Rationale <!-- Why this option over the others? --> ## Consequences - Good: - Bad: - Neutral: ## Revisit trigger <!-- What event would prompt revisiting this decision? --> ``` **Fill-in example:** ```markdown --- tags: [#adr] date: 2025-10-05 project: [[dashboard-v3]] status: accepted --- # ADR-004: Use Zustand over Context API for global UI state ## Context Dashboard has 3 layers of context providers causing re-renders across 60+ components on every state update. Profiler shows 40ms render cycles on filter changes. ## Decision Replace UI state Context providers with a single Zustand store. ## Options considered ### Option A: Zustand - Pros: Selector-based subscription (only re-renders consumers of changed slice), minimal boilerplate, no Provider nesting - Cons: External dependency, team needs to learn new patterns ### Option B: Refactor Context with useMemo + split contexts - Pros: Zero new dependency, stays idiomatic React - Cons: Brittle, hard to enforce; root cause is architectural not just memoization ## Rationale Re-render count is the actual problem — useMemo treats symptoms. Zustand selectors fix the root cause and the API surface is small enough to learn in one session. ## Consequences - Good: ~70% reduction in unnecessary re-renders - Bad: One more dependency in the bundle (~1.1 kB gzipped) - Neutral: Devtools story slightly different (Zustand has its own devtools) ## Revisit trigger React compiler reaches stable release — may make selector-based subscriptions unnecessary. ``` --- ### Template 5 — Resource Review ```markdown --- tags: [#resource] date: {{date}} type: article | docs | video | course | talk url: author: rating: 1-5 time-invested: Xm --- # Resource: [Title] ## One-line summary <!-- What is this about in one sentence? --> ## Key takeaways <!-- 3–5 bullet points — your synthesis, not copy-paste --> 1. 2. 3. ## Quotes / highlights worth preserving <!-- Only if the exact phrasing matters — paraphrase otherwise --> ## What this changes for me <!-- How does this update my mental model or workflow? --> ## Action items - [ ] Try: - [ ] Write note on: [[]] - [ ] Apply to project: [[]] ## Connections - Reinforces: [[]] - Contradicts: [[]] - Leads to: [[]] ``` **Fill-in example:** ```markdown --- tags: [#resource, #gap/performance] date: 2025-10-12 type: article url: https://react.dev/reference/react/useTransition author: React team rating: 5 time-invested: 25m --- # Resource: useTransition — React official docs ## One-line summary useTransition marks state updates as non-urgent so React can interrupt them to handle higher-priority user input. ## Key takeaways 1. Transition updates don't block the UI — typing in an input stays responsive while a heavy list re-renders 2. `isPending` flag lets you show a loading state during the transition 3. Not a replacement for debounce — transitions still run, they're just interruptible 4. Server components: startTransition can wrap navigation in Next.js App Router ## What this changes for me I've been using debounce for search inputs — useTransition is a better primitive when the work is in React state, not a network call. ## Action items - [ ] Try: Replace debounced search filter in [[project-dashboard]] with useTransition - [ ] Write note on: [[react-concurrent-features]] - [ ] Apply to project: [[design-system-v2]] ## Connections - Reinforces: [[react-suspense-concept]] - Leads to: [[useDeferredValue-concept]] ``` --- ## 3. Knowledge Processing Pipeline ### Daily Inbox Triage (10 min/day) Run this every working day, ideally at end of day or morning: 1. Open `00-INBOX/` 2. For each note, ask **one question**: *"Is this raw capture or processed knowledge?"* - Raw → leave in INBOX, tag `#needs-processing` - Already has structure → move to correct folder now 3. Delete anything you won't use in 6 months 4. Mark any note that connects to a gap tag (`#gap/performance`, `#gap/a11y`, `#gap/testing`) with `#spaced-rep` **Time limit: hard stop at 10 minutes.** Don't process — just sort. --- ### Weekly Synthesis Session (60 min, fits in your 5 hr budget) Schedule: **Sunday evening or Monday morning**, 60 minutes fixed. **Structure:** | Time | Activity | |------|----------| | 0–10m | Process INBOX — move and tag everything captured this week | | 10–30m | Write or upgrade ONE evergreen note (seedling → evergreen) | | 30–45m | Link audit — open any note marked `#needs-link` and add 2 backlinks | | 45–55m | Create this week's synthesis note in `70-REVIEWS/weekly-synthesis/YYYY-WNN.md` | | 55–60m | Update gap review queue (see below) | **Weekly synthesis note template:** ```markdown # Week YYYY-WNN Synthesis ## Captured this week - N new concepts, N bugs, N snippets ## Best insight <!-- One thing that shifted your thinking --> ## Gap progress - performance: - a11y: - testing: ## This week's output candidate <!-- One note that's close to #output-ready --> ## Next week focus <!-- One thing to intentionally learn --> ``` --- ### Spaced Repetition Trigger System For your three gap areas, use a lightweight rotation — not a full SRS app. Inside Obsidian, maintain this file: **`70-REVIEWS/gap-review-queue.md`** ```markdown ## Performance (review every 2 weeks) - [ ] [[react-memo-bailout]] — due: 2025-10-14 - [ ] [[virtualization-windowing]] — due: 2025-10-28 - [ ] [[profiler-workflow]] — due: 2025-11-04 ## Accessibility (review every 2 weeks) - [ ] [[aria-roles-cheatsheet]] — due: 2025-10-18 - [ ] [[focus-management-patterns]] — due: 2025-11-01 ## Vitest / Testing (review every 10 days — highest forgetting risk) - [ ] [[vitest-async-patterns]] — due: 2025-10-11 - [ ] [[msw-handler-conventions]] — due: 2025-10-21 - [ ] [[rtl-query-priority]] — due: 2025-10-31 ``` **Review cadence by topic:** | Topic | Interval | Rationale | |-------|----------|-----------| | React performance | 2 weeks | Mental models are stable; application needs practice | | Accessibility | 2 weeks | ARIA spec is stable; forgetting happens between projects | | Vitest / testing | 10 days | Syntax is highly forgettable without daily use | **Trigger rule:** Every Sunday synthesis, scan the queue. Any note past its due date gets a 5-minute active recall session: close the note, write what you remember, then open and check. Extend due date by the same interval. --- ## 4. Content & Output Layer ### Output Type 1 → Blog Post **Source notes:** `10-CONCEPTS/` + `20-PATTERNS/` when status = `evergreen` and tagged `#output-ready` **Mapping:** - Concept note → "What I learned about X" post - Pattern note → "How I solve Y problem in React" post - Bug note → "Debugging X in React 18" post (highest SEO value for developer audiences) **Workflow:** 1. When a note reaches `evergreen`, add `#output-ready` 2. During weekly synthesis, identify 1 candidate 3. Move a copy to `50-OUTPUTS/blog-drafts/` 4. Expand with: intro context, reader payoff, code examples, conclusion CTA 5. Publish target: **dev.to** or your personal site (builds technical writing credibility) **Quality gate:** If you can't explain the concept without looking at your notes, it's not ready to publish. Write one more synthesis session first. --- ### Output Type 2 → Interview Prep Cards **Source notes:** `10-CONCEPTS/react/patterns/` + `10-CONCEPTS/react/performance/` + `20-PATTERNS/testing/` **Mapping:** - Every concept note with `status: evergreen` → one interview card - Card format: Question on front, your synthesized answer (no code) on back **Card template:** ```markdown # Interview Card: [Topic] ## Question [Interviewer-style question — open-ended] ## Key answer points (no code) 1. 2. 3. ## Follow-up they might ask - ## Code example to draw on → [[snippet-note]] ``` **Storage:** `50-OUTPUTS/interview-prep/` — one file per domain (react-patterns.md, performance.md, testing.md) --- ### Output Type 3 → Portfolio Case Studies **Source notes:** `40-PROJECTS/[project-name]/` ADRs + implementation notes + bug notes **Mapping:** - ADRs → "Problem & Decision" section - Bug notes → "Challenges" section - Implementation notes → "Technical approach" section **Case study structure:** ```markdown # Case Study: [Project Name] ## Problem <!-- 2–3 sentences — what were you solving? --> ## Technical decisions <!-- Pull from ADRs — frame each as a tradeoff you navigated --> ## Interesting challenge <!-- One bug or architectural problem — from bug notes --> ## Outcome <!-- Measurable or observable result --> ## What I'd do differently ``` **Publish to:** GitHub README, personal portfolio site, or LinkedIn article — all build the "confident technical writer" goal. --- ## 5. 60-Day Implementation Roadmap ### Week 1–2: Scaffold **Week 1 — Build the vault structure** - Task: Create all folders and tags in Obsidian exactly as specified in Section 1. Create your 3 MOC files (react-MOC, typescript-MOC, tailwind-MOC). - Success metric: Zero orphan notes possible — every folder exists, every MOC is linked. **Week 2 — Install templates** - Task: Add all 5 capture templates to Obsidian as Templater templates. Create `gap-review-queue.md` with 3 entries per gap topic. - Success metric: You can create any template type in under 10 seconds from the command palette. --- ### Week 3–4: Capture Habit **Week 3 — First capture week** - Task: Capture at least 5 notes this week using templates. Don't process — just capture using the correct template. - Success metric: 5 notes in INBOX by end of week, all with correct tags. **Week 4 — First triage week** - Task: Run daily inbox triage every weekday. Do your first weekly synthesis session. - Success metric: INBOX is empty by Sunday. One note upgraded from `seedling` to `evergreen`. --- ### Week 5–6: Processing Ritual **Week 5 — First spaced repetition cycle** - Task: Review all notes tagged `#spaced-rep`. Update `gap-review-queue.md` with due dates. Complete one active recall session for each gap area. - Success metric: Every gap topic has at least 2 notes with due dates assigned. **Week 6 — Link density sprint** - Task: Open every note in `10-CONCEPTS/` and ensure it has at least 2 outgoing links. - Success metric: No concept note has zero links. Graph view shows a connected cluster, not isolated nodes. --- ### Week 7–8: First Outputs **Week 7 — First blog draft** - Task: Identify the most mature evergreen note. Write a 400-word blog draft in `50-OUTPUTS/blog-drafts/`. - Success metric: Draft exists and covers: hook, explanation, code example, takeaway. **Week 8 — Publish + build interview deck** - Task: Publish the blog post. Create `50-OUTPUTS/interview-prep/react-patterns.md` with 5 interview cards. - Success metric: Published post URL exists. 5 cards written in your own words (no copy-paste from notes). --- ## 6. Stack-Specific Tool Recommendations ### Tool 1 — Obsidian Templater Plugin **Why it fits:** Generic text templates aren't enough — Templater runs JavaScript at template insertion time, which means your templates can auto-populate today's date, prompt you for the domain tag, and auto-link to the right MOC. **Configuration:** ```javascript // In your "New Concept" template, add to frontmatter: date: <% tp.date.now("YYYY-MM-DD") %> domain: <% tp.system.prompt("Domain? (react/typescript/tailwind)") %> // Auto-link to MOC: links: [[<% tp.frontmatter.domain %>-MOC]] ``` **Install:** Settings → Community plugins → Templater. Set template folder to a `_templates/` directory in your vault root. --- ### Tool 2 — Vitest UI + Istanbul Coverage Reports **Why it fits:** Your `#gap/testing` notes will be much more concrete if you run coverage reports and capture gaps as actionable notes. Vitest UI gives you a browser-based test runner that makes debugging async test failures (like the fake timers bug above) dramatically faster. **Configuration:** ```ts // vitest.config.ts export default defineConfig({ test: { ui: true, // opens browser UI at localhost:51204 coverage: { provider: 'istanbul', reporter: ['text', 'html'], include: ['src/**/*.{ts,tsx}'], thresholds: { lines: 80, functions: 80 } } } }); ``` **Integration with Second Brain:** After each coverage run, open the HTML report. Any file under 80% → create a `#gap/testing` note. Link it to the relevant component's implementation note. --- ### Tool 3 — TypeScript Error Lens (VS Code) + ts-reset **Why it fits:** Two separate tools that compound. Error Lens surfaces TS errors inline without hovering — you see type errors as you write, which generates more real debugging sessions worth capturing. `ts-reset` (by Matt Pocock) resets several surprising TypeScript defaults (e.g., `.json()` returns `unknown` instead of `any`), which forces you to confront type narrowing — a key TypeScript learning area. **Error Lens config:** ```json // .vscode/settings.json { "errorLens.enabledDiagnosticLevels": ["error", "warning", "info"], "errorLens.followCursor": "allLines", "errorLens.delay": 300 } ``` **ts-reset setup:** ```ts // src/reset.d.ts — add one file, no imports needed elsewhere /// <reference types="@total-typescript/ts-reset" /> ``` **Integration with Second Brain:** When `ts-reset` breaks existing code (it will), that's a note. Every broken assumption → one concept note in `10-CONCEPTS/typescript/type-narrowing/`. --- ## 7. Anti-Pattern Warnings ### Anti-Pattern 1 — The Collection Trap **What it looks like:** 200 notes in INBOX, zero evergreen notes. You feel productive because you're capturing constantly, but nothing is being processed. **Why it happens:** Capturing is easy and feels like learning. Processing requires cognitive effort. **Fix in this system:** Hard rule — INBOX never exceeds 20 notes. If it does, cancel the next capture session and run a synthesis session instead. The weekly synthesis cadence is not optional. --- ### Anti-Pattern 2 — Copying Instead of Synthesizing **What it looks like:** Notes that are just copy-pasted documentation with no personal insight. **Why it happens:** It's faster to copy than to think. But copied notes have no retrieval value — you can't search your memory for something you never processed. **Fix in this system:** The "Why it matters" and "What this changes for me" fields in each template force you to generate personal meaning. If you can't fill them in, you don't understand the concept yet — read more before capturing. --- ### Anti-Pattern 3 — Infinite Refinement, Zero Publishing **What it looks like:** 15 `evergreen` notes, zero published posts. Every note has one more "open question" before it's ready. **Why it happens:** Publishing feels final and risky. Refining notes feels safe. **Fix in this system:** The 60-day roadmap hard-gates a publish at Week 8. The quality gate is concrete: "Can you explain this without the notes?" If yes, it's ready. Perfect is the enemy of shipped. --- ### Anti-Pattern 4 — One Giant Note Per Topic **What it looks like:** `react-everything.md` — a 4,000-word document covering hooks, patterns, performance, and testing. **Why it happens:** Feels organized. Is actually unsearchable and impossible to link atomically. **Fix in this system:** One concept per note, enforced by the template structure. If a note exceeds 400 words, it should probably be two notes. Use links instead of sections within a single note. --- ### Anti-Pattern 5 — Ignoring the Gap Tags **What it looks like:** You have `#gap/testing` notes but only write about React patterns because they're more comfortable. **Why it happens:** We naturally gravitate to our strengths. Second Brains mirror that bias if unchecked. **Fix in this system:** The weekly synthesis template has a mandatory "Gap progress" section. You must write something for each gap topic every week — even if it's "no progress, moved due date." This makes avoidance visible rather than invisible. --- *System version: 1.0 · Built for Obsidian · React 18+ / TypeScript 5+ / Tailwind CSS 3+*