Don't Admit a Second Chrome

Two Conventions for One Job

The panel that docks an assistant surface into an app grew three times, independently — a full-tree sweep later established exactly three lineages. This lesson is about the moment the second one became a decision. One convention had been promoted into the shared repository. The second grew in a different corner of the family and was hand-copied into three more apps — same purpose, different mechanism: one rendered the panel as a layout sibling the host wrapped, another as a bare fixed overlay with no packing at all, which meant it covered the content instead of pushing it aside.

At its third copy, the second convention had — by the family's own heuristic — earned promotion. A fourth adopter existed and nobody knew it yet; lesson 3 is about how it surfaced.

The Trap Inside a Correct Rule

This is the interesting part. Applying the rule of three mechanically gives an answer that is locally correct and globally absurd: promote it, and now the repository that exists to remove duplication contains two components for the same purpose, with different mechanisms, both carrying the shared layer's authority. Every future change to the panel has to be made twice. Every new app has to choose. The duplication has been formalized rather than removed.

The call was to merge instead: adopt the existing shared chrome, retire the copies, and end the second lineage entirely. Four apps converted in a day, and no file of the retired convention remains anywhere in the family.

Before promoting a pattern, ask whether the shared layer already holds something with the same purpose — and if it does, merge rather than admit a second. The rule of three answers 'has this earned extraction'. It does not answer 'is this the same job as something already extracted', and those are different questions. A repository whose purpose is deduplication is the one place where a duplicate is most expensive and least visible, because both copies look legitimate.

What the Merge Cost, and What It Revealed

Adopting was not free, and what it cost is specific to this merge. One of the four converting apps explains its controls with a tooltip — a component that renders a sibling node beside the control, which no number of attributes on the control can express. So the shared chrome grew a second injection shape: wrap the control in the app's own node, alongside the one it already had, which merges attributes onto it. Both optional; the consumers that use neither were untouched.

That is the pattern worth carrying away: the apps converging on the shared layer is also how the shared layer finds out what it was missing. A merge is not one-directional. The converting app had been solving the same problem for as long as the shared version had, and it had solved one part of it in a way the shared version could not express.

A later wave of the same convergence — the third lineage, retired the day after — cost considerably more per app, and the next track prices it in full: a permission that would have vanished silently, a region above the frame, and a layout fix one app handed back to everyone.

Code

Two lineages, and the decision at the third copy·text

BEFORE - two conventions, same job

  shared chrome            second convention (hand-copied)
  ├── app A                ├── app D   ORIGIN. A bare fixed overlay
  ├── app B                │           with no packing at all, so it
  └── app C                │           COVERED the content - a live
                           │           violation of the family's own
                           │           rule, in the app that started
                           │           the convention
                           ├── app E   flex sibling, host wraps it
                           ├── app F   flex sibling
                           └── app G   a FOURTH adopter, unknown
                                       until a full-tree sweep found
                                       it AFTER the first three were
                                       converted (lesson 3's story)

  At app F the second convention hit its third copy. By the rule of
  three, it has earned promotion.


THE MECHANICAL ANSWER (locally correct, globally absurd)

  shared repo
  ├── SharedPanel          <- for apps A, B, C
  └── SecondPanel          <- for apps D, E, F

  Two components, one purpose, both authoritative. Every future
  change made twice; every new app forced to choose. Duplication
  formalized, not removed.


THE ANSWER TAKEN

  shared repo
  └── SharedPanel          <- ALL SEVEN, second lineage extinct

  What THIS merge cost, per converting app:
    app D  converting FIXED a live violation - its bare overlay had
           been covering the host content
    app E  its flex-sibling host wrapper dropped for the shared shell
    app F  same
    app G  same, converted last, after the sweep surfaced it

  What THIS merge grew in the shared component: ONE seam. App D
  explains its controls with a tooltip, which renders a SIBLING node
  beside the control - and no number of attributes ON the control can
  express that. So the chrome gained a second injection shape (wrap
  the control in the app's own node) beside the one it had (merge
  attributes onto it).

  A LATER WAVE of the same convergence - the third lineage, retired
  the next day - cost far more per app. Track 7 prices it in full.

Exercise

Look at your shared component library for two entries that solve the same user-facing problem with different mechanisms — two modals, two toasts, two table components. For each pair, find the moment the second was admitted and what argument was made. Then decide whether the correct move today is a merge, and what each consumer would lose by converting.

Hint

The 'what would be lost' list is the real deliverable, and it is usually short. Most of what looks like an obstacle turns out to be either an accident nobody needs or a genuine improvement the other component should adopt.

Two Conventions for One Job

The Trap Inside a Correct Rule

What the Merge Cost, and What It Revealed

Code

External links

Exercise

Progress

Comments 0