SolidJS•13mo ago

show is rendering children when still falsy

I have a simple parent component in a CSR setup

  const [data] = createResource(params, async ({ id }) => {
    const out: AlreadyExistingForm = await invoke("get_config", {
      id: Number(id),
    });
    return out;
  });

  return (
    <Layout>
      <Show when={data()}>
        <EditS3ConfigForm initialForm={data()} />
      </Show>
    </Layout>
  );

  const [data] = createResource(params, async ({ id }) => {
    const out: AlreadyExistingForm = await invoke("get_config", {
      id: Number(id),
    });
    return out;
  });

  return (
    <Layout>
      <Show when={data()}>
        <EditS3ConfigForm initialForm={data()} />
      </Show>
    </Layout>
  );

When reading the props in the child component though, the props are undefined

export function EditS3ConfigForm(props: {
  initialForm?: AlreadyExistingForm;
}) {
  console.log(props)
  const [form, setForm] = createStore(props.initialForm ?? defaultState);

export function EditS3ConfigForm(props: {
  initialForm?: AlreadyExistingForm;
}) {
  console.log(props)
  const [form, setForm] = createStore(props.initialForm ?? defaultState);

This logs out an empty object. I understand the value im passing as a prop is not a signal but I dont think that should matter because the value should exist when initially rendering the child component

31 Replies

foolswisdom•13mo ago

Is the props object empty of getters as well, or empty of values? Dynamic props are compiled to getters, so the value indeed does not exist (and dynamic expression - data() in this case - does not run until that prop is accessed)

SeanAyeOP•13mo ago

Oh yea It looks like safari dev tools was playing tricks on me once I bound the props to dom nodes it displayed as expected so safari doesn't show the proxy getters

foolswisdom•13mo ago

BTW the data variable is a read only signal with additional behaviors tacked on

SeanAyeOP•13mo ago

and it looks like an empty object Yea the resource? I'm not too concerned with loading state because its a local app takes like 10ms to resolve the resource

foolswisdom•13mo ago

Technically these are unrelated to the "Proxy" feature of Javascript, although they are proxying by virtue of being getters. Unless you use a store, solid won't use proxy objects at all I was commenting on the statement in your question that the prop passed was not a signal

SeanAyeOP•13mo ago

oh I see thanks!

foolswisdom•13mo ago

Unless you were referring to the fact that you were passing by value instead of by reference (we usually do recommend pass by value, and have the compiler wrap in a getter)

SeanAyeOP•13mo ago

pass by value like clone the object? all objects are pass by reference I thought or you mean each primitive in the obj is a prop

foolswisdom•13mo ago

No When I say reference, I mean the signal When I say value, I mean to evaluate the signal and pass the contained value

SeanAyeOP•13mo ago

ah right

foolswisdom•13mo ago

I'm probably the only person here using that terminology for this

SeanAyeOP•13mo ago

Yea that makes sense in most contexts but in this case I dont care about the value after the initial render so unwraping the signal in child is not required

foolswisdom•13mo ago

It is never required Because you can treat the prop access the same as evaluating the signal, because it's actually a getter access That's why the getter access exists I gave a presentation about this once https://wonderful-pegasus-9e6649.netlify.app/1 Use the arrow keys to move between slides

SeanAyeOP•13mo ago

I'm not sure I follow If I change the prop to a signal then I need to do this in the child

export function EditS3ConfigForm(props: { initialForm?: Accessor<AlreadyExistingForm> }) {
  console.log(props);
  const [form, setForm] = createStore(props.initialForm?.() ?? defaultState);

export function EditS3ConfigForm(props: { initialForm?: Accessor<AlreadyExistingForm> }) {
  console.log(props);
  const [form, setForm] = createStore(props.initialForm?.() ?? defaultState);

this is "unwrapping" the signal, subscribing in the child but since I dont care about reactivity this seems unnecessary

foolswisdom•13mo ago

My point is that it is unnecessary even if you did care about reactivity Though in your case, since component level code is not reactive, that code would never be reactive You can pass the value (not the signal), and still expect props.initialForm to be reactive. Because accessing that property accesses the getter which calls the signal. So you are actually calling the signal at the point of prop access

SeanAyeOP•13mo ago

ohh ok I understand

foolswisdom•13mo ago

In other words, your code would look like it is passing a value, but it would not be

SeanAyeOP•13mo ago

so even when you unwrap signal in parent the child value remain reactive as long as you dont destructure

foolswisdom•13mo ago

Yeah

SeanAyeOP•13mo ago

so you don't need to litter the types with Accessor everywhere

foolswisdom•13mo ago

Because destructuring is accessing the getter at component level, which is not tracked Correct

SeanAyeOP•13mo ago

ok yea yea I got it, sorry that took me a second

foolswisdom•13mo ago

Most solid components (see any of the component libraries, for example) rely on this mechanism

SeanAyeOP•13mo ago

I'm coming from leptos where this doesn't happen in quite the same way

foolswisdom•13mo ago

Aha, okay I'm not familiar with how leptos does rendering

SeanAyeOP•13mo ago

its based on solid

foolswisdom•13mo ago

I guess you need to actually pass the signal Oh I know about sycamore and leptos I'm just not familiar with how they actually do things Never took a close look As we have just seen, there are differenences 🙂

foolswisdom•13mo ago

I wonder if they're more similar to https://github.com/vobyjs/voby in that way

GitHub

GitHub - vobyjs/voby: A high-performance framework with fine-graine...

A high-performance framework with fine-grained observable-based reactivity for building rich applications. - GitHub - vobyjs/voby: A high-performance framework with fine-grained observable-based re...

foolswisdom•13mo ago

(made by our own @fabiospampinato)

SeanAyeOP•13mo ago

In leptos you need to be explicit about props being reactive or not https://docs.rs/leptos/latest/leptos/enum.MaybeSignal.html

MaybeSignal in leptos - Rust

A wrapper for a value that is either T or Signal.

SeanAyeOP•13mo ago

so if it is the signal variant it will be reactive and if it is the static variant it wont thanks for all your help!

Gaming

Programming

show is rendering children when still falsy