Product Management and Sync

Welcome back. In the previous unit, you transformed the admin product workspace from a simple selection screen into a real form-driven management surface. You built a reusable typed ProductForm, introduced ProductFormValues as the stable UI shape for editable fields, added helper functions that translate form values into API-ready payloads, and wired both create and update flows into ProductAdminPageClient. That gave the admin page a strong foundation: create on the left, edit on the right, and a product list underneath that stays in sync through refresh() after successful writes.

This final unit builds directly on that foundation. The create and update flows already work, but the workspace still needs better list behavior and stronger synchronization between the selected product and the refreshed server data. In this lesson, you will sort products so the newest items appear first, keep the selected product aligned with the latest collection after refreshes, reset the create form after successful creation, and add archive actions to complete the first practical version of the admin management workflow.

In the previous lesson, the key idea was typed form reuse. src/components/admin/ProductForm.tsx defined a clear boundary between editable UI values and API payloads, while src/components/admin/ProductAdminPageClient.tsx used that form for both product creation and editing. The page also added isCreating and isUpdating flags, used the shared toast system for success and failure feedback, and refreshed the product collection after each successful mutation.

That architecture matters a lot here. Because the page already trusts the server as the source of truth and already refreshes after writes, this lesson can focus on what happens after those refreshes: how the list should behave, how selection should stay current, and how the workspace should respond when products are created or archived.

At first glance, sorting and selection synchronization can look like “small polish.” In reality, they are core workflow behavior in an admin tool. When an internal user creates a product, they usually expect to see it appear near the top immediately. When they update or archive a selected product, they expect the edit form to stay aligned with the current server version rather than keep showing stale data.

That is why this lesson leaves the existing create and update form logic mostly unchanged. The important new work is about keeping the admin workspace honest after refresh-driven mutations. A management tool feels reliable when the list order helps users find recent work quickly, when the selected item tracks the latest version from the collection, and when the form resets or clears itself at the right moments.

The central file for this lesson is still src/components/admin/ProductAdminPageClient.tsx. The component now needs a few extra React tools so it can derive a sorted list and synchronize local selection with refreshed collection data.

Here is the top of the file:

'use client';

import { useEffect, useMemo, useState } from 'react';
import {
  ProductForm,
  buildCreateProductInput,
  buildUpdateProductInput,
  toProductFormValues,
} from '@/components/admin/ProductForm';
import { PageContainer } from '@/components/layout/PageContainer';
import { Button } from '@/components/ui/Button';
import { EmptyState } from '@/components/ui/EmptyState';
import { ErrorState } from '@/components/ui/ErrorState';
import { LoadingState } from '@/components/ui/LoadingState';
import { SectionHeading } from '@/components/ui/SectionHeading';
import { StatusBadge } from '@/components/ui/StatusBadge';
import { useToast } from '@/components/ui/Toast';
import { archiveProduct, createProduct, updateProduct } from '@/lib/api/products';
import { getErrorMessage } from '@/lib/api/client';
import { useProducts } from '@/lib/hooks/useProducts';
import { formatMoney } from '@/lib/utils/format';
import { Product } from '@/types/domain';

• useMemo is added because the page now derives a sorted version of the product list. That is a classic React use case for memoization: the sorted array is derived from existing data and should be recomputed only when the source collection changes.

• useEffect is also important here because the page needs synchronization logic that reacts to changes in products and selectedProduct. This is not form-local logic; it is collection-aware page behavior, so it belongs in the page component.

• The new import of archiveProduct signals the final workflow expansion of this course. The admin page is no longer just about creating and editing products — it is now becoming a fuller management workspace with lifecycle actions for products as well.

• Importing Button directly for the row action group matters too. Earlier versions of the list used a simpler single button, but the final workflow now needs a richer action layout with separate Edit and Archive controls.

The next addition is a new piece of local state used to remount the create form after a successful create. This is a very practical React pattern: rather than teaching the form a special reset API just for one workflow, the page can force a fresh mount by changing a key.

Here is the component state setup:

