Evaluating making store props signals

[christianalfoni]

Currently when providing a store:

function App(props) {
  return (
    <AppStoreProvider user={props.user}>
      <Editor />
    </AppStoreProvider>
  )
}

Any props are passed "as is" to the store. That means the props passed to a store are the ones passed when first calling the AppStoreProvider in this example. If the props.user changes... nothing happens in the store.

So if you want to observe the user it is expected that you subscribe to updates in the store:

function AppStore(props) {
  const apiStore = useApiStore()
  const user = signal(props.user)

  cleanup(apiStore.subscribeUserUpdates(props.user.id, user))

  return {
    get user() {
      return user()
    }
  }
}

But it could be that the props.user sent to the store actually is being updated.

So this made me think about this bridge between Impact and React. From react => impact we make values signals and from impact => react we make signals values.

So it IS possible to:

function AppStore(props) {
  const user = props.user

  return {
    get user() {
      return user()
    }
  }
}

Basically all props to stores becomes signals. I think this conceptually makes sense and makes this "values <=> signals" bridge very obvious. So the cost here is really that you can not consume props directly, you have to unwrap the value. For example props.user().id.

I am leaning to this being even expected API and behaviour 🤔

[christianalfoni]

Decided to implement this