Forem: Rik Browning

Do you need Vuex?

Rik Browning — Wed, 01 Apr 2020 23:43:36 +0000

With the upcoming release of Vue 3 and its much anticipated composition API, I took some time to read up on it ahead of time. I recommend reading Composition API RFC it covers everything about the API. Vue allowing us direct access to it's reactivity is very useful. One use for this could be to get rid of Vuex 😁

What's wrong with Vuex?

OK time for some random dude on the internet's opinion. Vuex is great for sharing state between components when the normal method for sharing data via props becomes cumbersome. But more often than not Vuex becomes a dumping ground for all data related to an applications state or data which doesn't need to be reactive. I don't think this would be so bad if there wasn't so much overhead for access/modifying data. Create a mutation, don't forget the getter! Oh wait that's async! Create an action to call the mutation 😅.

Probably the final nail on the coffin for me is around Typescript. I have yet to find a nice solution to interacting with Vuex, especially given it's reliance on strings for mutation and action names.

Vuex Example

Let's start with a simple example of a Vuex store.

import { Article } from "../models";
import { ActionContext } from "vuex";
import api from "../api";
import Vue from "vue";
interface ArticleState {
  articles: Article[];
}
const articleModule = {
  namespaced: true,
  state: {
    articles: []
  },
  mutations: {
    setArticles(state: ArticleState, arr: Article[]) {
      state.articles = arr;
    },
    updateArticle(state: ArticleState, a: Article) {
      const index = state.articles.findIndex(v => v.id === a.id);
      if (index > -1) {
        Vue.set(state.articles, index, a);
      }
    }
  },
  actions: {
    loadArticles(context: ActionContext<ArticleState, unknown>) {
      api.load().then(res => context.commit("setArticles", res));
    },
    like(context: ActionContext<ArticleState, unknown>, a: Article) {
      api.like(a).then(res => context.commit("updateArticle", res));
    }
  },
  getters: {
    articles(state: ArticleState) {
      return state.articles;
    },
    totalLikes(state: ArticleState) {
      return state.articles.reduce((p, c) => p + c.likes, 0);
    }
  }
};
export default articleModule;

That's a lot of code for exposing articles, totalLikes and providing a mechanism to loadArticles and like a given article. Also has magic strings in there for committing the mutations, which I know could be extracted out to constants but yet again that's more code for a relatively simple module.

Composition API

I wanted to try and recreate this store like functionality using the new Vue composition API. Here is what I have come up with:

import { ref, computed } from "@vue/composition-api";
import { Article } from "../models";
import api from "../api";

const _articles = ref([] as Article[]);

const loadArticles = () =>
  api.load().then(articles => {
    _articles.value = articles;
  });

const like = (incoming: Article) =>
  api.like(incoming).then(res => {
    const index = _articles.value.findIndex(a => a.id === res.id);
    _articles.value.splice(index, 1, res);
  });

export default {
  articles: computed(() => _articles.value),
  totalLikes: computed(() => _articles.value.reduce((p, c) => p + c.likes, 0)),
  loadArticles,
  like
};

Here I expose methods to act upon hidden reactive data. I then expose this reactive data via computed functions so that they are readonly. NOTE: The documentation for the API states there should be a readonly but I was unable to find a way to import it. Computed offers a similar readonly functionality.

Benefits

Here are some of the benefits I see:

I may be biased (read I am) but I find the composition API version a lot nicer to read and follow.
There is no magic strings I have to worry about.
Typing is obvious and less complex than having to worry about typing the overall state.
There are no scenarios where you have to use the Vue.set.
There is no pollution of the Vue prototype. This is particularly important as it means it is easier to track where this solution is being used and that we can easily tree shake/code split our solution with out having to dynamically register anything.

Pinch of salt

I have not seen the next version of Vuex that utilizes the latest composition API functionality so it may well address some of the short comings I see with it currently. With that being said, I am still not sure I will use it given I can achieve the same results with the standard composition API.

I would love to know your thoughts on using Vuex when Vue 3 is released?

Vue Composition API Components

Rik Browning — Wed, 01 Apr 2020 20:34:58 +0000

Component with Props

import { defineComponent } from "@vue/composition-api";
import { Article } from "../models";

export default defineComponent<{ article: Article }>({
  props: {
    article: Object
  },
  ...
});

Component that emits an event

import { defineComponent } from "@vue/composition-api";

export default defineComponent({
  setup(props, ctx) {
    const onClick = () => ctx.emit("like");
    return { onClick };
  }
});

Javscript Async Reduce

Rik Browning — Tue, 21 Jan 2020 02:53:00 +0000

Array.reduce is a pretty powerful function but I wanted to share a technique that I have found useful, serial execution of async functions.

const asyncs = [asyncFn, asyncFn1, asyncFn2, ...];

//Simple execution with no results
await asyncs.reduce((promise, asyncFn) => promise.then(asyncFn),
  Promise.resolve());

//Save results to an array
const asyncResults = await asyncs.reduce((promise, asyncFn) => 
  promise.then(results =>
    asyncFn()
      .then(newResult => [...results, newResult])), 
  Promise.resolve([]));

Hope you found this helpful. If you got any other reduce use cases please let me know by leaving a comment.

3 Simple JavaScript Changes

Rik Browning — Tue, 14 Jan 2020 00:56:43 +0000

I am going to show you 3 simple JavaScript changes that I think will improve your code.

1. Pure Functions

What do I mean by this? Well not quite the strict pure function definition but what I like to aim for is; a function that takes in arguments and returns a value. Ideally there should be no side effects from a pure function but sometimes that is easier said than done.

///trivial example
function add(a,b){
  return a+b;
}

This example is pretty straight for. Take in two values and return a value, really simple.

//Don't do this
function badProcessPerson(person){
  person.fullName = `${person.firstName} ${person.lastName}`;
  person.shoeSize = person.showSize || 7;
}

This is a common issue and one immutability also aims to solve but that is a topic for another day. By passing in a reference type any changes made to the object will be reflected outside of the function. However if we explicitly return the modified object the consumer of the function will be certain they have the necessary changes.

//Do this
function goodProcessPerson(person){
  person.fullName = `${person.firstName} ${person.lastName}`;
  person.shoeSize = person.showSize || 7;
  return person
}

//but ideally this
function goodProcessPerson(person){
  return {
    ...person,
    fullName: `${person.firstName} ${person.lastName}`,
    shoeSize:person.showSize || 7
  }
}

Multiple returns?

If you need to return multiple values consider using an object to encapsulate the values. With object de-structuring, consuming the results has gotten even easier.

const {total, avg} = getTotalAndAverage(scores);

2. Parameter Order

When creating functions I always try and make the data that is being acted upon the last argument.

// Don't do this
function setAge(user, age){....

// Do this
function setAge(age,user){

This practice really lends itself to some examples below...

3. Currying

Currying allows us to partially apply a function, only executing once all the arguments have been received. Whilst there are many frameworks out there with currying functionality you can also achieve similar results with this little gem:

const setAge = (age) => (user) => {....

setAge(24)(currentUser);

HOORAY for arrow functions!!

Now let me clear this is NOT true currying but it allows us to quickly create a function that we can partially apply.

Tying them together

Array Functions

Array functions are great but take a look at the following example:

const users = [...];
const olderThan = (user,age) => user.age > age;
const over18 = users.filter(x => olderThan(x, 18));

Whilst this code is fine by reordering the parameters and currying the function it becomes a lot more readable.

const users = [...];
const olderThan = age => user => user.age > age;
const over18 = users.filter(olderThan(18));

Promises

Just like Array functions benefited from curried, pure functions with nicely ordered parameters, Promises can as well. Let's take the function from the previous code and build upon it.

const olderThan = age => user => user.age > age;
const filterUsers = filterFn => users => users.filter(filterFn);
const over18 = getUsers().then(filterUsers(olderThan(18)));

Conclusions

These changes aren't ground breaking but I do think they have a few important benefits. Pure functions are super easy to test and always returning a value can help alleviate accidentally updating reference type. Combine that with currying and good parameter order and you end up with functions that produce easier to read code when interacting with Arrays and Promises.

What's a simple code change you think makes a big impact on a code base?