apps/web/ui/modals/register-domain-modal.tsx (1)

46-64: Consider memoizing props if they change frequently.

The hook correctly includes props in the dependency array (line 59), which will cause RegisterDomainModal to recreate whenever props changes. If the caller passes a new object reference on each render, this could cause unnecessary re-renders of components using this modal.

If you notice performance issues, consider having callers memoize their props object:

const registerModalProps = useMemo(
  () => ({ onSuccess, setRegisteredParam }),
  [onSuccess, setRegisteredParam]
);
const { RegisterDomainModal, setShowRegisterDomainModal } = 
  useRegisterDomainModal(registerModalProps);

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Learnt from: TWilson023
Repo: dubinc/dub PR: 2872
File: apps/web/app/(ee)/partners.dub.co/(dashboard)/profile/profile-details-form.tsx:180-189
Timestamp: 2025-09-24T15:50:16.414Z
Learning: TWilson023 prefers to keep security vulnerability fixes separate from refactoring PRs when the vulnerable code is existing and was only moved/relocated rather than newly introduced.

Learnt from: steven-tey
Repo: dubinc/dub PR: 2958
File: apps/web/app/(ee)/partners.dub.co/(dashboard)/profile/members/page-client.tsx:270-303
Timestamp: 2025-10-15T01:52:37.048Z
Learning: In React components with dropdowns or form controls that show modals for confirmation (e.g., role selection, delete confirmation), local state should be reverted to match the prop value when the modal is cancelled. This prevents the UI from showing an unconfirmed change. The solution is to either: (1) pass an onClose callback to the modal that resets the local state, or (2) observe modal visibility state and reset on close. Example context: RoleCell component in apps/web/app/(ee)/partners.dub.co/(dashboard)/profile/members/page-client.tsx where role dropdown should revert to user.role when UpdateUserModal is cancelled.

apps/web/ui/partners/program-link-configuration.tsx (1)

311-349: Consider adding loading and error states for domain verification.

The component fetches verification data but doesn't display a loading indicator or handle potential errors. While the verification UI only appears when data is available, users might not understand why the verification section doesn't appear immediately after selecting a domain.

Consider adding a loading skeleton or message:

{domain && (
  <>
    {!verificationData && (
      <div className="mt-6 animate-pulse rounded-md border border-neutral-200 bg-neutral-50 p-5">
        <div className="text-xs text-neutral-500">
          Checking domain configuration...
        </div>
      </div>
    )}
    {verificationData?.status !== "Valid Configuration" && (
      <motion.div ...>
        <DomainConfiguration data={verificationData} />
      </motion.div>
    )}
  </>
)}

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Learnt from: TWilson023
Repo: dubinc/dub PR: 3136
File: apps/web/ui/layout/sidebar/app-sidebar-nav.tsx:377-379
Timestamp: 2025-11-19T17:26:51.912Z
Learning: In the dub repository, TWilson023 prefers an incremental approach to route updates: fixing the most user-visible issues first (like sidebar navigation) while deferring less visible internal references to follow-up PRs, especially when redirects provide backward compatibility.

Learnt from: TWilson023
Repo: dubinc/dub PR: 2872
File: apps/web/app/(ee)/partners.dub.co/(dashboard)/profile/profile-details-form.tsx:180-189
Timestamp: 2025-09-24T15:50:16.414Z
Learning: TWilson023 prefers to keep security vulnerability fixes separate from refactoring PRs when the vulnerable code is existing and was only moved/relocated rather than newly introduced.

Learnt from: steven-tey
Repo: dubinc/dub PR: 2958
File: apps/web/app/(ee)/partners.dub.co/(dashboard)/profile/members/page-client.tsx:270-303
Timestamp: 2025-10-15T01:52:37.048Z
Learning: In React components with dropdowns or form controls that show modals for confirmation (e.g., role selection, delete confirmation), local state should be reverted to match the prop value when the modal is cancelled. This prevents the UI from showing an unconfirmed change. The solution is to either: (1) pass an onClose callback to the modal that resets the local state, or (2) observe modal visibility state and reset on close. Example context: RoleCell component in apps/web/app/(ee)/partners.dub.co/(dashboard)/profile/members/page-client.tsx where role dropdown should revert to user.role when UpdateUserModal is cancelled.

apps/web/ui/partners/program-link-configuration.tsx (2)

300-303: Replace response: any with a typed interface for domain verification data.

The SWR response shape is partially typed (status: DomainVerificationStatusProps) but leaves response as any, which weakens type‑safety for DomainConfiguration and other consumers:

const { data: verificationData } = useSWRImmutable<{
  status: DomainVerificationStatusProps;
  response: any;
}>(/* ... */);

Define an explicit interface for the verification payload and use it here, e.g.:

interface DomainVerificationResponse {
  // Shape based on `/api/domains/:domain/verify`
  verified?: boolean;
  message?: string;
  errors?: Record<string, string>;
  // add other known fields as needed
}

const { data: verificationData } = useSWRImmutable<{
  status: DomainVerificationStatusProps;
  response: DomainVerificationResponse;
}>(/* ... */);

Then update DomainConfiguration’s props (if necessary) to use the same type.

---

145-167: Guard onSelect on isLoadingDomains before checking domains length.

The “Connect a domain you own” option currently branches on !domains?.length even while isLoadingDomains can be true:

onSelect: () => {
  if (!domains?.length) setShowAddEditDomainModal(true);
  else setState("select");
},
loading: isLoadingDomains,

