const value = useMemo(() => compute(input), [input]);
const onSubmit = useCallback(() => submit(input), [input]);
const Card = memo(function Card(props) {
  return <div>{props.title}</div>;
});

Apa yang harus saya memoize secara manual?

Apakah code saya cukup pure, explicit, dan compiler-compatible sehingga React bisa mengoptimalkannya dengan aman?

props + state + context -> JSX

profile -> temukan rerender -> tambahkan memo/useMemo/useCallback -> ukur lagi

pastikan purity -> bentuk state topology benar -> aktifkan compiler -> profile -> memo/manual optimize hanya untuk kasus tersisa

Memoization adalah optimization, bukan correctness mechanism.

unnecessary recomputation
unnecessary rerender karena identity yang bisa dianalisis
manual memoization boilerplate

context value terlalu volatile
state diletakkan terlalu tinggi
list ribuan row tanpa virtualization
DOM/layout thrashing
network waterfall
server-state invalidation salah
expensive chart/DOM library
large JSON parsing di main thread
subscription eksternal yang terlalu broad
query key salah
component impure

Compiler mengurangi biaya render yang tidak perlu.
Compiler tidak memperbaiki arsitektur state yang salah.

Kenapa update ini menyentuh subtree sebesar ini?
Kenapa consumer context terlalu banyak?
Kenapa state high-frequency berada di provider global?
Kenapa derived data mahal dihitung di banyak tempat?
Kenapa expensive DOM tetap dimount semua?

component pure
hook pure kecuali effect/event boundary
props/state tidak dimutasi
render tidak punya side effect
object/function dependency eksplisit
state shape tidak ambigu
external mutable object tidak dibaca sebagai sumber render tanpa subscription

let globalCounter = 0;

function CounterLabel() {
  globalCounter += 1;
  return <span>{globalCounter}</span>;
}

function CounterLabel({ count }: { count: number }) {
  return <span>{count}</span>;
}

function ProductList({ products }: { products: Product[] }) {
  const visible = useMemo(() => {
    products.sort((a, b) => a.name.localeCompare(b.name));
    return products;
  }, [products]);

  return <Rows rows={visible} />;
}

function ProductList({ products }: { products: Product[] }) {
  const visible = [...products].sort((a, b) => a.name.localeCompare(b.name));
  return <Rows rows={visible} />;
}

takut rerender
lint noise
kebiasaan lama
mengira function baru selalu mahal
mengira object literal selalu masalah

function PermissionProvider({ children }: { children: React.ReactNode }) {
  const permissions = usePermissionSnapshot();

  const value = useMemo(() => ({
    can(action: string, resource: string) {
      return evaluatePermission(permissions, action, resource);
    },
  }), [permissions]);

  return (
    <PermissionContext value={value}>
      {children}
    </PermissionContext>
  );
}

function Component() {
  "use memo";
  return <div />;
}

function Component() {
  "use no memo";
  return <div />;
}

function ThirdPartyChartBridge(props: ChartBridgeProps) {
  "use no memo";
  // This component wraps a mutable third-party chart instance.
  // Keep it outside compiler optimization until the adapter is refactored.
  return <ChartBridgeImpl {...props} />;
}

app code compiled
internal component library maybe compiled
legacy package not compiled
third-party package not compiled
chart/map/editor library imperative
microfrontend boundary

const editorConfig = useMemo(() => ({
  readonly,
  language,
  theme,
}), [readonly, language, theme]);

return <LegacyEditor config={editorConfig} />;

function AppShell() {
  const [draftSearch, setDraftSearch] = useState("");

  return (
    <AppProviders>
      <Header search={draftSearch} onSearchChange={setDraftSearch} />
      <MainRoutes draftSearch={draftSearch} />
      <Footer />
    </AppProviders>
  );
}

function SearchPage() {
  const [draftSearch, setDraftSearch] = useState("");

  return (
    <SearchLayout>
      <SearchBox value={draftSearch} onChange={setDraftSearch} />
      <SearchResults draftSearch={draftSearch} />
    </SearchLayout>
  );
}

<AppContext value={{ user, permissions, theme, flags, draftSearch, setDraftSearch }}>
  <App />
</AppContext>

<AuthContext value={authValue}>
  <ThemeContext value={themeValue}>
    <FeatureFlagContext value={flagValue}>
      <App />
    </FeatureFlagContext>
  </ThemeContext>
