My first impressions of Vue & Nuxt
I’ve recently picked up a project which has been written in Vue 2 & Nuxt and I thought I’d document my initial impressions in the hope of doing a follow up in a couple of months time to see if my gut feeling holds true.
For context, I’ve got about 4 years of working with React and React Native in various different professional and personal capacities so this does influence how I feel somewhat.
I’ll try to stop this post from becoming a Vue vs React one but I won’t deny that some of my love of more immutable & functional code comes from working with React.
This post won’t be a deep dive into the inner workings of either technology, nor will it be that structured. I’m writing this to capture my initial thoughts, so don’t expect to learn much.
Previously I had written Styleguides with tools like KSS and got tired of having other developers take my examples, butcher them and then complain that things didn’t look right and I thought web components would solve all these issues.
With a lot more experience under my belt I no longer think defining CSS in your components is a good idea (I’m ok with importing) as this mixes the concerns of structural and presentational logic.
However, it feels backward to me that you define your mark up which can contain HTML, other components (who’s name changes case between definition and use) and presentational logic (
v-if etc) and then you define the script which returns the data that template will use.
This approach means I have to translate my component’s data definition into what will be rendered, jumping through logic within the component’s template to get a better idea of the final output.
It may be there’s a design pattern I don’t know about which will give me a more functional syntax but for now I can’t say I find Vue’s component structure easy to work with.
State management (Vuex)
While Vuex isn’t a first party library of Vue it’s something that I think a lot of Vue developers work with so I think it’s worth covering as I have a few gripes with it.
The first thing that really stood out to me about Vuex is the fact that state is mutable and while I understand that you don’t call the state mutations directly, the fact that you’re directly updating state instead of creating a new object doesn’t sit well with me.
This mutable state has led to a number of discussions around unit testing as it was common for people to create a mutable state object, pass this into the mutation to update it and test the expected state value was updated.
This test approach however does not detect unwanted state mutations and I can’t help but think if the state updates were immutable that this wouldn’t be such an issue.
I do like the term ‘getters’ for reading values out from the store though as it feels a lot more semantic than the term ‘selectors’ that Redux uses.
So far I find Nuxt ok but I guess this is mostly due to the fact that I’ve not had to do too much with it but there is one thing I’ve yet to really understand the need for — modules.
The code base I work with has 3 different APIs it needs to communicate with, each with their own credentials for authentication and while in something like React I’d have created an API module with functions for handling calls to these APIs it appears in Nuxt the approach is to use
I guess this is similar to my issues with mutable state in Vuex but something doesn’t feel right about using
this.$axios as I can’t guarantee what state it’s in before I use it.
These are just my initial thoughts on Vue and Nuxt and it’s likely my opinion on some aspects will change as I learn ways of working with these technologies in a manner that I’m happier with.
For now though I would say I very much prefer React to Vue.