Knowing when to abstract

You build three cards that look similar. Each has a title, a short line of text, and a button. Bubble makes it easy to turn that shape into a reusable element.

Do not abstract yet. First check whether the repeated UI or workflow represents the same concept in the app. Similar shape is not enough.

Abstract when duplicated work has the same meaning. An invoice row shown on the client dashboard and the admin dashboard is still an invoice row. It should probably use one reusable element that receives anInvoice and owns the display rules for invoices.

Do not abstract two unrelated cards because they both have a title and a button. A booking card and an onboarding task card might share a visual layout, but they have different data, actions, visibility rules, and empty states. A shared generic card would need inputs for every difference.

A reusable element is a good fit when one concept appears in several places and should behave consistently. InvoiceRow can accept anInvoice, show the same status treatment everywhere, and expose the same invoice actions where the current user is allowed to use them.

A reusable element is the wrong fit when it becomes a bundle of switches. If GenericCard needs inputs like show button,button label, button workflow,show status, status color, andlayout variant, the element is carrying several concepts under one name.

Use a custom event when a repeated sequence has the same business meaning. If several workflows need to create an audit log entry, a custom event namedCreate audit log entry gives that behavior one place to live. The event takes the thing being changed, the actor, and the action label.

Do not create a custom event just because three actions happen next to each other once. If the sequence only exists on one page and has no business name, keeping it in the page workflow is easier to read.

Shared data structures need a shared concept. A Notificationdata type works when several features create notifications that users read in one inbox. Each notification has the same core fields: recipient, title, body, read date, and link target.

A generic Activity type is usually the wrong move if it stores unrelated events with fields like type, thing,metadata, and extra text. Searches then filter on text labels, workflows cast generic things back into specific records, and privacy rules have to reconstruct what each activity represents.

Every abstraction adds a name, a contract, and a place to debug. A reusable element needs clear input types. A custom event needs stable parameters. A backend workflow needs an owner and a calling convention. A shared data type needs fields that mean the same thing for every record.

The warning sign is condition handling inside the abstraction. If a reusable element has conditions for invoices, bookings, and onboarding tasks, split it. If a custom event branches by five action names, split it. If a shared data type has fields that only apply to one caller, move those fields back to the specific data type.

Abstract when the duplicated work has the same business meaning and one place should own the rule. Keep the duplication when two places only look similar.