Harry Potter and the JavaScript Fatigue — Part 1
At the time of writing, it is about two years after everyone was talking about javascript fatigue. And yes, back then my team was no exception. We fatigued by the ever growing complexity in the React.JS ecosystem and had to learn our lessons the hard way. But today things look much brighter. Best practices spread fast and everyone seems to test their code now. But if you do not live in a javascript bubble, it is still very hard to get things right. Especially, if your team needs a frontend that is well tested, scalable and maintainable even if design decisions and opinions change.
This text cannot achieve all that. But it can present recipes for building and testing a Vue.JS frontend. With a focus on modern state handling, side-effecting and testing. And at the very least, it can be Harry Potter fan-fiction!
Part 1: The Philosophers UI
You are in the first year of Hogwarts. Being raised by geeky muggles, you have the great idea to write an app to track all your magical homework. You call it TodoMVC (the M stands for magical)! Over the course of the next few days you try out a lot of UI frontends. Finally you find that Vue.js is the winner being the only UI frontend magical enough to run on campus.
Setup
So you install the Vue.JS cli and use it to create a webpack + vue.js project
mkdir todomvc
cd todomvc
vue init webpack frontend
? Project name frontend
? Project description Todo MVC magical edition
? Author <Name> <Mail>
? Vue build runtime (the runtime-only option)
? Install vue-router? No
? Use ESLint to lint your code? No
? Setup unit tests Yes
? Pick a test runner jest
? Setup e2e tests with Nightwatch? No
? Should we runnpm installfor you after the project has been created? (recommended) yarn
You can pull the App from here! If you do so, run git checkout part1 for this part.
In your project folder you run yarn install to pull some dependencies. And yarn dev to start a hot-loading web server for development. In another console you start jest --watch for your interactive testing console.
The first component
At Hogwarts you learned that you can start with a definition and things pop into existence. All by themselves and the means of magic! So you start with your app by writing a single unit test that defines what you want.
This test first imports the component under test and a model of a task. Both do not exist yet and to your surprise the test did not bring them into existence out of thin air. But you have a pretty good idea now on how they should look like. The item should take as props a task object that contains a title property and it should render it.
Now that you specified everything you need to write the missing parts. And with everything you already know you can create the model
and the component
The test worked like a charm.
From one to many
For a list of tasks you end up with the following test
This time you could even verify that the list correctly fills its sub-components. Shallow rendering from the vue-test-utils is very helpful for exactly this purpose. The component gets rendered to html but not its sub-components. This keeps the snapshot tests more succinct, while you can still find the components and check their props.
This is a Todo List you could end up with.
The v-for directive iterates over a collection of things. Here you iterate overtasks and use the:task="task" expression to bind the current task to a prop named task.
Being in style
The todo list still looks somewhat ugly. So you install bootstrap yarn add bootstrap-vue bootstrap@4.0.0-beta.2 and include it in the main.ts
Now the bootstrap markup is available everywhere.
You are happy with your app now. It renders your tasks and does not give instant eye cancer to every passerby!
The next thing is to build mechanisms to also change the Todolist. Because applying the proper spells every time you have a new task is tedious. And some of the spells in data manipulation magic are still way too hard for a freshman.
