Summary
The js-react shiny create template's example app raises a client-side error on first render:
Cannot destructure property 'value' of 'object null' as it is null
The error is thrown inside the template's own renderComp in shiny/templates/package/js-react/srcts/index.tsx:
makeReactOutput<{ value: string }>({
name: "custom-component-output",
selector: "custom-component-output",
renderComp: ({ value }) => ( // ← destructures `value`, but the payload is `null`
<div style={{ backgroundColor: value, ... }} />
),
});
When @posit-dev/shiny-bindings-react's renderValue(el, payload) is invoked with payload === null during the initial output lifecycle, the destructure of null throws.
Reproduction
shiny create --template js-react --package-name my_component --dir /tmp/my_component
cd /tmp/my_component
npm ci && npm run build
pip install -e . shiny
shiny run example-app/app.py
# open in browser → red error overlay / DevTools console shows the destructure error
Fix (probably template-side)
Either guard the renderComp:
renderComp: (data) => {
if (!data) return null;
return <div style={{ backgroundColor: data.value, ... }} />;
}
…or change @posit-dev/shiny-bindings-react to skip rendering when the payload is null.
Pre-existing, not a regression
Verified the bug is unrelated to #2237's lodash bump — it reproduces against both the original lodash 4.17.21 lockfile from main and the patched 4.18.1 lockfile in #2237. See #2237 for the testing setup that surfaced this.
Summary
The
js-reactshiny createtemplate's example app raises a client-side error on first render:The error is thrown inside the template's own
renderCompinshiny/templates/package/js-react/srcts/index.tsx:When
@posit-dev/shiny-bindings-react'srenderValue(el, payload)is invoked withpayload === nullduring the initial output lifecycle, the destructure ofnullthrows.Reproduction
Fix (probably template-side)
Either guard the renderComp:
…or change
@posit-dev/shiny-bindings-reactto skip rendering when the payload is null.Pre-existing, not a regression
Verified the bug is unrelated to #2237's lodash bump — it reproduces against both the original
lodash4.17.21lockfile frommainand the patched4.18.1lockfile in #2237. See #2237 for the testing setup that surfaced this.