Filter alternatives in vuejs

About three months ago I started using filters in my vue-template files. I created a whole formatter-library in our private NPM-repo with the aim to use the functions in there as filters. I had also started promoting this strategy (well discussed beforehand) with my colleauges. And then I found out that …

In vue 3 filters will no longer work. My colleagues, who have experience back to vue 1, tell me the vue-team has tried to get rid of filters before. They hope Evan and his team will change their minds for vue 3.1. However, if they don’t, there are decent alternatives.

So what are filters? They are a way to format input in a vue-template. The syntax looks like this:

<div>{{number | euro}}</div>

The ‘euro’ filter can format the number to include a euro sign and perhaps format the number in an EU-locally appropriate way.

I like this syntax because reading from left to write I first get the value and the variable the value is coming from and only then what it will be formatted as. Since the formatting is usually an (important) afterthought and rarely relevant for bug fixing, it makes sense to have it last.

There are basically two ways to circumvent filters for this purpose:

  • Methods
  • Computed properties


Using methods in templates feels off. It’s a rarely used method in the documentation and for obvious reasons: it means that the method gets called again and again, without caching. However, under the hood filters and methods are precisely the same thing, so it’s not an argument against methods as a replacement for filters. The syntax is pretty obvious:


Again: the euro method will transform the number into a string starting with a euro-sign. Just like a filter, but the syntax is just slightly less obvious on first sight. You will first notice that you’re dealing with euro’s and only then with the actual variable.

Computed properties

My template files are full of computed properties. From transformed data to simple references to my vuex-store. However, in order to use them to transform my data to something humanly legible I would have to do something like this (assuming my number isn’t coming from some long list of data):

