Enhancement - Prop destructuring

[pureliani]

Prop destructuring is supported natively in JavaScript, and developers, often ones migrating from react to solid, are used to this pattern. Supporting it in SolidJS would lower the barrier to entry for newer developers.

This is personal opinion, but destructuring props directly in the function signature is more readable, developers can immediately see which props a component expects and uses.

And lastly, many IDEs and linters have optimizations and features that work well with destructuring, such as better autocompletion, checking for unused properties, type checking, and refactoring tools.

Personally i think the two big reasons are - lower barrier of entry and ease of use

[deluksic]

If this was easy to do, it would have been the default. The problem with it is that it doesn't work with reactivity where "reading is subscribing". This relies on getters. You can't implement the subscribe part if you destructure, as the component function body never reruns.

There is a community driven props destructuring plugin that rewrites your code, but I don't know how good that works. I feel like less compiler magic is better, but you have options for sure.

[pureliani]

If this was easy to do, it would have been the default. The problem with it is that it doesn't work with reactivity where "reading is subscribing". This relies on getters. You can't implement the subscribe part if you destructure, as the component function body never reruns.

There is a community driven props destructuring plugin that rewrites your code, but I don't know how good that works. I feel like less compiler magic is better, but you have options for sure.

Yes, i know that reactivity is lost when destructuring, but with the help of a compiler i don't think this would be an issue, i think this is the plugin which already does it, and to me this doesn't feel like compiler magic, more like, smoothening sharp edges of solidjs to make it look more like regular js

[deluksic]

Imo its magic because it (seems to) only work when having annotations on your functions which make them components. It is already pretty hard to get people who are used to react to understand reactivity. Now if you say, sometimes destructuring works, but only if you have this special annotation, that will be even more confusing. Personally, I would support this being core only if you can globally sove for this.

P.S. this would be better as a discussion than an issue. As it has been brought up many times.

[ryansolid]

I agree. If anything this is better as a discussion. As @deluksic said unless there was some unavoidable and automatic way to identify components this would never work. And more over it would take more than just handling function signatures if you wanted any sort of consistency. The complexity there is hard to merit.

Not that we are at that state now anyway. If we were to try to implement this it would make sense only to people already well aware of the problem, making the solution not any better than the problem as it interfere with teaching. Like why does certain things work and not others. It again requires too much specific knowledge.

[kuchta]

If you use compiler, than it shouldn't be too hard to tell if a function uses any sort of reactivity to handle it as a reactive component, right?

[ryansolid]

Right, cross module analysis. We were working on that at eBay in Marko 6. The idea is you generate metadata about each file as you process it an ensure that deps are processed before consumers. My experience is anyone who has tried to do this has not been able to deliver in a reasonable amount of time. It's also slow to build and compile as projects scale. At that point you are basically building a reactive language that isn't even JavaScript. I mean that type of analysis could have a lot of value beyond this so definitely a good place for research.

[pureliani]

it's not as simple as I thought 🤔, thanks for explaining

[kuchta]

Isn't that the default mode of compilation for most compilers including TypeScript? For sure, there are compilers that doesn't check types that can cut corners, but I don't think TypeScript isn't able to compile in reasonable amount of time for most projects. Also, if you are producing regular "destructured" JS, then it's not building reactive language (superset), but just less capable one (subset)...

[ryansolid]

TypeScript yes. But most framework compilers haven't gone there. Tools like Babel/SWC etc don't have this capability built in. You sort of make a system on top of it. I was actually hoping due to things like Ezno we could use types to help here but then you have to be pretty strict. Even React's upcoming compiler isn't tracing things this far I imagine and it has been no simple feat. It would be pretty cool if it could be built. There also might be assumptions that let it cut corners.

While destructuring hasn't been explored as globally to my knowledge, reactivity across file boundaries is something that a few have looked into. They were looking at it early in the design of Svelte 5, and I mentioned Marko. There are a few other less notable ones. Even things like Vue Ref Sugar proposal were designed as they were because of challenges there. I wrote a bit about this a few years ago: https://dev.to/this-is-learning/the-quest-for-reactivescript-3ka3

I'd love to see work done in this area. But I'm also practical and have other priorities myself.

[kuchta]

Than go with TS, there's already a Proposal and PR for official custom transformer plugin support. But some tools are able to use custom typescript transformers even now. Considering we are talking just about desctructuring here, it doesn't have to be supported by all tools in the ecosystem. You might as well say if you want to use desctructuring, it only works with this tool/bundler/whatever...

[deluksic]

It might even be a slight optimization, destructuring once at the beginning of a function can help avoid repetitive access to the props object which is slightly slower.

Can you elaborate on how this would work? I'm thinking this wouldn't help, because the transform would have to re-inject prop access in order to keep reactivity.

[pureliani]

Yeah, I guess that wouldn't work with solidjs, will remove that part from description

[FlatMapIO]

I used to think that Solid's way of handling props might be a hassle. Why not just pass around Signal everywhere? I felt that destructuring, mergeProps, and splitProps were burdens. But after using solid-start for a few months, I realized it's not an issue at all. It doesn't add any burden, and I barely even notice it's there.

[russelgal]

Are you kidding? )

[deluksic]

I would personally love for destructuring to somehow magically work, but I did not see a proposal or come up with something that would be completely transparent, i.e. not observable by accidentally creating bugs/issues in edge cases like event handlers and async.