Add a way to have placeholder or dummy data that are only shown in the preview.

[ogoffart]

When developing a component, it is useful to add dummy data for models and things that are not part of the application but would be useful to have when previewing.

Suggestions:

component Foo {
   // Load all 'in' properties from a json file  (relative to this file)
   // (only for preview)
   @dummy-data("./file.json")

   // the 'dummy' built-in function is like an identity function in preview mode, 
   // but is deleted and the default value is used in production.
   in property [{name: string, age: int}] model: dummy([{name: "John", age: 85}, {name: "Jane", age: 16}]);
}

The preview could offer an UI to edit these.

The slint-viewer can also load these or have an argument to remove them. (it can already load json with --load-data but that'd be orthogonal)

Exact naming of these macros/functions can be discussed.

[Enyium]

I had a case where a property of type float needed to have its dummy data removed, because, in conjunction with a changed-callback that was only called on actual property value change, my two widgets that the changed-callback filled, weren't initialized, when coincidentally the initial real data set from Rust was the same value as the dummy data.

So, this mechanism wouldn't only be useful for models, but also for other data types.

And you'd still need to be able to specify the initial run time data in the property declaration (in a case like the above, the possible data from Rust could also include the default value, necessitating another initial value to make sure the changed-callback is triggered). So, simply dummy() with a single argument wouldn't suffice.

[jturcotte]

I like the dummy function approach. Like an assert or debug_assert I think that it should be as close as possible to the relevant code/property. It also make refactoring easier than having a loosely coupled dummy data file and make the migration from inline to/from dummy almost effortless.

But if you go with a JSON file, consider adding the --load-data argument to slint-lsp instead of having it defined inside the language. I didn't try that feature myself but having the same interface as slint-viewer sounds like a good idea and it should be possible to set it into the slint.lsp-args VS Code workspace setting, or adding an extra extension setting for that purpose. It would also allow adding VS Code tasks to launch slint-viewer with different data files for different scenarios without having to change the code.