I've seen references to getCurrentInstance() function on some old(?) documents and codes, but cannot find it in the current Vue 3 document.
Is getCurrentInstance() deprecated?
If so, what is the reason? (inject() considered enough?) If not, why can't I find it in the document?
getCurrentInstance() was removed from the Vue 3 docs because it's an internal API:
Because the instance is an internal instance that exposes non-public APIs. Anything you use from that instance can technically break between any release types, since they are not subject to semver constraints.
getCurrentInstance() was originally documented in 4-Oct-2020, but that was later removed in 31-Aug-2021 in a major refactoring of the Composition API docs by the creator of Vue (Evan You). Despite its removal from the docs, getCurrentInstance() still:
is widely used in Vue core.
is not documented as deprecated in code.
is exported as part of the Advanced API.
Given that it's an undocumented internal API, use it with caution.
https://github.com/vuejs/vue/issues/12596#issuecomment-1173269807
quoting the comment from evan,
getCurrentInstance is used mostly for official vue libraries that need additional internal access, not for userland application code. It was mistakenly documented in WIP v3 docs but is no longer considered a public API
The VueUse library extensively uses getComponentState() to detect if code is called within the component lifecycle.
For example:
https://github.com/vueuse/vueuse/blob/main/packages/shared/tryOnBeforeUnmount/index.ts
I'm going to go out on a limb and say,
"If it is good enough for the VueUse maestro antfu, it is good enough for me."
So although officially deprecated, it is still essential until Vue provides a method such as isInComponentLifecycle().
My recommendation is to only use it for this type of detection, and avoid accessing it's members if possible.
Related
Is it possible to install Vue 3, but still do things the "Vue 2" way? In other words, I see that Vue 3 has the new Composition API, but is that optional or the required way of doing things in Vue 3?
For some reason, I was thinking that Vue 3 still allowed you to do things the Vue-2 way, using the Options API instead. Is that not the case? Thanks.
Vue 3 does not require using the Composition API. The Options API is still available and will not be removed, as explained by two Vue core team members:
Thorsten Lünborg in Vue 3: Data down, Events up (19-MAY-2020):
IMPORTANT: The composition API is additive, it’s a new feature, but it doesn’t and will not replace the good ole “Options API” you know and love from Vue 1 and 2. Just consider this new API as another tool in your toolbox that may come in handy in certain situations that feel a little clumsy to solve with the Options API.
Ben Hong in Enjoy the Vue #48: "New in Vue 3: The Composition API" (19-JAN-2021):
[00:01:03] T: Yeah. Well, the first thing I remember hearing was that it was replacing the options API.
[00:01:08] BH: Big disclaimer. That isn’t happening. Big disclaimer.
...
[00:09:10] BH: [...] this is not something you need to go and rewrite your app in. [...] the composition API is not like, drop the options do composition. It's an additive thing that when you have a problem that it can solve, it's really great for that.
An early RFC for the Composition API had only considered deprecating the Options API:
A previous draft of this RFC indicated that there is the possibility of deprecating a number of 2.x options in a future major release, which has been redacted based on user feedback.
The Vue docs also confirm this:
Will Options API be deprecated?
No, we do not have any plan to do so. Options API is an integral part of Vue and the reason many developers love it. We also realize that many of the benefits of Composition API only manifest in larger-scale projects, and Options API remains a solid choice for many low-to-medium-complexity scenarios.
I'm wondering if there's someone knowledgeable in Vue(2 or 3)'s reactivity that might be able to answer this question and explain reasons.
This is regarding features such as data() reactivity (getters & setters), computed properties, a global Vue instance, and even a Vuex store.
Is there a way I could tap into just these non-browser javascript features for use in a backend-only Node.js application?
I need a way to have a global store holding temporary data that can update "components" in other files via mapState/mapGetters.
I'm using lowdb currently for this because it suits my needs in terms of shapeable JSON objects, where something like redis is key:value-only. (Don't want to get into a more complex redis/rejson setup.)
Basically I need a globally accessible relatively-full-featured reactivity system on the backend, without global variables or needing to set up a custom Rxjs system, which is a bit over my head and will take too much momentum away from my goals, time-wise.
I'd appreciate any input. Thanks 🙂
Vue is designed to run inside Node to support SSR (server side rendering). There is already a good post here on SO with simple sample for Vue 2 (using Vue + Vuex)
But it seems overkill to me. If you want something much simpler and lightweight, you can use package #vue/reactivity which is normally part of the Vue 3 but can be used completely standalone. It is basically Vue 3 reactivity system based on JS proxies
Why would I choose this approach:
No Vue 2 Change Detection Caveats
More "functional" API (designed for their new Composition API) with much better support for TypeScript and type inference (even without TS)
I think Vuex API is super bad (using string constants for data mapping - especially with modules. It's pain...)
As it is part of Vue 3, you can use it's documentation:
Basic Reactivity APIs
Refs
Angular 2+ offers Modules (NgModule)s that "configure the injector and the compiler and help organize related things together." They are another layer of code organization, to facilitate modularity of parts of large scale applications.
I am NOT talking about Node modules. Angular has those too. NgModule is unrelated to that.
So far in learning Vue.js, I'm not coming across anything that is analogous to NgModule. Searching for this information was not fruitful on search engines. Is there anything? Or does Vue.js in some way make them not necessary?
They are another layer of code organization, to facilitate modularity of parts of large scale applications.
No, ngModule is the only way the Angular ahead-of-time compiler can discover, walk and tree shake providers that are not required for the project. This includes things like components, directives, services, etc that you would define in modules.
So far in learning Vue.js, I'm not coming across anything that is analogous to NgModule.
You shouldn't because this is an Angular specific feature. Vue has no dependency injection or lazy loading as a core feature.
Or does Vue.js in some way make them not necessary?
You might be confusing Angular NgModules with JavaScript modules. The two are not the same, because Angular uses NgModules to make it's dependency injection system work. Without the DI there really is no need for NgModule. Angular would then work the same way Vue and React work, and use the JavaScript import to resolve dependencies.
Angular is an opinionated (I don't mean that as a negative) and monolithic framework. It uses ngModules for organization. They are a benefit by default. Vue is a progressive framework that allows you to include as much or as little as you want.
Vue Plugins allow for mass registration of components if you need it, but you can just as easily narrow your dependency tree using explicit import/export statements.
Vue Bootstrap has a Vue Plugin mechanism that allows you to include all of the features outright including the custom elements it provides but also allows you to import each component individually if that is what you want.
Angular Powered Bootstrap provides an ngModule in much the same way but also allows you to include components piecemeal if you want.
The key thing here is that Vue tries to be as non-opinionated as possible and lets you configure how you want dependencies included whereas Angular wants you to do everything its way. Neither way is outright better than the other. You benefit from knowing how do to things by default with the opinionated way vs having way too many choices with the non-opinionated way.
Consider this question, how do you perform network requests with each of these frameworks? The answer is obvious for Angular: HttpClient. However, you can use whatever request library you want in Vue, be it fetch, axios, jQuery.get() or anything else as long as you appropriately deal with Vue's reactivity model. You can likely do the same thing in Angular, but you're going outside of Angular's suggested approach.
You likely don't see a lot of documentation about comparable things to ngModule because Vue doesn't really push for organization in that manner. Again, not a judgement, it's just a difference in how the frameworks are intended.
What is the most elegant way to get a riot based UI today?
i'd love the following points to be addressed:
A proper code-mapping for easy debugging
A good way to bundle the application (so far i used Webpack and JSPM)
It would be lovely if it would work elegantly with Typescript.
Is it best to use Tag files, or straight JS? If the later, would it be better to use a class that inherit from riot's tag class? If so, can i place the template code in a different file?
Future compatibility: i saw that there's going to be a change (that "export default" thing) - how would you recommend to write the code for the smoothest migration path?
If you have more items for consideration - please add them....
Thanks for asking these questions. I have tried to answer to all your questions hoping they could be useful also to other Riot.js users
A proper code-mapping for easy debugging
the riot compiler generates simply javascript code without modifying too much the structure of your original source code. Any modern browser should be able to provide with debugger breakpoints and console calls all the debugging tools you need. Check for example the stack trace of this error you don't need much more to figure out where it's coming from.
A good way to bundle the application (so far i used Webpack and JSPM)
In this repo we provide 3 different javascript bundle examples: rollup, webpack, riot-compiler. I personally prefer rollup but you can (and should) use whatever works best for you and your team.
It would be lovely if it would work elegantly with Typescript.
The riot public methods are already available as Typescript interfaces:
- https://www.npmjs.com/package/#types/riot
- https://www.npmjs.com/package/#types/riot-route
I am not a typescript user and that's why I will not invest time in making examples in a technology I don't use but PR are welcome
Is it best to use Tag files, or straight JS? If the later, would it be better to use a class that inherit from riot's tag class? If so, can i place the template code in a different file?
I recommend you to just use Tag files because riot was designed as component library and it embraces completely the philosophy of components composition vs class inheritance. If you have code you share across several components you can either use mixins or import it with your bundler directly in your tags see for example
Future compatibility: i saw that there's going to be a change (that "export default" thing) - how would you recommend to write the code for the smoothest migration path?
Riot 3 will be not compatible with Riot 4. (that will be a full rewrite) I can't recommend any best practice to make your code portable to Riot 4. Remember that Riot 3 will be still supported and your code will run even on IE9 for the next 10 years. Once riot 4 will be released and the API will be stable I can provide more hints about a migration path.
In the documentation a method [[MQALogger defaultSettings] setReportOnDoubleSlideEnabled:false] is mentioned. But the library does not have such a method. Is there a library update that contains this method?
The reason for this question is, that the shake gesture is already used in our application.
Starting in version 2.x of the iOS library, APHLogger has been deprecated and replaced with MQALogger. Deprecated methods that have not been moved to MQALogger can continue to be used from APHLogger, in the near term, but they will be removed at some point in the future. It is recommended to move to the supported interface and its methods. When using the MQALogger interface, note that settings is used instead of defaultSettings. Specific to the setReportOnDoubleSlideEnabled method, try using [MQALogger showReportScreen] to launch the reporting screen.
The double slide feature has been deprecated, so it is more than possible to have since been removed from the production rather than revived.
See this question: How to use MQA setReportOnDoubleSlideEnabled in an iOS App?