Even though the button is disabled while loading, it’s safer and clearer to ensure the handler itself is a no‑op during loading and only inspects domains once loaded:

         onSelect: () => {
-          if (!domains?.length) setShowAddEditDomainModal(true);
-          else setState("select");
+          if (isLoadingDomains) return;
+          if (!domains?.length) {
+            setShowAddEditDomainModal(true);
+          } else {
+            setState("select");
+          }
         },
         loading: isLoadingDomains,

This avoids any accidental decision based on an incomplete domains list.

apps/web/ui/partners/program-link-configuration.tsx (4)

16-25: Rename local DomainProps to avoid confusion with shared domain entity type.

DomainProps is already a widely used type for full domain objects (from "@/lib/types"). Using the same name here for { domain: string | null; onDomainChange: (domain: string) => void } is likely to confuse future readers.

Consider renaming this alias to something more specific (e.g. ProgramDomainSelectionProps) and updating the intersection and component signatures accordingly:

-type DomainProps = {
+type ProgramDomainSelectionProps = {
   domain: string | null;
   onDomainChange: (domain: string) => void;
 };
 
-type ProgramLinkConfigurationProps = {
+type ProgramLinkConfigurationProps = {
   url: string | null;
   onUrlChange: (url: string) => void;
   hideLinkPreview?: boolean;
-} & DomainProps;
+} & ProgramDomainSelectionProps;

Then update DomainOnboarding and DomainOnboardingSelection to use the new name.

---

96-98: Guard against empty linkStructureOptions to avoid a runtime error.

linkStructureOptions?.[0].example will still throw if getLinkStructureOptions returns a non‑null empty array, because the optional chaining only protects the root, not index access.

If getLinkStructureOptions can ever produce an empty array, consider:

-                    {linkStructureOptions?.[0].example}
+                    {linkStructureOptions?.[0]?.example ?? ""}

or provide a more explicit fallback string.

---

124-126: Consider syncing onboarding state with domain prop changes.

state is initialized from domain only once. If domain is populated asynchronously after mount (e.g. editing an existing program where the domain is loaded later), the UI could remain stuck in "idle" even though a domain is set.

If that scenario is possible, consider syncing via an effect:

const [state, setState] = useState<"idle" | "select">(domain ? "select" : "idle");

useEffect(() => {
  if (domain) {
    setState("select");
  }
}, [domain]);

(You’d also need to import useEffect from React.)

---

128-135: Align RegisterDomainModal onSuccess payload with onDomainChange expectations.

Here onSuccess passes domain directly into onDomainChange, while the AddEditDomainModal path below passes domain.slug. That asymmetry suggests the RegisterDomainModal callback may be returning a full domain object but you’re treating it as a slug:

useRegisterDomainModal({
  onSuccess: (domain) => {
    onDomainChange(domain); // vs. onDomainChange(domain.slug) below
    setState("select");
  },
  setRegisteredParam: false,
});

If onSuccess receives a DomainProps-like object (as in the add/edit modal), this should likely be:

onSuccess: (domain) => {
  onDomainChange(domain.slug);
  setState("select");
},

Please double‑check the onSuccess type in useRegisterDomainModal and make these consistent.

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Learnt from: TWilson023
Repo: dubinc/dub PR: 3136
File: apps/web/ui/layout/sidebar/app-sidebar-nav.tsx:377-379
Timestamp: 2025-11-19T17:26:51.912Z
Learning: In the dub repository, TWilson023 prefers an incremental approach to route updates: fixing the most user-visible issues first (like sidebar navigation) while deferring less visible internal references to follow-up PRs, especially when redirects provide backward compatibility.

Learnt from: TWilson023
Repo: dubinc/dub PR: 2872
File: apps/web/app/(ee)/partners.dub.co/(dashboard)/profile/profile-details-form.tsx:180-189
Timestamp: 2025-09-24T15:50:16.414Z
Learning: TWilson023 prefers to keep security vulnerability fixes separate from refactoring PRs when the vulnerable code is existing and was only moved/relocated rather than newly introduced.

Learnt from: steven-tey
Repo: dubinc/dub PR: 2958
File: apps/web/app/(ee)/partners.dub.co/(dashboard)/profile/members/page-client.tsx:270-303
Timestamp: 2025-10-15T01:52:37.048Z
Learning: In React components with dropdowns or form controls that show modals for confirmation (e.g., role selection, delete confirmation), local state should be reverted to match the prop value when the modal is cancelled. This prevents the UI from showing an unconfirmed change. The solution is to either: (1) pass an onClose callback to the modal that resets the local state, or (2) observe modal visibility state and reset on close. Example context: RoleCell component in apps/web/app/(ee)/partners.dub.co/(dashboard)/profile/members/page-client.tsx where role dropdown should revert to user.role when UpdateUserModal is cancelled.

Learnt from: TWilson023
Repo: dubinc/dub PR: 2673
File: apps/web/ui/partners/rewards/rewards-logic.tsx:268-275
Timestamp: 2025-07-30T15:29:54.131Z
Learning: In apps/web/ui/partners/rewards/rewards-logic.tsx, when setting the entity field in a reward condition, dependent fields (attribute, operator, value) should be reset rather than preserved because different entities (customer vs sale) have different available attributes. Maintaining existing fields when the entity changes would create invalid state combinations and confusing UX.

Learnt from: TWilson023
Repo: dubinc/dub PR: 2736
File: apps/web/lib/swr/use-bounty.ts:11-16
Timestamp: 2025-08-26T15:05:55.081Z
Learning: In the Dub codebase, workspace authentication and route structures prevent endless loading states when workspaceId or similar route parameters are missing, so gating SWR loading states on parameter availability is often unnecessary.