export function ProductAdminPageClient() {
  const { products, isLoading, errorMessage, refresh } = useProducts();
  const [selectedProduct, setSelectedProduct] = useState<Product | null>(null);
  const [isCreating, setIsCreating] = useState(false);
  const [isUpdating, setIsUpdating] = useState(false);
  const [createFormKey, setCreateFormKey] = useState(0);
  const toast = useToast();

• createFormKey is local page state because the reset behavior only matters to this page’s create form. There is no reason to push that concern into ProductForm itself when the parent can control remounting cleanly.

• Keeping isCreating and isUpdating separate remains the right choice from the previous lesson. The new reset behavior and archive behavior do not change that principle: the create and edit sides of the workspace still represent different async workflows.

• selectedProduct remains page-local as well, but in this lesson it becomes even more important because the page must now keep that selection synchronized with the refreshed collection after updates and archives.

• This is a good example of React state staying close to the workflow it serves. Each state value here has a clear responsibility: selection, creation progress, update progress, create-form remounting, and toast feedback.

One of the first major improvements in this lesson is the derived sorted product list. Internal tools often benefit from showing newest records first, because the user frequently creates something and then immediately wants to confirm that it exists or continue editing it.

Here is the derived list:

  const sortedProducts = useMemo(
    () => [...products].sort((left, right) => right.created_at.localeCompare(left.created_at)),
    [products]
  );

• useMemo(...) is used because sortedProducts is derived from products, not stored independently. That makes the code easier to reason about: the source of truth remains the hook-provided collection, and the sorted list is just a computed view of that data.

• The spread syntax [...] is extremely important here. The component sorts a copied array rather than sorting products directly, which preserves immutability and avoids mutating the hook’s result in place.

• Sorting by right.created_at.localeCompare(left.created_at) places newer products first. That means recently created items rise to the top of the admin list, which makes refresh-based workflows feel much more immediate and useful.

• This is not just a visual preference. In an internal management workspace, ordering affects how easily the user can verify the result of a recent action. If a newly created product appears near the top after refresh, the tool feels responsive and trustworthy.

• Because the dependency array is [products], the memoized sorted list updates automatically whenever the collection changes. That keeps the list aligned with server refreshes while still making the derivation explicit and controlled.

Once the page refreshes after an update or archive, the selectedProduct object the user originally clicked may no longer match the latest version in the collection. That is why the page adds an effect that watches both products and selectedProduct.

Here is that effect:

  useEffect(() => {
    if (!selectedProduct) return;
    const nextSelected = products.find((product) => product.id === selectedProduct.id) ?? null;
    setSelectedProduct(nextSelected);
  }, [products, selectedProduct]);

• The early if (!selectedProduct) return; guard is important because the page should stay quiet when nothing is selected. If the workspace is currently acting only as a create surface, there is no selection to synchronize.

• products.find((product) => product.id === selectedProduct.id) searches the newest collection for the currently selected product by ID. This is the right lookup because refreshes may produce a new object reference even when the logical product is the same record.

• If the product still exists in the refreshed collection, setSelectedProduct(nextSelected) replaces the stale selected object with the latest one from the server-backed list. That keeps the edit form aligned with reality after updates.

• If the product no longer exists in the collection, the ?? null fallback clears the selection. That is especially useful for destructive or lifecycle transitions, because the page should not keep editing a product that is no longer represented in the current list state.

• This effect is a very good example of page-level synchronization logic. The form component should not know about the full collection or how it changes over time; the page is the correct place to keep collection state and selected-record state in sync.

• The broader lesson here is that refreshing data is only half the job. A trustworthy admin page also has to reconnect its local UI state to that refreshed data once it arrives.

The create handler from the previous lesson already performed the create mutation, refreshed the collection, and showed a success toast. In this lesson, it adds one more important behavior: resetting the create form only after the product has truly been created and the list has refreshed successfully.

Here is the updated handler:

  async function handleCreate(values: ReturnType<typeof toProductFormValues>) {
    setIsCreating(true);
    try {
      await createProduct(buildCreateProductInput(values));
      await refresh();
      setCreateFormKey((current) => current + 1);
      toast.success('Product created.');
    } catch (error) {
      toast.error(getErrorMessage(error));
    } finally {
      setIsCreating(false);
    }
  }

• The first part of the handler is still the same strong workflow from the previous lesson. It sets the pending flag, builds a normalized create payload with buildCreateProductInput(values), and trusts the shared API helper to perform the mutation.

• await refresh() still comes before the form reset, and that sequencing matters a lot. The form should only reset after the write has actually succeeded and the collection has been refreshed from the canonical server state.

• setCreateFormKey((current) => current + 1) is the key new step. Incrementing the key forces React to remount the create form, which gives the user a fresh empty form without needing to teach ProductForm a separate reset method.

• This is a very practical React technique. It keeps the reusable form component simpler while still giving the parent page a reliable way to clear the create workflow after success.

• The success toast remains useful because even with the list refresh and form reset, the user still benefits from an explicit acknowledgment that the creation completed correctly.

The update handler in this lesson is intentionally unchanged. That is important to call out because good refactoring does not disturb unrelated, already-correct flows.

Here is the existing update handler:

  async function handleUpdate(values: ReturnType<typeof toProductFormValues>) {
    if (!selectedProduct) return;
    setIsUpdating(true);
    try {
      await updateProduct(selectedProduct.id, buildUpdateProductInput(values));
      await refresh();
      toast.success('Product updated.');
    } catch (error) {
      toast.error(getErrorMessage(error));
    } finally {
      setIsUpdating(false);
    }
  }

• The early guard remains correct because edit mode still requires a selected product. This lesson does not need to change that workflow contract.

• The refresh step continues to be the central trust-building behavior. After saving changes, the page re-reads the server’s version rather than assuming local state already represents the final truth.

• What changes around this handler is not the handler itself, but the way the page responds afterward. Thanks to the synchronization effect, the selected product now updates to the newest matching object in the refreshed collection automatically.

• This is a useful lesson in UI architecture: sometimes the right improvement is not to rewrite a handler, but to improve the surrounding state relationships so that existing handlers gain better downstream behavior.

The final major feature in this lesson is the archive flow. Archiving is a product lifecycle action, much like paying or cancelling orders in the earlier course, and it belongs in the admin page because it changes operational product state.

Here is handleArchive(...):

  async function handleArchive(productId: string) {
    try {
      const updated = await archiveProduct(productId);
      if (selectedProduct?.id === productId) setSelectedProduct(updated);
      await refresh();
      toast.success('Product archived.');
    } catch (error) {
      toast.error(getErrorMessage(error));
    }
  }

• archiveProduct(productId) is the semantic API helper that keeps this handler easy to read. The page expresses business intent directly instead of building a DELETE request inline.

• Capturing the returned value as updated is a very useful detail. If the currently selected product is the one being archived, the page can immediately update selectedProduct with the returned archived product before the refresh finishes.

• if (selectedProduct?.id === productId) setSelectedProduct(updated); keeps the edit side honest during the transition. Instead of briefly showing stale pre-archive data while the refresh is in flight, the page moves the selected state toward the archived version immediately.

• await refresh() still follows because the collection as a whole should come from canonical server data. Even when the handler gets an updated product back, the page still wants the latest full list.

• The success toast provides immediate confirmation without navigating away from the workspace. That is particularly important in admin tooling, where users often perform several lifecycle actions in a row on the same screen.

• Unlike create and update, this handler does not currently track a dedicated local pending flag. That is acceptable here because the practice focus is on integrating the archive action and reflecting workflow rules in the UI rather than teaching a second full button-state system.

The create form reset behavior becomes visible in the page layout by passing createFormKey as the React key prop for the create-side ProductForm.

Here is that part of the workspace:

      <div className="grid gap-8 xl:grid-cols-[0.9fr_1.1fr]">
        <ProductForm
          key={createFormKey}
          title="Create product"
          values={toProductFormValues()}
          submitLabel="Create product"
          onSubmit={handleCreate}
          isSubmitting={isCreating}
        />

• The key={createFormKey} prop is what makes the reset technique work. When createFormKey changes after a successful creation, React treats the form as a new component instance and remounts it.

• That remount resets the form’s internal local state back to the toProductFormValues() defaults, which gives the user a fresh blank create form.

• This is a very clean solution for this workflow because it avoids complicating ProductForm with imperative reset methods or extra parent-to-child reset props that only one side of the workspace needs.

• It also reinforces an important React idea: sometimes component remounting is the simplest and most practical way to reset local state when the UX genuinely calls for a “fresh start.”

The edit side of the workspace stays mostly the same, but it benefits from the new synchronization logic because the selected product reference stays current as products refresh or change status.

Here is the conditional edit area:

        {selectedProduct ? (
          <ProductForm
            title={`Edit ${selectedProduct.name}`}
            values={toProductFormValues(selectedProduct)}
            submitLabel="Save changes"
            onSubmit={handleUpdate}
            disableSku
            isSubmitting={isUpdating}
          />
        ) : (
          <div className="rounded-[2rem] border border-dashed border-stone-300 bg-white/70 p-10 text-center text-sm text-stone-600">
            Select a product below to edit inventory, pricing, description, or status.
          </div>
        )}
      </div>

• The conditional rendering pattern is still right for this workspace. When a product is selected, the user gets a preloaded edit form; when no product is selected, the page shows a dashed guidance panel instead of a blank space.

• What changes in this lesson is how reliable that selected product becomes over time. Because the selection sync effect now tracks refreshed collection data, the edit form stays aligned with the current version of the selected product rather than drifting behind it.

• The disableSku rule still matters as before. Even while the workspace expands with sorting and archiving, the admin edit form continues to protect identifier stability.

• This is a good example of how a strong component structure can stay stable while the surrounding state logic becomes smarter.

Once sortedProducts exists, the page should use that derived list consistently in both the empty-state check and the populated render branch. That ensures the page is not partly driven by the raw array and partly by the derived one.

Here are those checks:

      {isLoading ? <LoadingState message="Loading products..." /> : null}
      {!isLoading && errorMessage ? <ErrorState message={errorMessage} /> : null}
      {!isLoading && !errorMessage && sortedProducts.length === 0 ? (
        <EmptyState title="No products created" description="Use the create form above to seed the catalog." />
      ) : null}
      {!isLoading && !errorMessage && sortedProducts.length > 0 ? (
        <div className="space-y-4">

• Switching the empty-state check from products.length to sortedProducts.length keeps the render logic consistent. Even though the lengths match, using the same derived source everywhere makes the page easier to understand.

• This consistency matters as a code-reading habit. Once a derived collection becomes the intended render source, the component should rely on it everywhere that same view of the data is needed.

• The loading and error branches remain unchanged, which is correct. Sorting is relevant only after the collection has successfully loaded, so it should not interfere with the primary page-state branches.

• This shows a useful separation of concerns: hook-provided state still controls whether the page can render the list at all, while the derived sorted list controls how the successful list should be presented.

The populated-state list now uses sortedProducts and replaces the previous single action button with the final row action group: Edit and Archive.

Here is the full populated-state row rendering:

          {sortedProducts.map((product) => (
            <article
              key={product.id}
              className="flex flex-col gap-4 rounded-[2rem] border border-stone-200 bg-white p-6 shadow-sm md:flex-row md:items-center md:justify-between"
            >
              <div className="space-y-2">
                <div className="flex items-center gap-3">
                  <p className="font-serif text-2xl text-stone-950">{product.name}</p>
                  <StatusBadge status={product.status} />
                </div>
                <p className="text-sm text-stone-500">
                  {product.sku} · {formatMoney(product.price_cents, product.currency)} · {product.inventory_count} in stock
                </p>
              </div>
              <div className="flex flex-wrap gap-3">
                <Button variant="secondary" onClick={() => setSelectedProduct(product)}>
                  Edit
                </Button>
                <Button variant="danger" onClick={() => void handleArchive(product.id)} disabled={product.status === 'archived'}>
                  Archive
                </Button>
              </div>
            </article>
          ))}
        </div>
      ) : null}

• Mapping over sortedProducts instead of products is what makes the newest-first ordering visible in the UI. This is the payoff of the earlier derived list logic.

• The Edit button now uses the shared Button component rather than a custom row button element. That helps the action group feel more intentional and visually consistent with the rest of the admin workspace.

• onClick={() => setSelectedProduct(product)} still drives the right-side edit form in the same clear way as before. The difference now is that the selected object is better synchronized with refreshed data afterward.

• The Archive button introduces the final product lifecycle action for this course. It uses variant="danger" to reflect the heavier operational weight of archiving compared with ordinary editing.

• disabled={product.status === 'archived'} is an important workflow rule surfaced directly in the UI. A product that is already archived should not keep advertising archive as a valid next action.

• This is a strong trust-building pattern: do not make users click into an invalid action just to be told later that it cannot happen. When the workflow rules are known at render time, the UI should reflect them directly.

• The row still preserves the useful internal metadata line with SKU, formatted price, and inventory count. That means the list continues to serve as a fast management board while also supporting richer actions.

One of the most important design choices in this lesson is where the synchronization logic lives. The effect that updates selectedProduct after refreshes is in ProductAdminPageClient, not in ProductForm.

That is the correct separation of responsibilities. The form should care about the currently edited values for one product. It should not know about the full collection, how the collection refreshes, whether the selected product still exists in the list, or how the list is sorted. All of that is collection-wide workspace knowledge, so it belongs at the page level.

This separation keeps the form reusable and focused, while the page remains responsible for the broader admin workflow. That is exactly the kind of architecture that scales cleanly as the app grows.

In this final unit, you strengthened the admin product workspace by making it more synchronized, more trustworthy, and more complete.

You started in src/components/admin/ProductAdminPageClient.tsx by deriving sortedProducts with useMemo, sorting a copied array rather than mutating the hook-provided products, and using created_at to show the newest items first. Then you added a synchronization effect that watches both products and selectedProduct, replacing stale selected references with the latest matching product from the refreshed collection or clearing the selection when the product no longer exists.

After that, you introduced createFormKey so the create form can remount after a successful create, which resets the form only after the product is actually created and the list has refreshed. You kept the update flow stable, added handleArchive(productId) using archiveProduct(productId), surfaced archive success and failure through toasts, and updated the selected product immediately when the archived record was the one being edited. Finally, you replaced the old single row action with the final action group — Edit and Archive — and disabled the archive button when the product was already archived so the UI reflects workflow rules directly.

The main takeaway is that admin tools feel reliable when they stay synchronized with server truth. Sorting helps users find recent work, selection sync keeps edit state honest after refreshes, form remounting resets the create workflow cleanly, and action buttons reflect the real lifecycle rules of the records they manage.