A declarative, efficient, and flexible JavaScript library for building user interfaces.
by solidjsLast 12 weeks · 5 commits
5 of 6 standards met
Repository: solidjs/solid. Description: A declarative, efficient, and flexible JavaScript library for building user interfaces. Stars: 35288, Forks: 1041. Primary language: TypeScript. Languages: TypeScript (72.2%), JavaScript (27.6%), CSS (0.2%). License: MIT. Homepage: https://solidjs.com Topics: declarative, fine-grained, javascript, jsx, performance, proxies, reactive, solid. Latest release: v1.9.0 (1y ago). Open PRs: 21, open issues: 97. Last activity: 23h ago. Community health: 87%. Top contributors: ryansolid, thetarnav, otonashixav, Jutanium, trusktr, dependabot[bot], davedbase, bikeshedder, aminya, Gavin-Gong and others.
TypeScript
Summary Solid leaves type imports behind, causing some systems to try to import non-existing things at runtime. This relates to the node vs web structure. The app in question s , which s , etc, however does not use these APIs on the backend, only on the client. The workaround for the app is to use in client-side code, so it is ignored in SvelteKit pre-rendering. Here's a sample error: How did you test this change? Not done yet, need to test and update code
Summary At the moment typescript only allow the following signatures for SetStoreFunction interface; I'm hidding the type because it's not relevant for the discussion. Said another way, at the moment, the interface only allow for: exactly 1 arg exactly 2 args exactly 3 args exactly 4 args exactly 5 args exactly 6 args exactly 7 args exactly 8 args 8 or more args. My proposition is to add overload for the cases: 1 or more args 2 or more args 3 or more args ... 7 or more args So that it would be legal to write : Breaking change: Adding support for those cases means that this does not error anymore The reason for that is that the rest of the overload 1+ typing is not smart enough to inspect the second argument so it thinks that he is looking at a . I say it is not a big deal to lose this safety and it was a safety we didn't provide for case 8+ before my change anyway. How did you test this change? Commented the 2 failing tests Added some test for the new signatures pnpm test
Summary This makes it so that: Which is potentially unsafe, but is already allowed if e.g. was a instead. Note however that letting inference work will instead infer which the setter has no issue with. However this is only applicable when the original array already contains all the types you intend it to hold. There are performance concerns with this implementation. How did you test this change?