You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Name the router's reactive primitives so attribution diagnostics say which query is waiting (liveQuery status, query versions, router memos) #691
With Solid's attribution engine on (attribution.enable(), rc.16), every diagnostic that involves the router's data layer names its sources "signal" or "computed". A SILENT_HOLD on a Studio page in our app reads:
Those are liveQuery status signals. Neither a person reading the console nor an agent reading /__solid/diagnostics can tell which live query was connecting, so the diagnostic cannot be acted on without bisecting by hand. The query version signals and the router's own memos have the same gap.
src/data/query.ts:322 and :437: the entry's version createSignal(stamp, { ownedWrite: true }) → name: \query:${key}``
Router internals with no name, which appear in tear/waterfall diagnostics: routing.ts (url, pathname, search, hash, queryFn, matches, the lazyTreeVersion signal, the link state/active/current/pending memos), routers/factory.tsx:364 (location signal), routers/components.tsx (data, routeStates, matchesAtLevel), pending.ts:24, data/action.ts:313.
@solidjs/signals already accepts name on all of these (SignalOptions.name, MemoOptions.name), and it is dropped in production builds.
Proposal
Name every primitive the router creates. Data-layer ones should carry the user's key (query:<name><hash>, liveQuery.status:<name><hash>), and internal ones should use a router. prefix (router.location, router.matches, …). A test that runs a page with attribution.enable() and asserts that no reported source is named "signal"/"computed" would keep it that way.
Happy to send a PR if that direction sounds right.
Activity
feat: name data-layer and location primitives in dev; #687 regression…