Image for post
Image for post

Many companies have multiple portals, and having them share common code is certainly the scenario we’d prefer, so what are the challenges to sharing code between Nuxt projects?

Normally shared code is in the form of an npm package with importable components, and that can be done with Nuxt, but the thing about Nuxt is that it offers some lovely features that are exclusively tied to its directory structure, and it only allows for one such structure.

What if we want to share pages, layouts or components between projects? …

Image for post
Image for post

Some devs fetch data in components and put the results in the store, others make Ajax requests inside store actions. The former might need more control over the Ajax or prefer decentralization, the latter may want components abstracted from state management.

I’m in the latter group, and I say that components shouldn’t know where or how to get data, only what data they need.

So instead of , the message we really want to communicate is .

What’s the difference?

Imagine you have 2 components on a page that leverage the same data. You may have some top level orchestration component (e.g. a page component) which is responsible for coordinating components and possibly loading all necessary data. Or you may want components to be as self-sufficient and loosely coupled as possible, if they request their own data, then it is easier to use/reuse them anywhere. …

Image for post
Image for post

So we got the first look at the code for vue-next, still in pre-alpha so some waiting left. But finally we can start to put some of our theories to the test. While Vue 2 does not support ES2015 Collection types, Vue 3 supports Map, Set, WeakMap and WeakSet. For Vue 2, this means that any mapped reactive data must use an Object as a map.

If you use ID lookups for data in your Vuex store, or even if you don’t, you might be aware of a nuisance problem in Vue 2 reactivity.

Say we have the following reactive user…

Image for post
Image for post

We’re going to talk about a common request when working with relational data in Vuex. Why and how to cache method-style getter invocations, though the principles would also apply to method-style computed properties.

If you have been following recent Vue v3 RFCs, you might have come across the Advanced Reactivity API, which comes as a very welcome direction for Vue to take. This article is written using Vue v2, but ultimately the code will be simplified if this RFC is implemented.

Firstly, although both property-style and method-style getters offer caching as part of core Vuex functionality, method-style getter invocations do not cache results. …

Image for post
Image for post

With all the buzz about the next major release of Vue, there is plenty of intrigue surrounding announced features, one that caught my attention was:

Better debugging capabilities: we can precisely trace when and why a component re-render is tracked or triggered

In this article, I’ll be talking about what we can do now in Vue 2.x to trace reactivity and maybe tune some stray code that might impact performance.

Image for post
Image for post

Why Reactive code might need tuning

If you work in a large codebase, you are probably using Vuex. …

Directive Lifecycle and Directive Linting

Image for post
Image for post

If your codebase is anything like the ones I’ve known, it has plenty of code like this template.

<label>{{ $t('login.username') }}</label>
<input type="text" placeholder="{{ $t('login.user.placeholder') }}">
<label>{{ $t('login.password') }}</label>
<input type="password">
<button>{{ $t('login.submit') }}</button>

For anyone who aims to write DRY code, or simply dislikes mixed syntaxes, this probably doesn’t give you a warm fuzzy feeling.

When researching available tools we, at, decided to use i18next. This library has a very mature and rich set of functionality, it also has a large community and is framework agnostic.

There are Vue plugins with in-built conveniences when using i18next within a Vue project. However our requirements were simple and the basic functionality could be achieved in 2 lines (within a Vue plugin). …

Image for post
Image for post

Those who have browsed the Vue.js v2 documentation, may have come across a guide in the advanced section, Reactivity in Depth.

Vue will walk through all of its properties and convert them to getter/setters using Object.defineProperty.

Hmmm, So, why might a Backbone developer be intrigued by this? Well Backbone has been around since 2010, when the first IE version to support had yet to be released (IE9), let alone the last one not supporting it to disappear from use! Today, this is a feature we can utilize in relative safety, but how?

From the Backbone docs:

A Model manages an internal table of data attributes, and triggers “change” events when any of its data is modified. …


Michael Gallagher

Living in the vibrant city of Buenos Aires, developing eCommerce software with Hip. Modern JS is my passion, Vue my tool of choice

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store