Type safety
Last updated
Last updated
A solid type system is an important driver of reliable and maintainable software systems. While coding in Uify is currently focused on JavaScript as primary programming language, there is a basic type system in place to avoid errors and guide the user towards correct usage of the exposed API.
The built-in type system currently supports the user in the following places:
Getters and setters of components, e.g. the setValue function of a Text Input component expects string | null as argument, and accessing value returns a string
All exposed properties of actions are typed (e.g. executionTime is number | undefined, success is boolean | undefined, and so on) and the trigger function returns Promise<unknown>
Other exposed objects like dateFns, nanoid, state, notify and inbox have strictly typed properties and methods
You can find details about all types of exposed properties and functions in the component reference.
Violations are highlighted in our code editor in the same way such errors are displayed in your typical IDE:
In this example, there are multiple violations against the type system:
setValue expects a string or null, but the provided value is of type number
state.setMyVariable expects a single argument (the next value of the state variable myVariable), but two arguments were provided
The notify.success function expects two arguments (the message and a timeout in milliseconds), but only one argument was provided
Hovering over the place of error provides additional information about the error. Additionally, hovering over properties or functions reveal their particular type definition:
The current type system is only the beginning of what we envision for the future of type support in Uify. The following features could drastically improve the coverage and usefulness of the type system:
Ability to declare types of state variables, to have explicit typing of setters and getters of such variables.
Automatic type inference of action results. For example, the fields of database query result sets could be automatically inferred to provide a better typing of the action data property than just unknown
Ability to declare accepted types of action args, to highlight invocations of the trigger function with incomplete or wrong arguments, and to use args inside of an action in a typed manner
Full TypeScript support in all code editors
We are going to add such features step by step, and hope that it leads to a better developer experience and more reliable software being built with Uify.
