runtime type consistency in expression evaluation.

https://github.com/webzard-io/sunmao-ui/blob/5fe5163733/packages/runtime/src/services/stateStore.ts#L106-L108

Currently, we handle expression evaluation errors with error logs but will return undefined as the result.

This makes components can not predict the types of props in runtime. For example, a component may define a props foo with type number which is required, but if the evaluation throws an error, the component may get undefined as the foo props value.

Possible solution: do not render components in ImplementWrapper when expression evaluation failed.

[MrWindlike]

Yanzhen worries about it will cause silent bug if we fallback to default value. Maybe displaying error message maybe could avoid this problem.

I think the component developers should handle the property’s value could be undefined condition caused by a wrong expression or empty input and consider whether to provide a default value for the property or throw the errors.

Displaying the error messages could help the Sunmao users fix some expression errors but can’t avoid them totally so I think we should handle the wrong expression in some ways.

As to the default value, should we defind default value in spec?

Yes. When switching the JS mode, the expression string is hard to display by the other widgets. Thus, I think maybe set the property to the default value when switching the JS mode.

In addition, I think we should also remain the exampleProperties in the spec because the defaultValue is used to init or reset or be a fallback and the exampleProperties is used to show the base usages of components when inserting the components.

[Yuyz0112]

@tanbowensg

I think this is an issue of soundness.

What’s the expected behavior when a user writes a wrong expression like {{ const a }} and passes the schema to sunmao-ui’s runtime?

Responses I’ve thought about:

• sunmao-ui’s runtime crash and throw the original expression error to the global scope
• sunmao-ui’s runtime catch the error and render a mask UI to display the error
• sunmao-ui’s runtime catch the error in component level and render a mask UI to display the error on top of the corresponding component
• sunmao-ui’s validator catch the error and show a wrapped error message
• sunmao-ui’s runtime catch the error and fallback to defaultValue, then log the error to console

Of course, there may be some different ways to handle this in dev/production environments or in runtime/editor scope, but I think we can start from the specific one.