Skip to content

Fix useModelMigration in async components #6608

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 our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: stable8
Choose a base branch
from

Conversation

baltitenger
Copy link

It was using getCurrentInstance() which, as I understand it, isn't part of vue's public API anymore and isn't guaranteed to work in every situation.

Makes call site a bit uglier, but I don't think there's a better way to do it.

☑️ Resolves

🏁 Checklist

  • ⛑️ Tests are included or are not applicable
  • 📘 Component documentation has been extended, updated or is not applicable
  • 3️⃣ Backport to next requested with a Vue 3 upgrade

@ShGKme
Copy link
Contributor

ShGKme commented Mar 11, 2025

It was using getCurrentInstance() which, as I understand it, isn't part of vue's public API anymore

It is a part of exposed Advanced API. It was called internal in the past indeed. Because it returns ComponentInternalInstance which is internal API and can be changed. However, Vue 2.7 is EOL so the result will never change. Also, Vue 2 didn't have a separation to ComponentInternalInstance and ComponentPublicInstance - so the result is a public instance.

and isn't guaranteed to work in every situation.

Could you clarify on a case when it isn't supposed to work?

@ShGKme ShGKme added bug Something isn't working 3. to review Waiting for reviews labels Mar 11, 2025
@ShGKme ShGKme added this to the 8.24.0 milestone Mar 11, 2025
Copy link

codecov bot commented Mar 11, 2025

Codecov Report

Attention: Patch coverage is 73.33333% with 4 lines in your changes missing coverage. Please review.

Project coverage is 43.11%. Comparing base (4c77334) to head (2e98a83).
Report is 222 commits behind head on master.

Files with missing lines Patch % Lines
src/components/NcActionRadio/NcActionRadio.vue 50.00% 1 Missing ⚠️
...ents/NcActionTextEditable/NcActionTextEditable.vue 50.00% 1 Missing ⚠️
...ts/NcCheckboxRadioSwitch/NcCheckboxRadioSwitch.vue 0.00% 0 Missing and 1 partial ⚠️
src/components/NcSelectTags/NcSelectTags.vue 0.00% 1 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##           master    #6608      +/-   ##
==========================================
+ Coverage   42.50%   43.11%   +0.60%     
==========================================
  Files         156      161       +5     
  Lines        4028     4108      +80     
  Branches     1036     1070      +34     
==========================================
+ Hits         1712     1771      +59     
- Misses       2200     2218      +18     
- Partials      116      119       +3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@baltitenger baltitenger force-pushed the usemodelmigration-fix branch from 2e98a83 to 85af9e5 Compare March 11, 2025 10:36
@baltitenger
Copy link
Author

Could you clarify on a case when it isn't supposed to work?

I'm not actually sure, I think I read somewhere that it's only guaranteed to work from lifecycle events but setup is one, so I don't know why it wouldn't work in this situation. But I did observe it returning null so clearly it can happen (see the mentioned issue).

Another thing, I just noticed that I forgot to update the jsdoc comment for useModelMigration, but I'm not sure how to type these two new parameters. (plus typescript-language-server seems to ignore typing information in jsdoc, I guess in typescript you're supposed to have it inline)

@baltitenger baltitenger force-pushed the usemodelmigration-fix branch from 85af9e5 to 28495f8 Compare March 11, 2025 11:13
@ShGKme
Copy link
Contributor

ShGKme commented Mar 11, 2025

I'm not actually sure, I think I read somewhere that it's only guaranteed to work from lifecycle events but setup is one, so I don't know why it wouldn't work in this situation

getCurrentInstance only supposed to work when there is the current instance - in the setup context. Same as all the other Composition API function and composables.

And the setup function has the setup context. Otherwise not only this function wouldn't work here, but any composable and even reactive effect wouldn't be cleared after component is unmounted and etc.

But I did observe it returning null so clearly it can happen (see the mentioned issue).

I'd guess that you test not with installed @nextcloud/vue, but with npm link to local @nextcloud/vue. In this case there are 2 copies of Vue in different node_modules. And Vue doesn't support it in general.

In this case, you need to either use npm pack instead of npm link to have a complete reproduction of installed package, or resolve vue as alias to app's node_modules.

It was using getCurrentInstance() which, as I understand it, isn't part
of vue's public API anymore and isn't guaranteed to work in every
situation.

Signed-off-by: Baltazár Radics <[email protected]>
@baltitenger baltitenger force-pushed the usemodelmigration-fix branch from 28495f8 to 472f504 Compare March 11, 2025 16:59
@ShGKme ShGKme modified the milestones: 8.24.0, 8.25.0 Apr 2, 2025
@susnux susnux modified the milestones: 8.25.0, 8.26.0 Apr 16, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
3. to review Waiting for reviews bug Something isn't working
Projects
None yet
Development

Successfully merging this pull request may close these issues.

useModelMigration broken in async components
3 participants