RFC: Static Props

[emdede]

Summary

This RFC looks for feedback on the addition of a reserved prop name which implies that a prop is not expected to change. This could be viewed as a compiler optimization but the driving point is that it helps shape the developer's mental model to be able to distinguish between "the wild west" where anything can update, and some other props which you don't want to change.

Background

I came across this when exploring the veracity of the eslint-plugin-solid reactivity warnings, which trigger anytime a prop is being used outside of a tracked scope. Rather than telling the tool that I indeed do not expect this prop to change, I think it would make more sense to introduce a way of telling Solid itself that I don't expect this prop to change. This comes with the added benefit of better compiler performance (if opted-in) because simply passing on a value is cheaper than wrapping it inside a getter (see a very basic benchmark example that somewhat showcases this).

Proposal

Add a reserved field to props which acts as an object of purely static props. I would defer the naming of said prop to the community. Something short and "unique" would come to mind, like $ or _ but in reality any such symbols have connotations attached to them, so I don't know. It could also just be a literal, like staticProps. For the sake of the argument I'll use $ from here on out.

Initially I was leaning towards making all props "static" and you have to opt-in for reactivity. But apparently Solid has moved on from this exact paradigm in the past. A lengthy discussion with a friend of mine also revealed to me that there exists a strong opinion of "As a component User, I want to be able to change the component's properties from outside". While I cannot argue with that point, I still think that there is something to be gained from being able to control a Component's props' shape from within, if needed. By adding a static prop option, this could be implemented in a 100% non-breaking way. It is an explicit choice of a developer to pass "static" properties.

In its simplest pseudo-code-ish form the props handling of a render would need to look something like this:

for (const propName in props) {
  if (propName === '$') continue // just don't touch it - no additional work required, pass it as-is
  doAsYouAlwaysDid()
}
return props

This is where the addition would incur a small overhead to any and all render invocations. This needs some more big-brainer opinions on how it could best be implemented.

In the long term there are also other things to consider. Like what about spreading props and wanting to add a static property?
<LeafComponent { ...props } $={{ additionalProperty }} />
But I consider this a Stage 0 proposal for now without going too much into implementation details.

Usage

You would declare the prop inside your props type as any other prop.

type Props = {
  dynamicLabel: string
  dynamicClass: string
  $: {
    neverChangingLabel: string
    neverChangingClass: string
  }
}

And then use it in whatever way you like.
To pass static props it would also be pretty straightforward.

<Label $={{ text: 'Foo' }} />

Or

<ReactiveTreasury $={{ mySignal, myMemo }} />
// note that you can pass "reactivity" down to a component even when using static properties

This would in fact also absolutely allow for destructuring props.
Reader discretion is advised

function SpecialComponent({ $: { label, placement }: MyProps) {
  let angle;
  if (placement === 'top') {
    angle = 0;
  } else if (placement === 'left') {
    angle = 270;
  }
  
  return (<div>
      <NestedComponent $={{ angle }} />
      {label}
    </div>)
}

Outro

I'm fairly new to the Solid universe and am not familiar with its history. If something like this has come up before (and if so, it has probably sparked heated debates) I apologize for rehashing it. For me this is really driven from the angle that I feel it's a real problem to always be in "Limbo" when it comes to the reactivity of your props, or as someone else put it

reactivity can come from the depth of the oceans, if you can't cover all cases, it is better not to cover any

I disagree (not with the statement, but with the sentiment). If the ocean is so vast that I can't know what's coming for me, I'll simply stay on dry ground, whenever I can.

All in all, I don't expect to get a lot of support for this. But something about this whole "getter just in case" thing just irks me. I can't really pinpoint it. Anyway, now it's out there and let's see what comes of it.

Edit: borrowed the structure mainly from Ryan's recent RFC, thank you!

[atk]

You can already easily mark any prop as static from the parent, by using /*@once*/; it would be helpful if the eslint plugin respected that. I don't think we need to complicate the whole props logic.

[emdede]

True, but this is not at all what I had intended with this RFC. /@once/ is passed down from a Parent, while I want this to be possible inside a receiving Component instead.

One way to look at it is that we split all props into let and const props. In the end they serve exactly the same purpose as let and const do.

There is one really straightforward example that showcases the immediate usefulness of this:

function NormalComponent(props: { maybeReactive?: string }) {
  createEffect(() => console.log(props.maybeReactive))
  return <div />
}

This is a fairly normal Component. But how about this?

function StaticProp(props: { $: { definitelyNotChanging: string }}) {
  createEffect(() => console.log(props.$.definitelyNotChanging)) // Lint warning; defintelyNotChanging will never update
  return <div />
}

Without even having to properly read the code you are able to immediately spot a case of mis-usage of a tracking scope. What this RFC stands for is a mental model that makes it easier to handle the craziness of "everything is dynamic".

[emdede]

Having said this, I think const Props is a better name for this whole thing as it much more clearly describes its intent.

The same semantic arguments about why to use let and const over var apply to dynamic/static properties. Mostly it leads to more comprehensible and predictable code both to a human eye and tooling.

[atk]

Another option would be to use an "initial" prefix for the const props to clarify that they are only taken initially, and change the eslint plugin to accept destructuring of those values. I don't think that the use case warrants changes to the core library.

[snnsnn]

 I want this to be possible inside a receiving Component instead.

Does not the destructuring give you a static value?

[atk]

Yes, but the linter cannot infer that, because it correctly assumes every possible use of all props.