Lint warning when using props in solid-styled-components

[kavsingh]

When accessing props via solid-styled-components, lint warnings are shown:

The reactive variable 'props.theme?.colors.surface[0]' should be used within JSX, a tracked scope (like createEffect), or inside an event handler function. Details: https://github.com/joshwilsonvu/eslint-plugin-solid/blob/main/docs/reactivity.md.eslint[solid/reactivity](https://github.com/joshwilsonvu/eslint-plugin-solid/blob/main/docs/reactivity.md)

**Screenshots**

in VSCode

via eslint .

To Reproduce
Have put together a small repro here: https://github.com/kavsingh/solid-eslint-styled-repro

essentially:

• setup solid + solid-styled-components, with eslint-plugin-solid:recommended enabled
• use a styled.x using tagged template literal, use a theme or custom prop as described here https://github.com/solidjs/solid-styled-components#tagged-templates
• lint warnings are generated for prop access

Expected behavior
Would be great to use props without lint warnings, or having to disable reactivity rules inline

Desktop (please complete the following information):

• macOS 12.5
• Node version (node --version): 18
• eslint-plugin-solid version (pnpm list eslint-plugin-solid): eslint-plugin-solid 0.7.1
• eslint version (pnpm list eslint): eslint 8.20.0

Additional context
Realise this is not vanilla solid, this should probably have been an enhancement / feature request but could not change the label after creating the issue. I can make a new feature request issue if it works better. Is there a way to to use solid-styled-components without producing lint warnings?

Thank you! 🙏

[joshwilsonvu]

Thanks for the issue! Integrating better with community projects is something that I want to do with the reactivity rule now that it's maturing. Currently, there's a part of the rule that's essentially a series of if-statements that look for cases to turn this warning off, and to fix your issue I'd add a case for expressions in styled.* tagged template literals.

However, I don't really want to "bless" certain libraries with special cases while the ecosystem is still maturing. I thought about trying to accept custom cases from libraries, but that's a big ask.

But I think there's a quick solution that will fix your issue while remaining neutral to specific libraries—allowing reactivity in expressions in any tagged template literal where the expression is an inline function. That's cases like:

styled.div<{ opacity: number }>`
  padding: ${(props) => props.theme?.spacing[1]};
`;
css`color: ${props => props.color}`;
html`<div>${props => props.name}</div>`;
log`hello world! ${function(otherProps) { return otherProps.greeting; }}`;
css`color: ${() => signal()}`;

(but not these)

// too easy to forget to call `signal` when the template tag expects a value, not a function
css`color: ${signal}`;

// no declared intent to pass the function, not the result of the function call
const f = a => signal() + a;
css`color: ${f}`;

Any concerns? This will probably come out in v0.7.2, I'll close this when it's published.

[kavsingh]

that sounds great, thank you! 💯 agree about not making specific cases for specific libraries, so what you've suggested sounds like a good way forward 🙏 👍

[joshwilsonvu]

This should be fixed in v0.7.2, thanks for your patience!

[zjullion]

Just FYI - I'm getting these warnings in 0.7.4 with solid-styled-components version 0.28.5.