User story
As a consumer embedding InteractiveMap on an element that carries app-specific data-* attributes,
I want the component not to log a console error for every attribute that isn't valid JSON
So that my browser console isn't filled with SyntaxError lines that look like real failures
Acceptance criteria
This story is done when:
Notes / constraints
In _buildConfig, the dataset reader copies every key from rootEl.dataset and passes each value through JSON.parse; the helper logs the caught error:
function d(e){try{return JSON.parse(e)}catch(e){return console.log(e),null}}Consumers commonly mount the component on an element that already carries app attributes — e.g. data-csrf-token="NV3T3p…", data-save-and-continue-url="/quote/draw-boundary/save", data-back-link-path="/quote/boundary-type". Each one produces:
SyntaxError: Unexpected token '/', "/quote/dra"... is not valid JSON
at JSON.parse (<anonymous>)
at d (im-shell.js:1:1605)
at p (im-shell.js:1:2065)
at G._buildConfig (im-shell.js:1:14167)
Two aggravating factors:
console.log(err) of an Error object renders with error styling in devtools, so it reads as a real failure- The parse result for those keys silently becomes
null in config, which also risks confusion for anyone passing string config via data-* (a raw string value can never survive this path)
Observed identical in 0.0.46-alpha and 0.0.48-alpha.
Possible directions (any one): only attempt JSON.parse for keys the library consumes; fall back to the raw string when parsing fails; or demote/remove the log.
Repro: new InteractiveMap(el, options) where el has data-example="hello" → console shows a SyntaxError.
(Re-filed from #527, which was accidentally created from the wrong account — closing that one in favour of this.)
User story
As a consumer embedding InteractiveMap on an element that carries app-specific
data-*attributes,I want the component not to log a console error for every attribute that isn't valid JSON
So that my browser console isn't filled with
SyntaxErrorlines that look like real failuresAcceptance criteria
This story is done when:
data-*attributes (URLs, CSRF tokens, dataset ids) produces no console errorsdata-*attributes continues to workNotes / constraints
In
_buildConfig, the dataset reader copies every key fromrootEl.datasetand passes each value throughJSON.parse; the helper logs the caught error:Consumers commonly mount the component on an element that already carries app attributes — e.g.
data-csrf-token="NV3T3p…",data-save-and-continue-url="/quote/draw-boundary/save",data-back-link-path="/quote/boundary-type". Each one produces:Two aggravating factors:
console.log(err)of anErrorobject renders with error styling in devtools, so it reads as a real failurenullin config, which also risks confusion for anyone passing string config viadata-*(a raw string value can never survive this path)Observed identical in 0.0.46-alpha and 0.0.48-alpha.
Possible directions (any one): only attempt
JSON.parsefor keys the library consumes; fall back to the raw string when parsing fails; or demote/remove the log.Repro:
new InteractiveMap(el, options)whereelhasdata-example="hello"→ console shows a SyntaxError.(Re-filed from #527, which was accidentally created from the wrong account — closing that one in favour of this.)