Skip to content

How component reuse works

Component reuse is the foundation of single-source authoring: write a piece of content once, reference it from multiple Create and manage topics, and update it in one place to update everywhere.

The problem with copy-paste

When the same content appears in multiple topics — a support contact block, a security disclaimer, a setup prerequisite — copy-pasting creates multiple independent copies. When the information changes, you need to find and update every copy. In practice, copies get missed, and your documentation drifts out of sync.

Content drift from copy-paste is one of the most common documentation quality problems. If your team relies on find-and-replace to keep duplicate content in sync, that's a strong signal to adopt component-based reuse instead.

Components as single-source blocks

In Topicary, a component is a named, reusable content fragment stored independently from any topic. Topics don't contain the component's content — they contain a reference to it.

The distinction matters:

  • Copy-paste: Topic A and Topic B each have their own copy of the text. Changing one doesn't affect the other.

  • Component reference: Topic A and Topic B both point to the same component. The component holds the text. Changing the component changes what both topics display.

Live references

Component references are live — not snapshots. When you view a topic in the editor, component references render the current content of the source component. There's no "sync" step or "pull latest" action. The reference always reflects the source.

Because references are live, you can safely edit a component at any time. You don't need to "push" changes to referencing topics — they pick up the update automatically the next time they load.

Impact awareness

Because components can be referenced from dozens of topics, Topicary provides impact signals:

  • Where-used counts on the Components page show the number of topics referencing each component

  • Deletion warnings tell you exactly which references will break if you delete a component

  • Find and fix orphaned components flags components with zero references — these aren't being used and may be candidates for cleanup

When to use components

Components work best for content that is:

  • Identical across locations — the exact same text, not similar text

  • Likely to change — content that's static doesn't benefit much from single-sourcing

  • Used in three or more places — two locations might not justify the indirection; three or more almost certainly do

Common examples: legal disclaimers, support contact blocks, prerequisite lists, standard warnings, version-specific notes, and API authentication boilerplate.

Start simple. You don't need to plan every component upfront. Write your topics first, then extract shared content into components when you notice duplication. See Structuring content for reuse for a practical, iterative approach.

When not to use components

If content is similar but not identical across locations, components aren't the right tool. Use Create conditional content blocks or Create variable sets for content that varies by audience or context. Use components only for content that should be exactly the same everywhere it appears.

Components and conditions solve different problems. Components share identical content across locations. Conditions vs. variables adapt content per audience or output. If you find yourself wanting a component that's "almost the same but slightly different" in each location, conditions or variables are probably the right tool.

See also

Was this page helpful?