You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
To be type safe, improve dev experience and prevent broken applications after a API changes, every API should provide types/models.
Lots of (all?) methods already provide models that can be used for implementing. Some event return types missing. Only object is retuned.
Especially after the migration from Quasar 1 to 2 there are some breaking changes that are only noticeable with testing or after the app broke in the part of change (and thats sometimes hard to find). If a type/model would be provided and used, changes would be noticeable right inside the IDE and compilation.
Describe the solution you'd like
Introduce event return models. For example for:
QLayout-API event objects (e.g. breaking changes of scroll event structure and prop names from Quasar 1 to 2)
The text was updated successfully, but these errors were encountered:
Hi, thanks for the issue report 👍 Breaking changes are thoroughly documented. The only concrete example you gave is QLayout's @scroll, which has been documented ~1 month before this issue got created, in this commit: d4cd48b#diff-64330052e9b5078f86f2422d71439b0a2e639765f3e7c60a38b81d4cedb4a01cR345-R346
So, if you follow the upgrade guide, you wouldn't face these kinds of problems. If something is missing from the upgrade guide, then it means it should be updated.
However, if you are asking to have a safety net in case of overlooking the upgrade guide, or maybe to avoid implementing something in a wrong way, etc. Quasar types have been fixed and improved a lot since then. You can use Volar to get the errors on your IDE or use vue-tsc to type-check your templates programmatically, they will check components, props, events, slots, basically everything you need!
If you need to reference Quasar types in your TS code, then you can import them and use them like QTable for template refs, QTableProps['columns'] for specific prop types, QTableProps['onRequest'] for event listener types, QTableSlots['header'] for using slots with render functions, etc. There are also more specific types like ValidationRule<T> to be used with rules prop of field derivative components, and there will be even more like QTableColumn which is planned for later.
So, considering all these, if you face any problems with the upgrade guide like wrong or missing info, or lacking/wrong types, please consider creating separate issues for your problems and explain the problems in detail, so we can track and solve them separately.
Is your feature request related to a problem? Please describe.
To be type safe, improve dev experience and prevent broken applications after a API changes, every API should provide types/models.
Lots of (all?) methods already provide models that can be used for implementing. Some event return types missing. Only object is retuned.
Especially after the migration from Quasar 1 to 2 there are some breaking changes that are only noticeable with testing or after the app broke in the part of change (and thats sometimes hard to find). If a type/model would be provided and used, changes would be noticeable right inside the IDE and compilation.
Describe the solution you'd like
Introduce event return models. For example for:
The text was updated successfully, but these errors were encountered: