Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Client element claims fire before dynamic attributes are applied, and only `href`/`action` writes re-claim

Closed
  • Is something wrong?
#3,923 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
24/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
typescript
Domain
compilers, frontend

Research direction

Start with the claim ordering in packages/compiler/tests/fixtures/dom-source-names/bindings/output.js, where _$claimElement runs before _$spread sets href and title, then read setAttribute in packages/web/src/client.ts for the claimed-attribute check. The issue offers two fixes, claiming after initial bindings or re-claiming on target, rel, download and similar writes, and a maintainer has to pick one first. Done means a claim consumer sees final initial attributes and is notified of later changes, with the compiler fixture updated to match.

Written by the indexing model from the issue text.

Description

Context

Compiled DOM output calls claimElement(node) at element creation for a[href] / form[action] so consumers (e.g. @solidjs/router link state) can manage navigation-relevant elements. Related: #3878 (server-side claim hole).

Problem

The claim fires before the element's dynamic attribute bindings are first applied — see packages/compiler/__tests__/fixtures/dom-source-names/bindings/output.js, where _$claimElement(_el$22) precedes the _$spread(_el$22, …) that sets href/title. Afterwards, setAttribute in packages/web/src/client.ts re-claims only on href/action writes (including via spread, which routes through assignProp → setAttribute). So a consumer sees the anchor without its final attributes and is never told when they arrive. Writes to target, rel, download, link (router's opt-in attribute), prop:href (property path) and xlink:href (setAttributeNS) don't re-claim.

Consequence (router)

<a href="/x" target={t()}>, download={…}, rel={…} get link state (aria-current / data-active) and interception treatment as if those attributes were absent — on initial mount and late mounts (<Show>) — until the next navigation. The router currently compensates by re-processing every anchor in its location-change sweep, including newly mounted anchors a second time in the same navigation, purely to correct claim timing.

Proposal (either)

  • (a) Claim after the element's initial attribute bindings are applied, so the claim sees final initial attributes.
  • (b) Also re-claim on writes to target, rel, download (ideally a consumer-declared set, e.g. link).

(a) fixes mount; (b) also covers later toggles. Server side has no ordering problem since SSR emits all attributes together.

Cost

None without a registered claim consumer (claims are dormant null checks); for (b), a few extra name comparisons in setAttribute's claimed-attribute check.

Dominant language
TypeScript
Stars
36.1k
Forks
1.1k
Avg merge
11h 27m
Merged PRs (30d)
351

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from solidjs/solid

All issues in solidjs/solid

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.