Untuk subtree ini, dependency/value/capability apa yang berlaku?

Di mana saya bisa menaruh semua state supaya mudah diakses dari mana saja?

function App() {
  return <Shell theme="dark" currentUser={user} />;
}

function Shell({ theme, currentUser }) {
  return <Sidebar theme={theme} currentUser={currentUser} />;
}

function Sidebar({ theme, currentUser }) {
  return <UserMenu theme={theme} currentUser={currentUser} />;
}

function UserMenu({ theme, currentUser }) {
  return <Avatar user={currentUser} theme={theme} />;
}

Shell tidak memakai theme, tetapi harus menerima dan meneruskannya.
Sidebar tidak memakai currentUser, tetapi harus tahu prop itu ada.
Layout boundary ikut berubah hanya karena descendant butuh dependency baru.

const ThemeContext = createContext<Theme | null>(null);
const SessionContext = createContext<Session | null>(null);

function App() {
  return (
    <ThemeContext value="dark">
      <SessionContext value={session}>
        <Shell />
      </SessionContext>
    </ThemeContext>
  );
}

function Avatar() {
  const theme = useRequiredContext(ThemeContext);
  const session = useRequiredContext(SessionContext);

  return <img className={`avatar avatar-${theme}`} src={session.user.avatarUrl} />;
}

Satu instance global.
Bisa dibaca banyak tempat.
Bisa diubah banyak tempat.
Umurnya biasanya sepanjang aplikasi.
Tidak selalu mengikuti struktur UI tree.

Value berlaku hanya untuk subtree di bawah provider.
Provider dapat di-nest dan dioverride.
Consumer membaca provider terdekat di atasnya.
Value mengikuti komposisi tree.
Satu context bisa punya banyak value berbeda di subtree berbeda.

<ThemeContext value="light">
  <MarketingPage />

  <ThemeContext value="dark">
    <AdminConsole />
  </ThemeContext>
</ThemeContext>

Provider terdekat untuk Context ini siapa?
Value yang berlaku di scope saya apa?

Lexical variable scope:
  block terdalam menang.

React context scope:
  provider terdekat di ancestor tree menang.

Context object  : identitas channel dependency.
Provider        : menentukan value untuk subtree.
Consumer        : membaca value provider terdekat.

import { createContext, useContext } from 'react';

type Theme = 'light' | 'dark';

const ThemeContext = createContext<Theme | null>(null);

function ThemeProvider({ children }: { children: React.ReactNode }) {
  return <ThemeContext value="dark">{children}</ThemeContext>;
}

function useTheme() {
  const theme = useContext(ThemeContext);

  if (theme === null) {
    throw new Error('useTheme must be used inside ThemeProvider');
  }

  return theme;
}

function Button() {
  const theme = useTheme();
  return <button data-theme={theme}>Save</button>;
}

Context object tidak menyimpan state.
Provider menyediakan value.
Consumer subscribe terhadap value provider terdekat.
Default value dipakai hanya ketika tidak ada provider di atas consumer.

ThemeContext adalah tempat menyimpan theme.

ThemeContext adalah channel untuk membaca theme yang berlaku pada subtree ini.

const ThemeContext = createContext('light');

const AuthContext = createContext<AuthContextValue>({
  user: null,
  login: async () => {},
  logout: async () => {},
});

type AuthContextValue = {
  user: User | null;
  login(input: LoginInput): Promise<void>;
  logout(): Promise<void>;
};

const AuthContext = createContext<AuthContextValue | null>(null);

function useAuth() {
  const value = useContext(AuthContext);

  if (value === null) {
    throw new Error('useAuth must be used inside AuthProvider');
  }

  return value;
}

Optional context boleh punya fallback bermakna.
Required context sebaiknya fail fast jika provider tidak ada.

const DensityContext = createContext<'comfortable' | 'compact'>('comfortable');

const CaseWorkflowContext = createContext<CaseWorkflowApi | null>(null);

Theme
Locale
i18n formatter
Feature flags
Permission/capability set
Analytics adapter
Router/navigation API
Form field registry
Modal manager
Design system configuration
Workflow command API

boleh membaca permission?
boleh membuka modal?
boleh dispatch event workflow?
boleh mengirim analytics?
boleh resolve translation?
boleh melakukan navigation?

type CaseActions = {
  approve(caseId: string): Promise<void>;
  reject(caseId: string, reason: string): Promise<void>;
  escalate(caseId: string, targetQueue: string): Promise<void>;
};

const CaseActionsContext = createContext<CaseActions | null>(null);

function useCaseActions() {
  const actions = useContext(CaseActionsContext);

  if (!actions) {
    throw new Error('useCaseActions must be used inside CaseActionsProvider');
  }

  return actions;
}

function ApproveButton({ caseId }: { caseId: string }) {
  const { approve } = useCaseActions();

  return <button onClick={() => approve(caseId)}>Approve</button>;
}

// Global import
import { analytics } from '@/infra/analytics';

function SaveButton() {
  return <button onClick={() => analytics.track('save_clicked')}>Save</button>;
}

function SaveButton() {
  const analytics = useAnalytics();
  return <button onClick={() => analytics.track('save_clicked')}>Save</button>;
}

<AnalyticsContext value={productionAnalytics}>
  <App />
</AnalyticsContext>

<AnalyticsContext value={testAnalytics}>
  <StorybookScenario />
</AnalyticsContext>

Mudah dites.
Mudah dioverride per subtree.
Tidak tergantung singleton global.
Lebih mudah untuk multi-tenant/multi-workspace UI.
Lebih cocok untuk Storybook dan integration test.

<FormFieldContext value={{ fieldId, errorId, describedBy }}>
  <Label>Email</Label>
  <Input />
  <ErrorMessage />
</FormFieldContext>

function Input(props: React.ComponentProps<'input'>) {
  const field = useFormField();

  return (
    <input
      id={field.fieldId}
      aria-invalid={field.hasError}
      aria-describedby={field.describedBy}
      {...props}
    />
  );
}

Value dibutuhkan oleh banyak descendant.
Passing props melewati banyak komponen tengah hanya membuat noise.
Value berlaku untuk subtree tertentu.
Provider override per subtree berguna.
Value relatif stabil atau update frequency rendah.
Dependency lebih tepat di-inject daripada di-import global.
Komponen consumer memang secara konseptual berada dalam scope provider.

ThemeProvider
LocaleProvider
AuthSessionProvider
PermissionProvider
FeatureFlagProvider
RouterProvider
FormProvider
TabsProvider
MenuProvider
ModalProvider
WorkflowProvider

Value sering berubah sangat cepat.
Consumer hanya butuh slice kecil dari object besar.
Banyak component membaca context tetapi tidak perlu rerender bersamaan.
State butuh selector granular.
State butuh devtools/time-travel/action log.
State sebenarnya server/cache state.
State harus survive di luar tree lifecycle.
State perlu subscription eksternal yang aman terhadap concurrent rendering.

Mouse position realtime.
Input keystroke global.
Large normalized entity store.
Query cache.
Collaborative document state.
High-frequency websocket feed.
Complex workflow dengan banyak actor terpisah.

useSyncExternalStore-based store
Zustand
Redux Toolkit
TanStack Query
XState actor model
URL state
local component state

Props first.
Composition when structure is the problem.
Context when dependency passing is the problem.
External store when subscription granularity and state lifecycle are the problem.
Server cache when data ownership is remote.
State machine when workflow correctness is the problem.

function DeleteCaseButton({ caseId }: { caseId: string }) {
  const permissions = useContext(PermissionContext);
  const workflow = useContext(WorkflowContext);
  const audit = useContext(AuditContext);
  const modal = useContext(ModalContext);
  const toast = useContext(ToastContext);

  // ...
}

<DeleteCaseButton caseId="C-123" />

function DeleteCaseButton({ caseId }: { caseId: string }) {
  const deleteCase = useDeleteCaseCommand();

  return <button onClick={() => deleteCase(caseId)}>Delete</button>;
}

function useDeleteCaseCommand() {
  const permissions = usePermissions();
  const workflow = useCaseWorkflow();
  const audit = useAudit();
  const modal = useModal();
  const toast = useToast();

  return async function deleteCase(caseId: string) {
    if (!permissions.can('case.delete')) {
      toast.error('You do not have permission to delete this case.');
      return;
    }

    const confirmed = await modal.confirm({
      title: 'Delete case?',
      description: 'This action cannot be undone.',
    });

    if (!confirmed) return;

    await workflow.deleteCase(caseId);
    audit.track('case.deleted', { caseId });
  };
}

const CurrencyContext = createContext('USD');

function Price() {
  const currency = useContext(CurrencyContext);
  return <span>{currency}</span>;
}

function App() {
  return (
    <CurrencyContext value="USD">
      <Price />

      <CurrencyContext value="IDR">
        <Price />
      </CurrencyContext>
    </CurrencyContext>
  );
}

Price pertama  -> USD
Price kedua    -> IDR

Theme section override
Locale preview
Tenant/workspace boundary
Permission simulation
Storybook scenario
Nested form field
Nested menu/listbox/tabs

<AuthContext value={{ user, login, logout }}>
  {children}
</AuthContext>

const value = useMemo(
  () => ({ user, login, logout }),
  [user, login, logout],
);

return <AuthContext value={value}>{children}</AuthContext>;

useMemo bukan solusi arsitektur untuk context yang terlalu besar.
useMemo hanya menjaga identity ketika dependency tidak berubah.
Jika user berubah, semua consumer context tetap harus mengevaluasi value baru.

type SidebarContextValue = {
  expanded: boolean;
  toggle(): void;
};

Tabs active tab
Accordion expanded item
Sidebar open/closed
Dropdown open/closed
Form field metadata
Theme mode

type ToastApi = {
  success(message: string): void;
  error(message: string): void;
};

toast
modal
analytics
permission check
router/navigation
workflow command
feature flag access

Provider ini mendefinisikan boundary apa?

<AppContext value={{
  user,
  theme,
  permissions,
  cases,
  selectedCaseId,
  filters,
  modalState,
  notifications,
  updateCase,
  deleteCase,
  setFilters,
  openModal,
}}>
  <App />
</AppContext>

Boundary tidak jelas.
Semua hal menjadi dependency semua hal.
Value berubah karena alasan terlalu banyak.
Consumer sulit dites.
Tidak ada ownership yang bersih.
Refactor menjadi berisiko.

<SessionProvider>
  <FeatureFlagProvider>
    <PermissionProvider>
      <ToastProvider>
        <ModalProvider>
          <CaseSearchPage />
        </ModalProvider>
      </ToastProvider>
    </PermissionProvider>
  </FeatureFlagProvider>
</SessionProvider>

function AppProviders({ children }: { children: React.ReactNode }) {
  return (
    <SessionProvider>
      <FeatureFlagProvider>
        <PermissionProvider>
          <ToastProvider>
            <ModalProvider>{children}</ModalProvider>
          </ToastProvider>
        </PermissionProvider>
      </FeatureFlagProvider>
    </SessionProvider>
  );
}

theme
locale
session
feature flags
analytics adapter
query client provider
router provider

case search filters
case detail workflow
route-level permission context
page-level modal host

invoice approval workflow
document review state
bulk action selection
wizard state

Tabs active value
Accordion expanded item
RadioGroup selected value
Menu open/highlighted item
FormField id/error relationship

Provider ini membuat X tersedia untuk subtree Y agar Z tidak perlu dipassing manual.

Siapa pemilik value?
Siapa boleh mengubah value?
Apakah consumer boleh mutation langsung?
Apakah context membawa state, command, atau keduanya?
Apakah value ini harus persist saat subtree unmount?
Apakah value ini harus global atau scoped?

type FiltersContextValue = {
  filters: Filters;
  setFilters: React.Dispatch<React.SetStateAction<Filters>>;
};

type CaseSearchContextValue = {
  filters: Filters;
  applyFilter(patch: Partial<Filters>): void;
  resetFilters(): void;
  setPage(page: number): void;
};

<WorkflowContext value={{ state, setState }}>

Consumer bisa membuat illegal transition.
Invariant tersebar di banyak tempat.
Sulit audit siapa mengubah apa.
Nama action tidak terlihat.
Testing harus mengejar banyak setter path.

type WorkflowContextValue = {
  state: WorkflowState;
  submit(): Promise<void>;
  approve(): Promise<void>;
  reject(reason: string): Promise<void>;
  retry(): Promise<void>;
};

function ApproveButton() {
  const workflow = useWorkflow();

  return (
    <button
      disabled={workflow.state.status !== 'readyForApproval'}
      onClick={workflow.approve}
    >
      Approve
    </button>
  );
}