computed: {
    number(){return 5},
    euroNumber(){ return this.euro(this.number) }

This means that the underlying ‘number’ property is hidden behind the euroNumber property, which necessitates an extra step when debugging. However, this approach does mean that the resulting ‘euroNumber’ variable is cached, which can speed up the application, especially when there is a lot of data.


I will miss filters. When we transition over from vue2 to vue3, I guess we will mostly use methods instead.

NextTick vs setTimeout in Vue

TL;DR : what you want is probably setTimeout.

To understand the following, you may want to watch (or watch again) the famous ‘What the heck is the event-loop?‘ video by Philip Roberts. Five years old, and still relevant. Watch till the end, because we’re interested in the following three aspects of the way browsers render javascript:

  1. call stack
  2. render queue
  3. (async) callback queue / task queue

Philip Roberts only touches on the render queue briefly at the end, but for us it’s crucial.

The call-stack always has priority. When it’s empty, the browser will start outputting what’s in the render queue. When that’s done it’s time for the callback queue.

Basic problem

When you use Vue to calculate something difficult, like opening all the nodes in a tree with thousands of nodes (actual use-case), it takes a while. For the user, this may be confusing. So you want to give them some indication that: ‘yes, we’re working on it’, say some sort of animation. You probably also want to disable the button they just clicked.

The problem is that without some extra work, the browser will show the animation just as it finishes doing that long calculation. By which time you’ve turned the animation off. Pseudo-code sample:

this.animation = true;
this.animation = false

-> browser shows change in tree, animation never called.

What happens is that the render-queue isn’t called until both those calculations are done. Not good. What you want is something like this:

this.animation = true;

-> browser shows animation


-> browser continues to show animation

this.animation = false;

> browser shows change in tree and stops showing animation. User happy (or happyish, because it did take a while)

So how come the second doesn’t happen? Because the render queue waits till the call stack is empty, before actually rendering. Our calculationStart ends up on the call stack and blocks it. The render queue doesn’t even get called, until the calculation is done.

Not good.


So how do we get our animation to start in the browser, before the calculation starts? You may have picked up on ‘nextTick’ and thought – that sounds promising.

In order to wait until Vue.js has finished updating the DOM after a data change, you can use Vue.nextTick(callback) immediately after the data is changed. The callback will be called after the DOM has been updated.

Vue documentation

Sounds good right? So I might do something like this:

this.animation = true;
this.nextTick( this.calculationStart() );
this.animation = false;

Unfortunately, this still doesn’t show our animation.


The ‘why’ is hidden in this stack-overflow answer:

nextTick allows you to do something after you have changed the data and VueJS has updated the DOM based on your data change, but before the browser has rendered those changed on the page.

Normally, devs use native JavaScript function setTimeout to achieve similar behavior. But, using setTimeoutrelinquishes control over to the browser before it gives control back to you via your callback.

Prasant at stack overflow

So – VueJS has updated the DOM, but the browser hasn’t actually RENDERED those DOM-changes yet. In other words: we’re still working within the call-stack. [or within microtasks, but for our purposes: same difference].

That’s not what we want. We want the DOM to change before that long calculation starts so our user knows what’s going on.

The solution is also given by Prasant: we use setTimeout. In most cases it’s quite enough to use 0 seconds, though I’ve sometimes gone for more.

So here’s our final pseudocode:

this.animation = true ;

-> browser renders animation because nothing left on the call-stack.

this.setTimeout( function(){this.calculationStart() }, 0)

-> browser moves this.calculationStart from callback queue onto the call stack and does ‘this.calculationStart’

this.animation = false

Animation stops after calculation is done. Phew.

So what happened? setTimeout does it’s thing by putting it’s callback on the callback queue. The callback queue is only called by the browser after both the call stack and the render queue are done. So our animation (which is on the call stack) gets done, the render queue renders it, and then the browser is ready for the callback queue and calls the long-calculation.

This is what we want.

Vue Dev-tools for development in IE-11 / Windows

In order to debug IE11 (still about 40% of our users), I recently had to install vue-dev-tools, the electron-app version. Using it is a bit more involved than the chrome-extension or the firefox-addon. Also, in some of it’s setups, the electron-app can cause unwanted extra console-warnings (endless amounts), if you just want to use the chrome-extension.

So here is the setup I ended up using:

$ npm install vue-devtools --save-dev 

in main.js (or comparable):

import devtools from '@vue/devtools';
 if (process.env.NODE_ENV === 'development') {
   global.devtools = devtools;

In your console, at your project root, run vue devtools with npx:

$ npx vue-devtools

En then in de browser console of the browser you’re checking (say IE11):

$ devtools.connect()

More complicated Leave animations in VueJS

I’ve been working with Vue for a few months now and I love the ease with which you can work css animations into it. However, when it came to creating an animation with two elements leaving the dom at the same time, I was stuck. I could also not find much help inline, so once I figured out a way, I thought I’d document it.

The trick is, basically, that when you want two elements to leave the dom at the same time, there has to be a containing element as well. It will also leave the dom. Unfortunately, once it has left the dom, the child elements (the ones you’re really interested in) will be gone as well. This means no fading or moving to the side or anything. Something that isn’t there will not show up as animating – bugger.

For this reason Vue has introduced the ‘duration’ prop. Here is some basic example vue template code:
<transition name="modal-main" :duration="500" >

    <transition-group name="modal-in-out" appear >

      <div class="class1"></div>

      <div class="class2"></div>



The outside ‘transition’ tag is for the containing element. The duration of 500 means that it will stay in the DOM for 500 ms after it’s been given the signal to leave.

This gives the ‘transition-group’ the time to manage the two transitions on the two enclosed divs in there. In VueJS you need transition-group if you want to manage more than one animation at once.

To make it more complete, here are some animations you might want to use:

.modal-main-leave-active .class1 {

animation: fadeout 550ms cubic-bezier(0.605, 0.09, 0.37, 0.9);

.modal-main-leave-active .class2 {
animation: slideout 550ms cubic-bezier(0.605, 0.09, 0.37, 0.9);

@keyframes fadeout {
0% {
opacity: 1;
100% {
opacity: 0;

@keyframes slideout {
0% {
margin-left: 0%;
100% {
margin-left: 100%;

Note that while the ‘duration’ of the main transition is 500ms, the css animations are 550ms. The extra 50ms prevent a weird flickering effect at the end of the leave animation. Basically it means that the element will (for some reason) come back in the dom right after the animation stopped. By making sure that the containing element has left the DOM, I’m also making sure that the flickering doesn’t show. It’s a bit hacky, but it works.

Web Developer Certificaat van Codaisseur

Deze zomer (2017) heb ik  me verder verdiept in het programmeervak: bij Codaisseur heb ik me tot full stack developer ontwikkeld.

Voor wie het wat zegt, ik heb Ruby and Rails geleerd, RSpec, JavaScript (incl. ES6, JQuery en Ajax), Mocha, Chai, React, SQL en Redux.

Ik heb version control met Github leren gebruiken (verslavend) en heb met ontwikkeld in TDD en Scrum.

Verder lezen Web Developer Certificaat van Codaisseur

Conversie optimalisatie voor ZZP-ers – maak klanten van bezoekers

Conversie optimalisatie is de kunst om klanten te maken van de bezoekers aan je website.

Conversie = hoeveel je verdient per bezoeker

Optimalisatie = zoveel mogelijk verdienen

Als je naïef naar website traffic kijkt, dan is het goed om veel bezoekers te hebben. Maar als die bezoekers niet echt geïnteresseerd zijn in wat jij te bieden hebt, dan heb je er helemaal niets aan om honderden of zelfs duizenden bezoekers per dag te hebben. Ik weet er alles van: zulke sites heb ik.

Dat is niet erg: die websites inspireren en informeren mensen. Ze hebben geen zakelijk doel.

Andere sites hebben in het hoogseizoen honderden bezoekers per dag en leveren dan duizenden euro’s op. Kijk, daar kun je als zakenvrouw mee weg komen. Dat is brood op de plank, hypotheek betaald etc.

Voor een zzp-er is het echter van belang dat je website klanten op levert. Klanten, niet alleen mensen die opbellen om informatie en vervolgens weer verdwijnen.

Als je gaat zoeken op ‘conversie-optimalisatie’ dan vliegen de termen je om je hoofd: A/B testen, usability, web-analytics, neuromarketing…

Dit soort principes werken als je het type bedrijf hebt waar je statistieken op los kunt laten. Voor de meeste zzp-ers zijn ze volkomen irrelevant. Hier mijn factoren voor conversie-optimalisatie voor zzp-ers:

  • Je bent je verhaal
  • Je netwerk is je belangrijkste bron van klanten
  • Wees uitstekend in wat je doet
  • Laat zien wat je in huis hebt
  • Laat zien wat je niet bent

Je bent je verhaal

Of het nu gaat om 50-plussers op de arbeidsmarkt of zzp-ers: de mensen die de draai naar een baan weten te maken zijn degenen die zichzelf helder weten te presenteren.

Als jij niet weet wat je wilt, kan je netwerk je ook niet aan je volgende klus helpen.

Een goede website bouwer weet niet alleen technisch hoe zij een website opzet, maar kan ook helpen je verhaal helder te krijgen.

Je netwerk is je belangrijkste conversie-factor

Als zzp-er moet je het vooral hebben van je netwerk: Mensen die weten wat je kunt en naar je doorverwijzen. Sympathie, de gunfactor.

Je website helpt je zodat je je verhaal niet twintig keer per dag hoeft te vertellen. Dat doet je website al voor je.

Wees uitstekend in wat je doet

Er zijn een heleboel mensen heel behoorlijk in wat ze doen. In loondienst is dat goed genoeg. In loondienst gaat het er om dat je op de juiste stoel zit en het goed genoeg doet om niet ontslagen te worden.

Als zzp-er ga je van klus naar klus. Je moet jezelf elke keer weer verkopen – de meest authentieke manier om dat te doen is door precies te zijn wat je zegt dat je bent. En laat dat ook zien…

Laat zien wat je in huis hebt

Veel Nederlanders hebben de neiging – en de meeste vrouwen nog meer – om verlegen achter een bosje te gaan zitten en vervolgens te verwachten dat mensen opmerken hoe goed je het doet. Dat werkt misschien op school, maar in het echte leven moet je laten zien wat je in huis hebt.

Je website is een van de plekken om dat te doen. En ja, dit is een principe van conversie optimalisatie – laten zien van autoriteit. (*)

Laat zien wat je niet bent

Een effectieve website voor een zzp-er trekt niet alleen klanten. Een duidelijk verhaal zorgt ook dat mensen die NIET bij jou bedrijf passen afdruipen zonder je lastig te vallen.

Hoe help ik daarbij?

Een acceptabele website in elkaar zetten kunnen heel veel mensen. Misschien ben jij er wel een van.

Ik kan je helpen door je verhaal te stroomlijnen, het ontwerp bij je boodschap aan te laten sluiten en de juiste toon te zetten.


*) De Cialdini-beïnvloedingsprincipes: sociale bewijskracht (via je netwerk), autoriteit, schaarste, consistentie (je duidelijke verhaal), sympathie, wederkerigheid (jij geeft, de ander voelt zich verplicht terug te geven) en verbondenheid (een gezamenlijk doel, ‘ons’). affliate programma en nofollow links heeft vorige week geschreven over of je links naar, via het affiliate programma, moet voorzien van het nofollow attribuut.

Het antwoord dat ze geven (waar ik overigens niet achter sta) is als volgt:

Google heeft aangegeven dat het een voorstander is voor het gebruik van het nofollow attribuut voor betaalde links op een site. Zo kun je aangeven dat de link er staat omdat er voor betaald is door een adverteerder en dat de link daarom geen “stem” is voor die site. Voor jouw eigen website maakt het dus niet uit of je wel of geen no follow link maakt van je partnerlinks. Het zorgt er dus alleen voor dat ‘spamlinks’ niet mee worden geteld voor de ranking in google.

Die eerste zin klopt:

Google heeft aangegeven dat het een voorstander is voor het gebruik van het nofollow attribuut voor betaalde links op een site.

Belangrijk is te weten dat elke affiliate link in de ogen van Google een betaalde link is. En hoewel het advies van Google niet altijd al te letterlijk genomen moet worden, zou ik dat in dit geval wel aanraden.

Dus zet nofollow in je links naar het affiliate programma.

Dat gaat als volgt:

<a href=”” rel=”nofollow” >Visit My Page</a>


<a rel=”nofollow” href=”” >Visit My Page</a>

Wat gaat er mis als je dit advies van Google niet op volgt?

1) Je loopt kans dat de traffic krijgt in plaats van jijzelf.

Stel: je schrijft een recensie over het nieuwste boek van A. Grunberg. Dan wil je natuurlijk dat, mochten mensen op zoek zijn naar recensies van dat boek, jou site boven komt drijven in Google. En dan wil je dat ze doorklikken naar en het boek kopen zodat jij commissie krijgt.

Probleem: zonder nofollow in je link, is de kans groot dat hoger in de zoekmachine resultaten terecht komt dan jij. Dat was niet helemaal de bedoeling – althans voor jou. Voor is het natuurlijk fantastisch: ze hoeven jou niet te betalen en krijgen ook nog meer traffic.

2) Als google weet dat er betaalde links op je site staan, loop je groot risico dat je lager in de zoekresultaten gezet wordt, of er zelfs uit geweerd wordt.

Google heeft een groot probleem met links. Aan de ene kant zijn ze essentieel om te bepalen wat goede / belangrijke / interessante inhoud is op het web. Aan de andere kant weten webmasters dit ook en gaan ze er dus naar sturen.

Er is dus de afgelopen 10 jaar een betaalde link economie ontstaan. Links zijn geld waard.

Google straft dit aan twee kanten af. Stel: Site A linkt naar site B en krijgt daarvoor betaald.

  1. Stel, site B heeft overwegend betaalde links naar zich toe, dan kan die site lager in de zoekmachine resultaten terecht komen, of er zelfs uit verbannen worden. is overigens te groot om met dit effect te maken te krijgen.
  2. Site A heeft zowel betaalde als onbetaalde links. Dan zijn dit de mogelijke gevolgen (als Google er achter komt):
    1. De links op die site kunnen allemaal als niet tellend te boek gaan staan. Dus die ene link naar kan betekenen dat ook de links naar je vriendjes hen niet helpen om in Google te ranken.
    2. Als de kwaliteit van site A toch al niet zo hoog is, en site A zelf niet al te goede links naar zich toe heeft, dan kan die betaalde link er toe bijdragen dat site A zelf minder goed in de zoekmachines rankt, of zelfs verbannen wordt.


  • Affiliate links zijn betaalde links
  • Google is almachtig
  • Je kunt het je niet veroorloven het risico te lopen dat je site afgestraft wordt, dus kan je beter gewoon nofollow in al je links naar het affliate netwerk zetten.

Hoe maak je een goede blogpost titel?

Literaire titels voor blogposts – niet doen!

Laat ik beginnen te zeggen dat er op elke regel uitzonderingen zijn. In het geval van creatieve titels voor blogposts is de duidelijke uitzondering: creatieve blogs. Als je een gedicht online zet, is het logisch dat de titel een literaire titel is, namelijk de titel van het gedicht.

Wil je echter met je blog nieuwe lezers aantrekken, of de kans groot maken dat je abonnees de moeite nemen in hun mail door te klikken van de titel naar de inhoud van je blog, dan zul je moeten zorgen dat de titel van je stukje samenvat waar het over gaat.

De beste titels voor blogposts hebben de volgende eigenschappen: Verder lezen Hoe maak je een goede blogpost titel?

Web filters – Gepersonificeerde zoekresultaten in Google en Facebook

Voor web professionals is het geen nieuws: zoekresultaten zijn verschillend voor ieder persoon individueel. Google is al jaren verschillend afhankelijk van waar je woont. Tegenwoordig nemen ze ook mee wat voor computer je gebruikt, wat je eerder gezocht hebt enzovoorts. Dit geldt ook voor Facebook: afhankelijk van welke links je klikt filter facebook zaken uit je nieuwsfeed.

Die krijg je dus nooit meer te zien!

Dat kan behulpzaam zijn. Als je, zoals ik, zelden in facebook inlogt – en ook nog eens zo’n 400 ‘friends’ hebt, staat er nogal wat onzin op je nieuwsfeed. Ik heb me weleens af gevraagd hoe ik de berichten over huishoudelijke zorgen (I want a robomaid) uit mijn feed kon krijgen. Voor de niet-enthousiaste facebooker blijkt het voornaamste filter te zijn: hebben andere mensen er op gereageerd? Maar ik ben maar snel gaan ‘liken’ wat ik wel interessant vind, om de volgende keer dat ik kijk tenminste iets meer van dat soort werk te zien te krijgen.

Dus zo’n filter heeft zin.

Maar het beperkt ons ook. Juist omdat we niet te zien krijgen wat er uit gefilterd wordt.

Eli Pariser heeft een TED talk gegeven (zie hieronder) over die personalisatie en hij kwam er achter dat als verschillende mensen over Egypte googlen, de een van alles over vakantie daar te zien kan krijgen, en de ander vooral informatie krijgt over de problemen daar. Stel je toch voor: je gaat op vakantie naar Egypte zonder te weten dat daar net de regering omver geworpen is.

Dat is de uiterste consequentie van die beleid.

Voor de web professional is er nog een probleem: als mijn zoekresultaten laten zien dat mijn site bovenaan staat, betekent dat dan ook dat andere mensen mijn site te zien krijgen? Het antwoord is, jammer genoeg, nee. Google weet wie jij bent – zelfs als je niet ingelogd bent weten ze wie je ongeveer bent.

Om te weten wat de gemiddelde zoeker wereldwijd te zien krijgt bij het zoeken van bepaalde termen gebruik ik Scroogle. Deze site haalt alle persoonlijke filters uit Google, inclusief localisatie. Wat over blijft is Google zoals we het vroeger kenden: voor iedereen het zelfde.
Voor de Nederlandse markt moet je dan wel weer mee nemen dat het Nederlandse publiek veel vaker Nederlandstalige sites zal zien dan bij zoeken via Scroogle lijkt. Dit geldt vooral als je termen in typt die niet duidelijk Nederlands zijn.

Nu dan eindelijk de video:

Wordcamp NL 2010 – impressies

Na de zakelijke sfeer van de zanox day vorige week is de wordcamp een verademing. Ik kom binnen als de eerste bezoeker en er wordt een foto van me genomen :) Blijkbaar ben ik te vroeg. 9 uur betekent blijkbaar dat je vanaf 9 uur verwacht wordt, niet dat de eerste lezing om 9 uur begint. Het is nu kwart over en de zaal is nog helemaal leeg. [Klopt: ik had gewoon het programma moeten lezen, in plaats van het kaartje. Op het programma staat dat de actie om 9.45 begint.]

Ze hebben hun sponsors goed op orde. Van Microsoft tot Adobe – en zelfs Yoast staat op het kaartje en levert een ‘goodie’ voor de goodie bag. Dat is overigens de enige manier waarop onze beroemdste Nederlandse wordpress expert op het programma staat. Hij geeft geen lezing: zijn dochter is jarig.

In de goodie bag twee t-shirts, veel wordpress stickers en twee buttons. Op elke stoel een flesje water. Bij de opening vertelt Erno Hannink dat wie een stikker op zijn flesje heeft een boek krijgt. Leuke actie.

Dit is de tweede Wordcamp Nederland.

Vorige week voelde ik me nog net niet underdressed. Nu voel ik me nog net niet overdressed. Ik had precies dezelfde outfit aan kunnen doen als ik spreker was geweest. Aan het eind zei een van mijn gesprekspartners over een van de sprekers: in dat shirt zou mijn vader nog niet rond willen lopen… Tja. Maar zakelijk of niet, het geheel was veel gezelliger en leerzamer dan vorige week en ik kom zeker nog een keer.

Bovenstaande foto van onder getekende door Happy Hotelier, Toegevoegd aan de WordCamp NL groep op Flickr. En als je wilt weten wat die foto BOVEN de titel van dit stukje doet, dat is standaard Thesis functionaliteit, net als de thumbnails of de index pagina en de categorie pagina’s.