nested signals get parsed as strings.

[cbhrocks]

I am running into an error with how initial signal values are being parsed. Based on your examples here, I should be able to do this:
val person = dataSignals("person" to "{name: 'John Doe', age: 18}")
but the person signal gets initialized to a string, not a js object. heres an example:

div {
    dataSignal("test1", "{child1: 'value', child2: 1}")
    dataSignals("test2" to "{child1: 'value', child2: 1}")
    input {
        dataBind("test1.child1")
    }
    input {
        dataBind("test2.child1")
    }
}

the html generated looks like this (note the single quotes wrapping test1 and tes2 contents):

<div data-signals="{test1: '{child1: \'value\', child2: 1}'}" data-signals="{test2: '{child1: \'value\', child2: 1}'}">
	<input data-bind="test1.child1">
	<input data-bind="test2.child1">
</div>

when the signals are displayed using

pre {
    dataJsonSignals({ Unit }) { }
}

it creates the nested signal path itself, blowing away the entire contents of test1 and test2 signals due to them being initialized as strings and prints the following:

"test1": {
  "child1": ""
},
"test2": {
  "child1": ""
},

[cbhrocks]

one interesting note, using test1.setValue("{child1: 'value', child2: 1}") seems to work properly.

[PauloCarvalho13]

Thank you for catching this. The example is misleading: when a nested signal is provided as a String, it is serialized as a string value rather than parsed as a JavaScript object.

Our intended approach for nested signals is to model them with Kotlin data classes, as shown in SignalComplexDomainTest. This preserves the nested structure during serialization and provides the static typing we want HtmlFlow-Datastar to encourage.

We will update the examples in HtmlFlow-Datastar-Examples to avoid suggesting that object-shaped strings are supported. We will also look into improving the API or validation so that this mistake is caught earlier rather than silently initializing the signal as a string.

Regarding it working with test1.setValue("{child1: 'value', child2: 1}"), this is because setValue does not use the same serialization logic as the data-* extension functions, such as dataSignals. setValue emits the signal name directly with the value passed to it, without serializing the value as a string.

[cbhrocks]

I've been using strings instead of dataclasses for ease of use with quote escaping. for example, I can add a helper function onto the data class:

fun toSignal(): String {
    return SignalJson.encodeToString(this).replace("\"", """)
}

to convert it to json and escape the double quotations in my text inputs. Whats nice is this also works with the setValue function. I use setValue inside dataInit blocks for signals carrying form values. With a signal that has its type set to a data class, setValue expects the data class to be passed as it's parameter. the html generated for that doesn't seem to parse correctly though. for example:

div {
    val test1 = dataSignal("test1", TestDC("this is a test", 1))
    dataInit {
        test1.setValue(TestDC("Now a new Test", 2))
    }
    input {
        dataBind(test1.name)
    }
}

produces:

<div data-signals="{test1: {child1: 'this is a test', child2: 1}}" data-init="$test1 = TestDC(child1=Now a new Test, child2=2)">
        <input data-bind="test1">
</div>

[cbhrocks]

I think the real issue is that setValue forces you to pass the signals type, but then cannot parse it if its a data class.

[PauloCarvalho13]

With the new follow-up issues, #16 and #17, we will address the underlying causes of this behavior as soon as possible. This issue will remain open until both are resolved. If you encounter any additional problems or edge cases, please let us know so we can investigate them.