Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings
/vuePublic

fix(types): no props typings in js files#13109

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Open
Ilanaya wants to merge3 commits intovuejs:main
base:main
Choose a base branch
Loading
fromIlanaya:fix-define-component

Conversation

Ilanaya
Copy link

@IlanayaIlanaya commentedNov 1, 2023
edited
Loading

What kind of change does this PR introduce? (check at least one)

  • Bugfix
  • Feature
  • Code style update
  • Refactor
  • Build-related changes
  • Other, please describe:

Does this PR introduce a breaking change? (check one)

  • Yes
  • No

If yes, please describe the impact and migration path for existing applications:

The PR fulfills these requirements:

If adding anew feature, the PR's description includes:

  • A convincing reason for adding this feature (to avoid wasting your time, it's best to open a suggestion issue first and wait for approval before working on it)

Other information:

This PR intended to fix an annoying problem that caused no type support forprops injs files. As it said itts documentation unspecified types defaults toany which caused the wholeprops object to becomeany.

Explicitly specifying the typeunknown in generic should fully fix this problem.

References:
Similar PR addressing the same issue but with a bit harder solution

KnownVue language tools issues which are closed as upstream because of this bug.
vuejs/language-tools#2347
vuejs/language-tools#1537

zardoy and Ilanaya reacted with thumbs up emoji
computed:{
test(){
//@ts-expect-error Invalid typecast if `this.a` is not any
;/**@type import('../utils').IsAny<typeof this.a> */(this.a)
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Ifthis.a isany this conversion wouldn't result in an error

Copy link

@dcq01dcq01 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Hi! I'm a grad student working on a research project about using large language models to automate code review. Based on your commite509aeb and the changes in types/test/v3/define-component-test.js, my tool generated this comment:

  1. Parameter Validation: Ensure that theprops object is validated before being used in thedefineComponent function. Ifprops is expected to contain certain types or structures, there should be checks to confirm that these are present and valid.
  2. Handling Undefined or Null Values: If thedefineComponent function is called withprops that may be undefined or null, it should handle these cases gracefully.
  3. Type Checking: Implement runtime type checking to ensure that the values passed toprops conform to the expected types.
  4. Error Handling: If thedefineComponent function encounters an error due to invalid props, it should have a mechanism to handle such errors without crashing the application.
  5. Logical Evaluation: Verify that thedefineComponent function correctly handles prop types. Ensure proper validation for the prop types defined in theprops object.
  6. Direct Feedback: Add or modify tests that specifically check the behavior of thedefineComponent function with various prop types. Confirm that components using different prop types behave correctly and that any errors are handled appropriately.
  7. Test Coverage: Ensure that there are existing tests that validate the behavior ofdefineComponent with respect to prop types. If there are no tests that specifically check for the correct handling of prop types, it would be prudent to add them.
  8. Edge Cases: Consider adding tests that cover edge cases for the prop types defined in theprops object.
  9. Specificity: Ensure that subsequent tests accurately reflect the behavior of prop types. Revise any tests that do not align with this focus.
  10. Conclusion: Further verification of thedefineComponent function's implementation and the associated tests is necessary to ensure that the functionality aligns with the new description. If the tests do not adequately cover the expected behavior of prop types, additional tests should be implemented.

As part of my research, I'm trying to understand how useful these comments are in real-world development. If you have a moment, I'd be super grateful if you could quickly reply to these two yes/no questions:

  1. Does this comment provide suggestions from a dimension you hadn’t considered?
    1. Do you find this comment helpful?

Thanks a lot for your time and feedback! And sorry again if this message is a bother.

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Reviewers

@dcq01dcq01dcq01 left review comments

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

2 participants
@Ilanaya@dcq01

[8]ページ先頭

©2009-2025 Movatter.jp