type PermissionContextValue = {
  can(action: string, resource?: unknown): boolean;
};

const PermissionContext = createContext<PermissionContextValue | null>(null);

function EscalateButton({ caseId }: { caseId: string }) {
  const permissions = usePermissions();

  if (!permissions.can('case.escalate', { caseId })) {
    return null;
  }

  return <button>Escalate</button>;
}

Permission context di frontend hanya mengatur UX.
Backend tetap harus melakukan authorization sebenarnya.
UI permission tidak boleh dianggap enforcement boundary.

mengurangi action yang tidak relevan
membuat UI konsisten
mendukung disabled/hidden policy
auditability UX
mengurangi accidental invalid action

render(
  <PermissionContext value={{ can: () => true }}>
    <EscalateButton caseId="C-123" />
  </PermissionContext>,
);

Setiap test perlu AppProviders penuh.
Mock provider sulit dibuat.
Komponen kecil butuh banyak dependency.
Provider value shape terlalu besar.

Buat custom render helper per feature.
Pisahkan provider per capability.
Gunakan domain hook untuk orchestration kompleks.
Jangan membuat AppContext raksasa.
Expose test harness untuk feature provider.

type Context<T> = {
  defaultValue: T;
  stack: T[];
};

function createTinyContext<T>(defaultValue: T): Context<T> {
  return {
    defaultValue,
    stack: [],
  };
}

function provide<T>(context: Context<T>, value: T, renderSubtree: () => void) {
  context.stack.push(value);

  try {
    renderSubtree();
  } finally {
    context.stack.pop();
  }
}

function read<T>(context: Context<T>): T {
  const latest = context.stack.at(-1);
  return latest ?? context.defaultValue;
}

const Theme = createTinyContext('light');

provide(Theme, 'dark', () => {
  console.log(read(Theme)); // dark

  provide(Theme, 'high-contrast', () => {
    console.log(read(Theme)); // high-contrast
  });

  console.log(read(Theme)); // dark
});

Provider masuk scope -> value ditaruh.
Consumer membaca value terdekat.
Provider keluar scope -> value sebelumnya berlaku lagi.

Satu context berisi semua state dan action.
Setiap perubahan kecil menyentuh banyak consumer.
Tidak ada boundary ownership.

Pisahkan berdasarkan capability dan update frequency.
Gunakan provider per domain/feature.
Gunakan external store jika butuh selector granular.

Typing input membuat banyak component rerender.
Pointer movement dibroadcast ke subtree besar.
List selection besar membuat page tersendat.

Localize state.
Gunakan external store dengan selector.
Virtualize list.
Pisahkan state high-frequency dari context low-frequency.

Komponen berjalan di test tetapi rusak di runtime.
Dummy function terpanggil tanpa error.
Auth/permission default membuat false confidence.

Gunakan null sentinel untuk required context.
Buat custom hook yang fail fast.

Komponen kecil membaca banyak context.
Sulit dipindahkan.
Sulit dites.
Sulit tahu dependency dari signature.

Buat domain hook.
Pindahkan orchestration ke boundary.
Pertahankan view component tetap dependency-light.

Consumer membuat state invalid.
Transisi tersebar.
Tidak ada audit action.

Expose command/event, bukan setState mentah.
Gunakan reducer untuk transition logic.
Gunakan state machine untuk workflow kompleks.

1. Value ini berlaku untuk subtree apa?
2. Apakah props/composition lebih eksplisit dan cukup?
3. Apakah value ini dependency/capability atau state yang sering berubah?
4. Siapa owner value ini?
5. Siapa boleh mengubahnya?
6. Apakah consumer perlu semua value atau hanya slice?
7. Apakah update frequency-nya rendah?
8. Apakah provider override per subtree berguna?
9. Apakah default value aman?
10. Apakah custom hook bisa fail fast ketika provider hilang?
11. Apakah value shape terlalu besar?
12. Apakah context ini akan membuat test setup berat?
13. Apakah raw setter bocor ke consumer?
14. Apakah context ini sebenarnya server/cache state?
15. Apakah external store lebih tepat?

scoped dependency
capability passing
cross-cutting read-mostly values
component group coordination
provider override per subtree

global dumping ground
high-frequency granular state
large entity cache
workflow rumit tanpa transition model
server state ownership