Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Generic `/tools/widgets/{name}` namespace for link-driven blocks

Aperta
  • Qualcosa non va?
#12 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Tranquilla
Stack tecnologico
javascript
Ambito
frontend, web-dev

Direzione di ricerca

Inizia leggendo linkBlocks e decorateLinks in scripts.js, quindi esamina come il blocco dell’intestazione trova /tools/widgets/scheme, /language e /toggle. Risolvi la collisione dello namespace, il contratto dei parametri del widget e se sia necessario un dispatcher prima di definire l’ambito dell’implementazione. Il lavoro è completato quando lo namespace e il comportamento della migrazione sono stati decisi e documentati nel codice o nella documentazione del progetto.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Problem

linkBlocks in scripts.js is a registry, and registries in config files grow:

const linkBlocks = [
  { fragment: '/fragments/' },
  { schedule: '/schedules/' },
  { youtube: 'https://www.youtube' },
];

Every new link-driven experience means another bespoke top-level path and another entry. The
naming is ad hoc (/schedules/ vs /fragments/), and nothing signals to an author that these
are the same kind of thing.

Proposal

A generic /tools/widgets/{name} namespace, with query params for configuration:

/tools/widgets/mortgage-calculator
/tools/widgets/article-list?filter=category|tech&limit=6&sort=publishDate

Authors get one predictable prefix; the config stops growing per widget.

Namespace vs. dispatcher

These are separable decisions, and the second may not be worth it.

If the block name is simply the last path segment, /tools/widgets/mortgage-calculator resolves
to blocks/mortgage-calculator/mortgage-calculator.js with no central module involved. One
config entry, no growth, no indirection. Params come free — the widget already receives the
anchor as el, so new URL(el.href).searchParams is available.

A blocks/widgets/widgets.js traffic cop that maps names to modules is the same registry
relocated: still a file to edit per widget, plus an extra module on the load path. It earns its
place only if widgets share real behavior (param coercion, a common failure mode, loading
states) — and that is a util each widget imports, not a wrapper each widget hides behind.

Two wrinkles

The header already occupies this namespace. /tools/widgets/scheme, /language and
/toggle are sentinels the header block finds via href*= after its fragment loads — they are
not widgets and are not auto-blocks today. Making the prefix a catch-all means decorateLinks
claims them first and tries to load blocks/toggle/toggle.js inside the header fragment. Either
they move to their own namespace, or they become genuine widgets and the header just styles
wherever they land. The latter is probably the better end state.

Not everything collapses into it. /fragments/ and /schedules/ are content-addressed —
the path says which content. Widgets are behavior-addressed. Folding schedules in costs
authors ?path=/schedules/foo, which is worse than what they have. YouTube can't be a path at
all. Realistically the list lands at three-ish entries, one of them elastic.

Open questions

  • Is linkBlocks still the right name? It describes the mechanism (a block made from a link)
    rather than the intent. widgets fits the new namespace but not /fragments/ or YouTube, so
    the rename may belong to the namespace rather than the config key.
  • Do header actions migrate into the widget namespace, or move out of it?
  • Are widget params a documented contract (coercion, defaults, validation), or left to each
    widget?
Lingua principale
JavaScript
Stelle
12
Fork
19
Merge medio
7m
PR unite (30g)
2

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di aemsites/author-kit

Tutte le issue di aemsites/author-kit

Issue simili

Altre issue su JavaScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.