DEV Community: Attila Szeremi⚡

Vue Multiple Logic Topics, but with the Object API

Attila Szeremi⚡ — Sat, 22 Jun 2019 13:10:11 +0000

There's been a bit of debate recently about the upcoming VueJS 3 Function API. It brings about several benefits, like being able to to make sharing code behavior easier for library authors, and better TypeScript support.

There are various downsides of implementing this of course, out of which added complexity, and inelegant syntax according to some.

I don't want to talk about all the upsides and downsides of this new Function API though.

I only want to talk about one supposed upside that Function API would bring, but that I claim to be completely achievable simply using the Object API available in VueJS 2:

Multiple Logic Topics

According to the Function API doc, though its example is simplified, it brings up the fact that large VueJS components in large projects can have multiple topics (i.e. domains) of logic happening, but that it's hard to tell which properties defined in data, methods, computed etc. belong to which topic.

Here is the example of mixing topics about both mouse movement tracking and data fetching in VueJS 2. Note that the example is simplified; it's potentially a bigger issue in larger code.

<template>
  <div>
    <template v-if="isLoading">Loading...</template>
    <template v-else>
      <h3>{{ post.title }}</h3>
      <p>{{ post.body }}</p>
    </template>
    <div>Mouse is at {{ x }}, {{ y }}</div>
  </div>
</template>

import { fetchPost } from './api'

export default {
  props: {
    id: Number
  },
  data() {
    return {
      isLoading: true,
      post: null,
      x: 0,
      y: 0
    }
  },
  mounted() {
    this.fetchPost()
    window.addEventListener('mousemove', this.updateMouse)
  },
  watch: {
    id: 'fetchPost'
  },
  destroyed() {
    window.removeEventListener('mousemove', this.updateMouse)
  },
  methods: {
    async fetchPost() {
      this.isLoading = true
      this.post = await fetchPost(this.id)
      this.isLoading = false
    },
    updateMouse(e) {
      this.x = e.pageX
      this.y = e.pageY
    }
  }
}

Here is the VueJS 3 proposed cleaner separation of topics with the help of the Function API:

import { fetchPost, value, watch, onMounted, onUnmounted } from './api'

function useFetch(props) {
  const isLoading = value(true)
  const post = value(null)

  watch(() => props.id, async (id) => {
    isLoading.value = true
    post.value = await fetchPost(id)
    isLoading.value = false
  })

  return {
    isLoading,
    post
  }
}

function useMouse() {
  const x = value(0)
  const y = value(0)
  const update = e => {
    x.value = e.pageX
    y.value = e.pageY
  }
  onMounted(() => {
    window.addEventListener('mousemove', update)
  })
  onUnmounted(() => {
    window.removeEventListener('mousemove', update)
  })
  return { x, y }
}

export default {
  setup(props) {
    return {
      ...useFetch(props),
      ...useMouse()
    }
  }
}

Indeed one can argue that the Function API is great for giving you an opportunity to group logic belonging to the same topic together and package it under reusable functions.

However, it's completely possible to effectively do the same thing with VueJS 2's old-fashioned Object API. It would involve writing the topic code to variables before your VueJS component object definition:

import { fetchPost } from "./api"

const fetchData = {
  data: {
    isLoading: true,
    post: null
  },
  mounted() {
    this.fetchPost()
  },
  watch: {
    id: "fetchPost"
  },
  methods: {
    async fetchPost() {
      this.isLoading = true
      this.post = await fetchPost(this.id)
      this.isLoading = false
    }
  }
}
const mouseData = {
  data: {
    x: 0,
    y: 0
  },
  mounted() {
    window.addEventListener("mousemove", this.updateMouse)
  },
  destroyed() {
    window.removeEventListener("mousemove", this.updateMouse)
  },
  methods: {
    updateMouse(e) {
      this.x = e.pageX
      this.y = e.pageY
    }
  }
}
export default {
  props: {
    id: Number
  },
  data() {
    return {
      ...fetchData.data,
      ...mouseData.data
    }
  },
  mounted() {
    fetchData.mounted.call(this)
    mouseData.mounted.call(this)
  },
  watch: {
    ...fetchData.watch
  },
  destroyed() {
    mouseData.destroyed.call(this)
  },
  methods: {
    ...fetchData.methods,
    ...mouseData.methods
  }
}

As you can see, the topics have been separated into fetchData and mouseData. Then we explicitly do object spreading in each property of the Object API for each topic that has it.

The object spreading may seem strange at first, but if you think about it, it's used commonly in Vuex's mapXXX() functions.

But there is a bit of code repetition here. And one may forget to spread on something from one of the topic's properties, or include calling the lifetime methods, or forget to bind this. I wonder if there's a way we could simplify this code and remove a lot of boilerplate...

import { fetchPost } from "./api"

const fetchData = {
  data: {
    isLoading: true,
    post: null
  },
  mounted() {
    this.fetchPost()
  },
  watch: {
    id: "fetchPost"
  },
  methods: {
    async fetchPost() {
      this.isLoading = true
      this.post = await fetchPost(this.id)
      this.isLoading = false
    }
  }
}
const mouseData = {
  data: {
    x: 0,
    y: 0
  },
  mounted() {
    window.addEventListener("mousemove", this.updateMouse)
  },
  destroyed() {
    window.removeEventListener("mousemove", this.updateMouse)
  },
  methods: {
    updateMouse(e) {
      this.x = e.pageX
      this.y = e.pageY
    }
  }
}
export default {
  props: {
    id: Number
  },
  mixins: [fetchData, mouseData]
}

