Frontend Component and State Architecture Questions

High-level approach

Use an offline-first client with Service Worker + Background Sync for retries, IndexedDB as single source-of-truth, an operation queue (op-log) persisted in IndexedDB, optimistic UI updates, server-side versioning, and conflict resolution strategies (merge or manual).

Storage choices

• IndexedDB (via idb or localForage) for documents, metadata, and the op queue — durable, large, works offline.
• Cache API / blob storage for attachments.
• In-memory indices for UI performance; rebuild from IndexedDB on startup.

Queue format (op-log item)

• id (uuid), docId, type (create/edit/delete), payload (delta or full), baseVersion (server version client knew), clientTs, retryCount, backoffUntil, status (pending/processing/failed).
• Use deltas (patches) for small ops; occasionally emit full snapshot to simplify recovery.

Retry & backoff

• Background Sync + periodic sync when online.
• Exponential backoff:
  • backoffMs = base * 2^retryCount + jitter
  • update backoffUntil; stop after maxRetries => mark failed and surface to user.
• Use BroadcastChannel or postMessage to update open tabs.

Conflict detection & resolution

• Detect: server responds with 409 + currentVersion or returns divergent patches.
• Strategies:
  • For structured documents, use CRDT (Automerge/Yjs) to auto-merge.
  • For text-only, use OT/CRDT library or three-way merge using baseVersion + client patch.
  • Fallback: present human-readable diff and allow the user to accept/merge.
• Always store both server and local versions so UI can show a conflict view.

UI feedback

• Per-document status badges: Pending (spinner), Syncing, Synced (green), Failed (red), Conflict (yellow).
• Inline indicators for specific fields changed offline.
• Actionable conflict modal: show local vs server, quick-merge suggestions, accept server/local, or manual edit.
• Toasts for global sync errors and progress bar for batch sync.

Bounding queue size

• Collapse ops: consolidate consecutive edits to same doc into one op (apply patch squashing).
• Periodic snapshotting: after N ops compress into a single snapshot and remove prior ops.
• Hard caps (e.g., 500 ops or X MB): when reached, evict oldest non-critical ops or prompt user to sync/clear.
• Respect browser storage quota APIs; surface warnings if nearing quota.

Why this works (frontend perspective)

• IndexedDB + Service Worker gives durable offline UX; optimistic updates keep UI responsive; op-log + versioning makes sync deterministic; CRDT/merge strategies reduce manual conflict load; UI signals keep users informed and able to act.

Approach (overview)

I would instrument the component to count renders during the user flow, drive the flow in an automated test, and assert the count ≤ N. Tools: React Testing Library + user-event for interactions, Jest for assertions, and React's Profiler or an internal render counter for precision.

Detailed steps

• Add a non-invasive render counter (useRef or Profiler callback) exposed only in test builds.
• Write an RTL test that mounts the parent, performs user interactions wrapped in act/userEvent, then reads the counter and asserts.

Example test (Jest + React Testing Library)

// MyPanel.test.js
import { render, screen } from '@testing-library/react';
import userEvent from '@testing-library/user-event';
import MyPanel from './MyPanel';

test('does not re-render MyPanel more than N times during expand/collapse', async () => {
  const user = userEvent.setup();
  // MyPanel increments window.__renderCounts.MyPanel on each render (test-only)
  render(<MyPanel />);
  const toggle = screen.getByRole('button', { name: /toggle panels/i });

  // perform interactions
  await user.click(toggle);
  await user.click(toggle);
  await user.click(toggle);

  const count = window.__renderCounts?.MyPanel ?? 0;
  expect(count).toBeLessThanOrEqual(5); // N = 5
});

Notes & trade-offs

• Using React Profiler offers production-like metrics but is harder to read per-component in tests.
• Keep test-only instrumentation gated (process.env.NODE_ENV === 'test').
• Ensure interactions are awaited and wrapped in act to avoid async flakiness.

What a stale closure is (concise)

A stale closure happens when a function captures variables from an earlier render and keeps referencing that old value later—common with useEffect, event handlers, or timers—so updates to state aren't seen by the closure.

Example (stale closure with setInterval)

import { useState, useEffect } from "react";

function Counter() {
  const [count, setCount] = useState(0);

  useEffect(() => {
    const id = setInterval(() => {
      // This closure closes over the initial `count` value -> stale
      console.log("count:", count);
      setCount(count + 1);
    }, 1000);
    return () => clearInterval(id);
  }, []); // empty deps -> closure never sees later `count`
  return <div>{count}</div>;
}

Two practical fixes

• Add dependencies / use fresh props: include count in the effect deps or recreate the callback so it captures latest state:
  • useEffect(() => { ... }, [count])
• Use functional updates or refs to avoid relying on closed-over value:
  • setCount(c => c + 1) or store mutable latest value in useRef and read ref.current inside the closure

