Skip to content

docs(components): clarify the tag-whitelist warning + Component vs Composite#58

Merged
GenericJam merged 1 commit into
masterfrom
docs/composite-warning-and-component-disambig
Jul 3, 2026
Merged

docs(components): clarify the tag-whitelist warning + Component vs Composite#58
GenericJam merged 1 commit into
masterfrom
docs/composite-warning-and-component-disambig

Conversation

@GenericJam

Copy link
Copy Markdown
Owner

Why

Follow-up to the 0.7.12 component-authoring guide (#…). That release documented how to write a tag composite, which answers the mechanics of issue #53. But it left unaddressed the two things the reporter actually got stuck on:

  1. The whitelist warning read as a failure. They quoted ~MOB: <ReadingTile> is not in the Mob tag whitelist — pass-through as :reading_tile as evidence it "doesn't work." That warning fires at compile time for every custom tag, because registration is a runtime action (Mob.Composite.register/2 in on_start/0, or a plugin manifest) the sigil macro can't see. It's informational. The guide never said so.
  2. Mob.Component vs Mob.Composite. They reached for use Mob.Component. That's a real but different feature — the behaviour for native view components (stateful BEAM process + platform-native view; render/1 returns a native props map, not a ~MOB tree). The tag-composite path they wanted is Mob.Composite (expand/3). The near-identical names are a trap, and nothing steered them off it.

What

Three edits to guides/components.md, all in/around the existing "Defining your own components" section:

  • A callout at the section intro disambiguating Mob.Component (native views, advanced) from Mob.Composite (pure-Elixir tags — what most people want).
  • A note right before "use them in a screen" explaining the whitelist warning is expected and harmless for a registered tag, with the real "it doesn't work" symptom to look for (an unregistered tag renders nothing).
  • Reworded the "Sub-component event isolation (planned)" note so it no longer calls the planned feature "a future Mob.Component wrapper" — that name already belongs to the existing native-view behaviour, so the old wording contradicted itself.

Docs-only; no code paths touched.

Note on #53

This makes the issue fully answerable from the guide alone. Suggest replying to #53 pointing at the updated "Tag composites" section with a corrected ReadingTile snippet (plain module + import Mob.Sigil + expand/3, registered at :expand), then closing.

🤖 Generated with Claude Code

…-Composite

Follow-up to the 0.7.12 component-authoring guide, addressing the two things
issue #53 actually got stuck on:

- The '~MOB: <Tag> is not in the Mob tag whitelist — pass-through' warning is
  expected for any registered composite (registration is runtime; the sigil
  macro can't see it at compile time). Say so, so it reads as informational
  rather than 'it doesn't work'.
- Disambiguate Mob.Component (existing native-view behaviour, render/1 returns
  a native props map) from Mob.Composite (pure-Elixir tag expanders, expand/3
  returns a ~MOB tree). The reporter reached for use Mob.Component; steer that
  instinct to Composite. Also reword the 'sub-component event isolation' note so
  it no longer calls the planned feature 'Mob.Component' (that name is taken).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@GenericJam GenericJam merged commit 76e346d into master Jul 3, 2026
4 checks passed
GenericJam added a commit that referenced this pull request Jul 3, 2026
…e docs

Doc-only patch so the components-guide clarifications from #58 reach hexdocs.pm
(HexDocs rebuilds only from a published Hex release). Addresses the two
sticking points in #53: the whitelist warning is expected for a registered
composite, and Mob.Component (native-view behaviour) is distinct from
Mob.Composite (pure-Elixir tag expanders).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@GenericJam GenericJam deleted the docs/composite-warning-and-component-disambig branch July 5, 2026 02:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant