Change behavior of prop tracing to avoid evaluating lazy values

[gbj]

The issue is #1952: Passing a lazy type like a derived Signal or a Memo as a component property now causes them to be eagerly evaluated before they're actually used. This is because the Serialize implementation for signals/memos reads their value. This is surprising because users do not expect these values to be read simply by passing through a component, and it changes the behavior/execution order of the program.

Switching to Debug, which doesn't read the inner value of a memo/signal, resolves the issue, but changes exactly what is logged by this tracing integration.

@luoxiaozero I'd be curious to hear your thoughts on this, since it was your contribution initially. Is switching to Debug here compatible with your use case, or do we need to try some further autoref specialization to create a special implementation for reactive types that doesn't use Serialize?

[luoxiaozero]

1. I have a question, why do lazy types (derived Signal or Memo) implement the Serialize trait, is it used internally by leptos, for user convenience serialization, or both？

2. For development tools, only deserialization is required. Debug can be used as a temporary solution for the moment, since Debug may not be stable in the future. https://doc.rust-lang.org/std/fmt/trait.Debug.html#stability

Is switching to Debug here compatible with your use case

You can add a field to indicate the method of serialization

or do we need to try some further autoref specialization to create a special implementation for reactive types that doesn't use Serialize?

Can't seem to handle nested memo.

[gbj]

I have a question, why do lazy types (derived Signal or Memo) implement the Serialize trait, is it used internally by leptos, for user convenience serialization, or both？

Solely for convenience: So that you can, for example, do

#[derive(Serialize)]
struct MyData {
  foo: RwSignal<String>,
  bar: Memo<i32>,
  baz: bool
}

I think the best solution here might actually be to add a tracing feature to leptos_dom, and gate the tracing_props on that. Then, we wouldn't be serializing props in a way that's unexpected by users, but in a way they could opt into or out of.

[luoxiaozero]

Totally agree, but could there be a more explicit name for the tracing feature, such as trace-component-props? Because I am leptos-devtools in the implementation of a component tree display and the component of signal properties. In the future, I might implement monitoring signal value changes. Then I can add a trace-signal featrue for leptos_reactive, and finally a devtools featrue for lepots. To enable all DevTools-related features. (Just my initial thoughts, of course)

[gbj]

Yes, this makes perfect sense to me. I'm going to close this and open a different PR that keeps the Serialize approach but feature-gates component prop tracing. Thanks for your input.