Both approaches ensure the closure uses up-to-date state.

Approach (brief)
For unit tests, mock the browser APIs at the Jest setup level or per-test to control callbacks and assert behavior. For E2E, prefer real browser behavior but provide polyfills or graceful fallbacks in the app so tests run across environments.

Jest mocks — examples

IntersectionObserver (setupTests.js):

// setupTests.js
class MockIntersectionObserver {
  constructor(cb) { this.cb = cb; }
  observe() { /* no-op */ }
  unobserve() { /* no-op */ }
  disconnect() { /* no-op */ }
  // helper to simulate entries:
  trigger(entries) { this.cb(entries, this); }
}
global.IntersectionObserver = MockIntersectionObserver;

window.matchMedia (per-test or setup):

// setupTests.js
Object.defineProperty(window, 'matchMedia', {
  writable: true,
  value: (query) => ({
    matches: false,
    media: query,
    addListener: () => {},
    removeListener: () => {},
    addEventListener: () => {},
    removeEventListener: () => {},
    dispatchEvent: () => false,
  }),
});

ResizeObserver (simple mock):

global.ResizeObserver = class {
  constructor(cb) { this.cb = cb; }
  observe() {}
  unobserve() {}
  disconnect() {}
  // test helper:
  trigger(entries) { this.cb(entries); }
};

How to use in tests

• Import your component, call mock.trigger([...]) to simulate intersection/resize events and assert side effects.
• Keep mocks minimal and deterministic; reset them between tests.

E2E strategies & graceful degradation

• Detect feature availability at runtime:
  • Use feature detection (if ('IntersectionObserver' in window) { use it } else { fallback })
  • Expose fallbacks (throttled scroll listeners) so app behavior remains testable.
• For E2E in CI:
  • Use real browsers (Playwright/Puppeteer) that support APIs.
  • Inject polyfills before app loads if target browser lacks API (serve polyfill bundle or set browser flags).
  • Optionally add a test hook: window.__TEST_FORCE_NO_IO = true to exercise fallback code paths.
• Document and test both primary and fallback paths.

Why this works

• Unit mocks give deterministic, fast tests focused on component logic.
• Graceful degradation and E2E in real browsers ensure production parity and catch integration issues.

Approach (brief)

We create generic types that map an 'as' component to its intrinsic props, merge them with our custom Button props, omit conflicting keys, and forward refs with correct type. Use Omit + intersection and conditional types to compute prop shapes.

Types

import React from "react";

type AsProp<E extends React.ElementType> = { as?: E };

// ref type for element E
type PolymorphicRef<E extends React.ElementType> =
  React.ComponentPropsWithRef<E> extends { ref?: React.Ref<infer R> } ? R : never;

// merge intrinsic props of E with our custom props P, giving precedence to P
type PolymorphicProps<E extends React.ElementType, P> =
  P & Omit<React.ComponentPropsWithoutRef<E>, keyof P> & AsProp<E>;

Core implementation sketch

type ButtonOwnProps = {
  variant?: "primary" | "ghost";
  children?: React.ReactNode;
};

type ButtonProps<E extends React.ElementType = "button"> =
  PolymorphicProps<E, ButtonOwnProps>;

const Button = <E extends React.ElementType = "button">(
  { as, variant = "primary", children, ...rest }: ButtonProps<E>,
  ref: React.Ref<PolymorphicRef<E>>
) => {
  const Component = (as || "button") as React.ElementType;
  return (
    <Component
      // apply className based on variant, preserve callers' props
      {...(rest as unknown)}
      ref={ref as any}
      data-variant={variant}
    >
      {children}
    </Component>
  );
};

const PolymorphicButton = React.forwardRef(Button) as <
  E extends React.ElementType = "button"
>(
  props: ButtonProps<E> & { ref?: PolymorphicRef<E> }
) => React.ReactElement | null;

How merging works (why safe)

• We start from React.ComponentPropsWithoutRef<E> to get intrinsic props for the chosen element/component.
• Omit<..., keyof P> removes keys that our custom props declare (so our props take precedence and avoid type conflicts).
• Intersection with P adds custom props.
• AsProp allows switching the rendered element.
• PolymorphicRef infers the correct ref target so consumers using ref get proper type (HTMLButtonElement, HTMLAnchorElement, or component instance).
• Using ComponentPropsWithoutRef ensures event handlers and HTML attributes are available for the selected 'as' element.

Edge cases / notes

• For components with required props, callers must supply them; you can tighten types to require specific props when 'as' is a particular component.
• For styled systems, ensure className merging and aria propagation are handled.
• Tests: verify ref types and TS inference for common usages:
  • <PolymorphicButton onClick=...> defaults to button
  • <PolymorphicButton as="a" href="..."> infers anchor props
  • <PolymorphicButton as={Link} to="..."> infers Link props