4 logged considerations
Back to case index
CASE 003Investigation depth Architecture notes Evidence items
HaveItDiscussed
Live product buildFiled under Full-stack Product
Developer community client: discussions, threaded comments, likes, profiles, social graph, notification hub, and dark mode—deployed to Netlify against a separate Node API (`HaveItDiscussed-Server`).
Lab register
3 structural threads
3 collected signals
Jump to section
Case briefing
Section I
HaveItDiscussed is a user-facing React application aimed at programmers asking and answering questions in threads. The surface area spans feeds, thread detail, comments, reactions, profiles, friend requests, and a notification centre. Constraints included staying responsive on small viewports, keeping API access configurable via environment (local API vs deployed), and keeping feature work incremental as the platform evolved from an earlier version documented in the repo history.
Initial signal
Section II
Symptom
What broke first
The concrete failure mode was stale UI state after navigation: thread metadata and notification badges could disagree with the server because screens re-fetched independently without a shared notion of “current” entities, so users saw outdated reply counts or notification totals until a full reload—acceptable for a toy demo, unacceptable for something positioned as a living community product.
Evidence collected
Section III
Thread-centred navigation
The IA keeps discussions and replies as the primary path rather than burying collaboration under static pages.
Notification hub integrated with social actions
Comments, likes, and friend activity surface in one notification model instead of isolated widgets.
Live deployment as proof
Production deploy links and README install steps tie the repository to a usable product, not only source code.
Investigation path
Section IV
Traced from blended community features to a single failure mode: screens disagreeing after navigation because data lifecycles were not coordinated. Delivery detail stays under Resolution.
- Log 01
Identified the highest-churn data: thread lists, comment trees, like counts, and the notification hub. Ruled out pushing everything into global context without structure—that scales poorly— in favour of consistent fetch patterns and clear ownership per route.
- Log 02
Split client and server repositories deliberately: the client’s job is to render and orchestrate calls to the documented REST API; server pagination and auth rules stay authoritative.
- Log 03
Balanced feature breadth (friends, dark mode, notifications) with maintainability: responsive layouts and shared UI primitives reduce one-off CSS and breakpoint logic per view.
- Log 04
Used the live Netlify deployment as the acceptance surface: if the behaviour is not credible there, the implementation is not done.
Product tradeoffs
Tradeoff 01Structured state over ad hoc context
A single giant React context for every entity was ruled out; domain-shaped fetch ownership per route scales better as features grow.
Tradeoff 02Environment-configured API base
Pointing the client at `localhost:5000` or deploy targets via env keeps one codebase across local review and production without string forks.
Resolution
Section V
Journey note
Discover & read
Feeds and thread detail prioritise skimmable discussion metadata—reply depth, recency, and engagement cues—without fragmenting layout across breakpoints.
Product decision
Responsive rules live in the same components rather than parallel mobile routes so behaviour stays consistent when users move between phones and desktops.
Delivery actions
- Action 01
Structure the app around discussion and profile routes with shared layout and navigation so participation flows feel continuous.
- Action 02
Centralise API base URL through environment configuration so local development points at `localhost:5000` as documented in the README without code forks.
- Action 03
Implement notifications and reactions as first-class flows rather than bolt-on modals so engagement features reinforce the same thread model.
- Action 04
Keep mobile layouts in the same components with responsive rules instead of maintaining parallel mobile-only screens.
Architecture composition
- Structure 01
The client is a React SPA deployed statically; it talks to `HaveItDiscussed-Server` over HTTP for CRUD and auth. Boundaries follow domain areas: discussions, comments, likes, user profiles, friend graph, and notification delivery—each maps to API usage patterns the UI composes into pages.
- Structure 02
State is handled at the component and route level with an eye toward consistent refetch or invalidation after mutations (posting, liking, marking notifications read) so the failure mode above is addressed by design rather than ad hoc `window.location.reload()`.
- Structure 03
Cross-cutting UX—dark mode, responsive navigation, notification hub—uses shared styling and layout primitives so new screens inherit the same spacing and typography instead of fragmenting the product look.
Outcome
Section VI
Long-form result
The site is live on Netlify with public deploy status; the repository documents setup against the backend and highlights the feature set explicitly. The case shows full-stack product ownership on the client: community flows, identity, and notifications wired through a real API contract rather than mocked data.