Props as explicit Accessors

[cdellacqua]

Hi, I've been playing around with Solid for quite some time now. From what I have experienced and from what I have read online, I think Solid could improve the way it manages props.

The problem

Props are currently implemented as proxy objects with getters that handle the reactivity, therefore to let the reactive system intercept their usage, we have to use them inside the JSX or inside a Solid reactive primitive like createEffect/Computed/....

A possible solution

An alternative way of doing things would be to use accessors. I think this would improve DX, enabling destructuring without breaking reactivity. This would also remove the need for some of the helper functions Solid currently provides (e.g. mergeProps would just be equivalent to {...props1, ...props2}).

As an example:

function Greetings({name}: {name: Accessor<string>}) {
  return <h1>Hello, {name()}</h1>;
}

function App() {
  return <Greetings name="John" /> 
}

Considering that writing Accessor<...> for every prop is not ideal, some helper types could be used:

type Accessorize<T> = { [K in keyof T]: Accessor<T[K]> }

function Greetings({name}: Accessorize<{name: string}>) {
  return <h1>Hello, {name()}</h1>;
}

function App() {
  return <Greetings name="John" /> 
}

Or, imitating React.FC:

type SolidFC<TProps> = (props: { [K in keyof TProps]: Accessor<TProps[K]> }) => JSX.Element;

const Greetings: SolidFC<{name: string}> = ({name}) => {
  return <h1>Hello, {name()}</h1>;
}

function App() {
  return <Greetings name="John" /> 
}

[lxsmnsyc]

The only problem I see here is that you're forced to treat props as "dynamic-first", which is contrary to Solid's compilation which is actually "static-first". Solid only generates getters for props that are assumed to be "dynamic".

Another problem would be spreading and applying this pattern to DOM elements.

Third problem would be event listeners, which are 100% static, same goes to ref.

Solid's compiler brings a lot of compile-time benefits, it helps decide Solid to not prematurely generate callbacks nor effects. But of course, users can still adopt the "accessor-first" design on their own.

On top of that, there's already 3P solutions to this that would allow users to adopt this pattern. For example, https://github.com/solidjs-community/solid-primitives/tree/main/packages/destructure

[cdellacqua]

Thanks for taking the time! Let me try to reply at each of your points.

Considering props are the only way descendants can communicate, it seems reasonable to adopt a dynamic-first approach in this context.

I'm not sure about this point about spreading and DOM elements, could you elaborate more on this?

Regarding the event listeners, as you say they are static right now, but not everywhere: Playground: Wrapping onClick. In this playground example you can see that the event listener is statically assigned to the button, but changing it still triggers the createEffect callback. This asymmetric behaviour could be fixed by "accessorising" the props.

The 3P package you linked is nice, though I'd prefer a built-in solution to this problem.

[lxsmnsyc]

Considering props are the only way descendants can communicate, it seems reasonable to adopt a dynamic-first approach in this context.

The problem with dynamic-first approach is that Solid will be creating functions unreasonably, on a perf standpoint, this isn't desirable. Static-first ensures that functions are only created when necessary.

I'm not sure about this point about spreading and DOM elements, could you elaborate more on this?

Spreading is probably the most problematic feature of Solid currently (there's a lot of blindspots). With accessor props, there's a lot to change in the types.

Regarding the event listeners, as you say they are static right now, but not everywhere

I forgot to mention that this applies to the DOM elements. Event listeners are one-time registration.

The 3P package you linked is nice, though I'd prefer a built-in solution to this problem.

TBF this proposition has been discussed multiple times (at least on the Discord channel, which was talked about very recently: https://discord.com/channels/722131463138705510/1005785836316524644) but with how stable Solid is right now, shifting the behavior of the whole renderer would introduce a lot of breaking changes, I don't think many people will like it, specially as a perf downgrade.

Probably other options may help? Something like https://github.com/vobyjs/voby
Or better yet, a Babel plugin: https://github.com/lxsmnsyc/solid-labels/blob/main/docs/ctf.md#component

[cdellacqua]

I think you are overestimating the impact on performance: from what I gathered of how solid processes components, those extra functions would only impact the first rendering, because then reactivity would kick in and only update what’s necessary without extra function calls. Furthermore, the impact on performance would only affect static props.

I agree that this is quite a redesign, but it may be considered for a v2 because of the advantages in terms of DX and flexibility.

[ryansolid]

Yeah selling any performance regression is harder. But we've made that move a couple of times in the past, like when we went from always explicit reactive wrappers to our current heuristic. I think spreads are probably the pain here especially with dynamic props. We go from getter objects to proxies and in this case I guess it would to proxies that created accessors on request. There would still need to be a mergeProps as the properties of a give object need to be able to change reactively without re-running. Right now we benefit from stores and props sharing the same APIs the incidental benefit of objects being reactive being the pattern so we don't need to go and map everything to objects of accessors. Like say spreading a store.

When this suggestion came up first about a year ago. I have to admit I was intrigued because admittedly it wasn't a direction I'd gone far on, as the time at which Solid was being built was back when POJOs were very much in fashion and no one wanted things that looked like Reactivity or Hooks. Proxies were the glue that made many things possible. The challenge here is this doesn't remove the need for proxies. Sometimes the whole props object needs to be a signal so to speak. Like {...props1, ...props2} isn't actually equivalent. Funny enough at one point they were and we coasted like that for a couple years but eventually it became clear the expectation is we needed more flexibility.

The destructuring thing is a pain point for many developers and admittedly I avoided this because I didn't use that pattern much in React when I developed in it due to us using reactive store technology so I can't appreciate perhaps how ingrained it is. But given the tradeoffs I'm not sure it's worth it.

[afranchuk]

I came to the discussions section to make this exact suggestion. The original suggestion here lays out a number of reasons I wanted to point out. The dissimilarity of props vs signal access is a bit frustrating to me; I like the design decisions behind other aspects of the API, and I like that stores at least are an opt-in and optional case of a proxy-driven API, but props always using this API has some downsides.

As mentioned in the original suggestion, you end up with a bunch of extra code to work around this design decision (mergeProps, splitProps, https://github.com/orenelbaum/babel-plugin-solid-undestructure, etc), which doesn't feel good (and isn't necessarily intuitive, especially for beginners). And of course, I need hardly mention the many bugs people report where they are accidentally breaking reactivity. Even with some experience it's a mistake that's all too easy to make.

There's also some other things that easily break because of this. For instance, I'm trying to use the HyperScript API as a JSX factory function, but prop spreads break due to this limitation (the generic JSX transform doesn't know about mergeProps of course), and I'm forced to manually use the API in those cases. BTW, that should probably be mentioned in https://github.com/solidjs/solid/tree/main/packages/solid/h where it talks about using it as a standard JSX transform. I absolutely understand that the HyperScript-as-JSX-factory-function case has a very minor impact, but it is annoying to have so many caveats on it all the same.

FWIW, the "entire-props-as-a-signal" case brought up by @ryansolid is necessarily far less common scenario than prop access, so I feel as if the API shouldn't be a proxy to better support that. I realize that's not the sole reason for the current design; I'm just pointing it out. That's a case where some helper {...spreadPropsSignal(props1)} function is fairly trivial to write (for users or as a library API), and it could potentially be automated by the compiler as well.

If possible, I'd really like it if there were at least some way to configure this behavior within a particular project, so a project can decide which API they'd prefer (and it'd help for things like my case with the HyperScript JSX transform). That's not the best outcome in that, with two APIs, you fragment developer understanding a little if they interact with many different projects (presumably projects they don't author, since those they do will likely be consistent with their preferences). TypeScript softens the blow with explicit props types at least.