</AuthContext>

context hanya membawa store/capability stabil
component subscribe ke slice lewat selector

function getSnapshot() {
  return { ...store.getState() }; // buruk jika dipanggil setiap render tanpa caching
}

let currentState = initialState;
let currentSnapshot = currentState;

function getSnapshot() {
  return currentSnapshot;
}

function setState(updater: (state: State) => State) {
  const next = updater(currentState);
  if (Object.is(next, currentState)) return;
  currentState = next;
  currentSnapshot = next;
  listeners.forEach(listener => listener());
}

1. Reproduce interaction lambat.
2. Aktifkan React DevTools Profiler / browser performance tools.
3. Identifikasi apakah bottleneck render, commit, layout, network, JS CPU, atau memory.
4. Cek render radius dan komponen yang sering render.
5. Cek context/provider/store/query update source.
6. Cek apakah compiler aktif untuk area itu.
7. Refactor topology/boundary sebelum menambah manual memo.
8. Ukur ulang.

1. Tambahkan lint rules React Hooks/Compiler.
2. Aktifkan compiler di area non-kritis dulu.
3. Perbaiki mutation/render impurity yang terdeteksi.
4. Jangan hapus memo manual yang menjaga library boundary sebelum diukur.
5. Tambahkan regression test untuk workflow penting.
6. Profile before/after untuk interaksi mahal.
7. Dokumentasikan exception dengan ADR/comment singkat.

Apakah kalkulasi mahal?
Apakah hasil dikirim ke memo child?
Apakah hasil dipakai sebagai dependency effect/subscription?
Apakah object identity dipakai third-party bridge?
Apakah compiler aktif di file/component ini?
Apakah ada benchmark/profile before-after?

Apakah callback dikirim ke memo child?
Apakah callback dipakai sebagai dependency effect?
Apakah callback didaftarkan ke external system?
Apakah callback identity menjadi bagian dari imperative contract?

Apakah component expensive?
Apakah props biasanya stabil?
Apakah child berada di compiled boundary?
Apakah parent sering render karena state lain?
Apakah custom equality aman?

<DataTable
  rows={rows}
  columns={columns}
  getRowId={(row) => row.id}
  onRowSelect={handleRowSelect}
/>

<DataTable
  config={{
    rows,
    columns,
    callbacks: {
      onSelect: handleRowSelect,
    },
    behavior: {
      selectable: true,
      virtualized: true,
    },
  }}
/>

Apa yang berubah?
Apa yang mahal?
Apa yang harus invalidate?
Apa yang harus preserve?

Compiler sudah aktif, berarti performance aman.

Compiler mengurangi sebagian overhead. Bottleneck tetap harus diukur.

[ ] Component render pure dan deterministic.
[ ] Tidak ada mutation props/state/query data.
[ ] State berada di owner tersempit yang benar.
[ ] Context tidak mencampur state volatile dan capability low-frequency.
[ ] External store memakai snapshot stabil.
[ ] Manual memoization punya alasan eksplisit.
[ ] Compiler exception punya comment/ADR kecil.
[ ] Performance claim didukung profiling.
[ ] Large list memakai virtualization/row boundary bila perlu.
[ ] Async/server-state bottleneck tidak diperlakukan sebagai render-only problem.

Interaction:
Expected latency:
Observed latency:
Update source:
Render radius:
Compiler enabled? yes/no
Manual memoization present:
Context providers touched:
External stores touched:
Server queries touched:
Main bottleneck class:
Refactor candidate:
Measured after:

1. Turunkan state yang terlalu tinggi, atau
2. Split context yang volatile, atau
3. Pindahkan derived data ke selector, atau
4. Tambahkan deferred/transition boundary, atau
5. Stabilkan legacy bridge props, atau
6. Hapus memo manual yang terbukti tidak perlu.

Apakah code ini pure?
Apakah state topology-nya benar?
Apakah provider terlalu volatile?
Apakah expensive subtree punya boundary tepat?
Apakah bottleneck render, commit, layout, network, atau cache?
Apakah manual memo ini masih punya alasan setelah compiler aktif?

purity
+ state ownership
+ compiler-compatible code
+ context/store/query boundary
+ profiling discipline
+ targeted manual optimization