Surprise surprise, this is precisely what mixins do :D.

In case you haven't thought of this before, you can define mixins and use them in the same file too. In which case the common argument is not so strong anymore against mixins about property clashing, and that you don't know which file the properties come from. But one could argue that this code both separates topics well and is pretty clean an simple too.

Closing thoughts

With this of course you can't share behavior between "topics" equally well as you could with the Function API (think useEffect() with React Hooks), probably. Also there are other benefits to the Function API as well.

The real purpose of my article was solely to demonstrate that the one argument about the new Function API bringing about the ability to separate topics is false, because you can do the same with the existing Object API.

Sharing .dotfiles cross-platform with a shell script

Attila Szeremi⚡ — Tue, 29 May 2018 23:56:37 +0000

Throughout my career I have been in many Linux environments. I had the one at my first workplace where I would have my own .vimfiles settings set. Then at home when I installed Ubuntu for the first time, I would have a .bashrc file for storing some aliases. Then on my Windows on my Linux-like cygwin environment I had to copy that same .bashrc over, and maybe I created a .screenrc to configure GNU screen. Then on my personal DigitalOcean server I had another Linux environment, and I had to copy my configuration again. Then I installed Linux on a new computer and needed to find and copy my aliases again... and so on and so on.

I have probably had to manually copy parts of local Linux configuration over and over again twenty times or so before I realized that this just has to be automated in some way so that I wouldn't have to suffer so much getting all my configuration ready any time I have to deal with a new Linux environment. In this article, I'm going to show you what I did to solve this problem of mine.

Why do I opt for shell scripts in the title? That's so to minimize the amount of dependencies needed to be installed in order to get my .dotfiles up and running on any server.

Versioning dotfiles with Git

First of all, what best way to save the state of several files (.bashrc, .gitignore_global, bin/) for keeping them in sync than by using version control?

There is a thing one might think as issues when considering to version files in your home directory...

The dotfiles you would like to version is a very small subset of files/directories in your home directory

That's true. If you started versioning your home directory, all the other unrelated files/directories would show up as unversioned, muddying up your git status output all the time.

To solve this, I just created a .gitignore file in my home directory with this in it: *. Basically to ignore everything.

It's not a problem at all. Whenever I want to add new file, I can just do git add -f <file> to bypass the ignores.

Cloning .dotfiles in new environments

Now that we have our dotfiles versioned in Git, we'll need to be able to clone it into new environments to make use of them.

On any new Linux environment ideally we would like to clone our dotfiles into our home directory. Unfortunately in every Linux environment your home directory is not empty, and Git doesn't give you a way to clone into an existing directory.

So we'll need to clone into a new directory. We could call it dotfiles, and it could be within our home directory.

Now after that we would need to copy the files over from within the dotfiles directory to the home directory. There are some issues with that again though that would be good to address:

It's usually non-trivial for non-Linux-gurus recursively copy files from within a directory including files starting with a dot (most dotfiles we would like to version)
Our new Linux environment might come with some .bashrc file already there that we might not want to just blindly override it with ours. Maybe this was actually an older Linux environment of ours which has an old .bashrc of ours with some interesting stuff in it.
Besides, worrying about all this also just wastes time. It would be good to get all our dotfiles ready ASAP on any Linux environment such that it would never feel like a chore.

Why not automate all this then?

Using an installer as a bash script

I'm not a big fan of bash scripts, but their portability is pretty good, so I opted for making one of those.

Where would the bash script go? Well it would be versioned within our dotfiles of course. I myself put it in bin/install_dotfiles.sh.

The answer to the problem of how to include files starting with a dot when copying files from * is by setting:

shopt -s dotglob

You now know what you need... but you might forget it. So just leave this in your bash script so you wouldn't have to remember!

The other thing is what to do to avoid overriding your existing files.

If you didn't know, there's an argument you can pass to cp which keeps numbered backups for any files that would be overridden by a copy. It's --backup=numbered.

So the initial install script would copy all the files over with backups including the .git folder and .gitignore file to make sure your home folder is versioned but ignores all files.

The bash script would basically contain:

#!/bin/bash
shopt -s dotglob
cd ~/dotfiles
cp -rv --backup=numbered * ~

And that's it, we have a portable way to sync dotfiles across Linux environments with a simple initial installer bash script you would have to run only once per new environment.

Addition for Macs

Unfortunately one more dependency is needed for this to work on a Mac.

To make cp on macOS work the same way as in Linux (for --backup=numbered), you'll need to make sure to install coreutils (e.g. with brew install coreutils), then make sure the GNU cp command is used by using this code after setopt:

# Wrapper for cp to work in macOS.
cp() {
    if [ -x "$(command -v gcp)" ]; then
        command=gcp
    else
        command=cp
    fi
    command $command "$@"
}

Last extension: dist files

You might have some local configuration files you wouldn't want to version, but would like to have a default "dist" version to be installed initially on new Linux environments. For that, you could have a folder called, say, .dotfiles.dist with all such files. Then at the end of your script file after copying the files, you could then do:

cp -rv --backup=numbered .dotfiles.dist/* ~

In case you're interested, you can see my dotfiles installer script here.