I have a Vuejs SPA that I want to clean-up and do some refactoring on. One thing I would like to do is detect
Unused or extra props defined in custom components. I don't mean within the component itself (this I do via eslint-plugin-vue), but when the component is instantiated somewhere in the app within another component.
Unused or extra $emits defined in custom components. Again, are there $emit that are never actually handled when instantiating a component?
Identify component's data that actually dont need to be reactive and can be removed from data
Unused components
Unused exports in my js files
The linter I use, eslint-plugin-vue, does its work component by component but here I want to be checking unused stuff across several components.
I could not find any built-in tool for these tasks, what's the best way to do this?
Even if the app contains hundreds of components I could still do this manually, but ideally I would like to run this process frequently to keep the app clean.
After some research I ended up writing my own node.js script using regex for parsing my codebase. It's too ugly for me to post it anywhere but it is <300 lines and writeable in a day or so.
Related
Currently when importing components from another file to be used inside the template part, if the name of the component is not correct, Vue just gives a warning about this. Is there any way to configure it so that it errors during compilation or building, so that it is easier to do refactoring or moving around components, since in Nuxt, we can enable auto-discovery component, just that we need to include the directory it is in as well as part of the component name. For example, if I have a component named PhoneNumber inside base folder inside components folder, I can use that component directly by using BasePhoneNumber.
I have tried disabling the auto-discovery component in Nuxt, and I got a lot of this unknown custom element as expected. But this only triggers the warning, which I can only see the warning when I'm browsing that page. So there's a big chance of making a mistake where I update the name of the component in one page, but another one in another page is missed
I am about to create a Vue.js project and i use the smart/dumb pattern for my ui components. In my dumb components I have already the input, buttons and etc..., but in my smart components I am curios if it is really necessary to create a component if i will use that only in one page. For example. login-form component, then i will use that only in login page. So, ⤵️
My first question, is it really necessary to create a component for that ?
Second question, and when will i gonna create a smart components?
Moving code to another components makes code of initial component more readable. Even if you are going to use that new components only once.
Usually smart components - are pages that fetch or simply share some data to its children.
I'm new to Nuxt and Vue in general, so I'm not sure, what would be the best solution for this use case.
I want to change the text (like "Home", "Settings", "Favourites" etc.) inside my Header.vue (always fixed on top of the page) from another component. like Favourites.vue for example.
Sometimes I want to hide the header completely or hide the title and display buttons instead,
so I need to pass more props than just the title.
I tried using different layouts, but that breaks the animation transitions (I haven't found the solution for this yet), but I think it's still better to have control from the page in what I'm passing into this component.
Should I pass props from Page.vue to parent and read it from there in Header.vue component?
Should I use Vuex to pass this through the store and update it when the route changes? Or is that too complex for this use case?
Maybe there's a simpler solution that I'm not aware of.
Folder structure:
/components
├──Header.vue
└──Nav.vue
/pages
├──Index.vue
├──Profile.vue
├──Settings.vue
└──Favourites.vue
Vuex is the answer here— don’t worry about the 'simple' use case. As soon as you notice you’re creating data that other components may rely on (is the header visible on this page? Is the text different? etc) it’s a good idea to move into Vuex and maintain a single source of truth.
Your app may seem simple to begin with, but it’ll inevitably grow and at that point you’ll appreciate having a single source of truth vs. trying to pass things between components via props.
Nuxt also makes implementing Vuex very straight forward. No doubt you’re capable of pulling up the docs!
I have a component library where i would like to standardize the props, component etc.
Thoughts on combining them props/methods/other mixins/etx into one larger mixin
All property names would be the same
Remove duplicated code on refactoring to adjust components from local props/methods/computed/ to "global"
Not all components would have need for every piece of data contained within the mixin - point 4
Would tree shaking remove the unused code on Rollup?
Is this a good idea?
If your component library is not constrained to using Vue 2 you might want to take a look at Vue Composition API to share functionality (methods + reactive state) between different components.
Mixins might not be what you really want to be using because you kind of lose information as to what features/props/methods really will be put inside your component without re-checking the mixin code. You also might run into issues when component options get merged by Vue at runtime. Check out these posts for more information:
https://css-tricks.com/how-the-vue-composition-api-replaces-vue-mixins/
https://reactjs.org/blog/2016/07/13/mixins-considered-harmful.html
As for sharing props: What I've seen just yesterday (but not yet tried!) in a talk by John Leider - creator of Vuetify - is create a function that returns the props you want to reuse between components. Then you just call said function inside your props definition and use the spread operator.
I construct deep nested tree of parent and children Vue custom components using my top level component dynamically and then I am updating the data from which all tree is constructed. Which has an effect of rendering the entire tree (its a form with various custom components). I refresh/rebuild the whole form after fetching the data (which is what vue do for reactive data) that itself tell me how to regenerate the view (its like a JSON Schema from which I render the entire view).
This is related to my other issue here.
I am observing a very weird behavior in my Vue Application. When I destroy all my children components and rebuild the data to force rendering the form, it appears that even after I have called $destroy on every child component...Vue is not entirely removing them from cache?
Does vue remove the component from cache if a $destroy is called ?
Because I do not see multiple components of the same type in the Vue component list in the Chrome Vue DevTool extension panel. But I see that the same custom event is handled twice by the same component. Same function that handle the events is getting called twice even though there is only one component visible in Vue DevTools of this type.
This only happens after I render the form. When the page is loaded for the first time every thing works. Then after I reset the form by destroying the child component and resetting the data to re-render the form, magically this child component start handling the event twice.. and in 3rd render it handle the events thrice. But I see only one component in google chrome VueJS DevTool extension panel. So my guess is that vue is still keeping the previously destroyed component in cache. I am trying to figure out how should I destroy those components in the cache.
If anyone has observed something similar and found a solution please let me know.
At the moment I am going to dig little bit more on my component keys (this particular component does not have explicit key set by me).
First and foremost, the vue documentation states:
vm.$destroy
In normal use cases you shouldn’t have to call this method yourself.
Prefer controlling the lifecycle of child components in a data-driven
fashion using v-if and v-for.
So instead of destroying and rebuilding the components manually yourself, you should really letting vue handle that via v-if and v-for. If the components aren't updating to your changes, you might be dealing with a reactivity issue.
As you mentioned that this is a deeply nested structure, the reactivity is key to keeping the components up to data with the data.
Vue does not allow dynamically adding new root-level reactive properties to an already created instance. However, it’s possible to add reactive properties to a nested object using the Vue.set(object, key, value) method:
Vue.set(vm.someObject, 'b', 2)
Inside of a component:
this.$set(this.someObject, 'b', 2)
Also, keep in mind that Vue should be doing the heavy lifting in regards to component management, while you should define the parameters by which a component is rendered.