DEV Community: Andy G

Rewriting a Vue 2.x component with Vue Composition API

Andy G — Sun, 29 Dec 2019 11:19:07 +0000

Vue 3 will come with an additional advanced API called "Composition", which will be "a set of additive, function-based APIs that allow flexible composition of component logic."

To experiment with it and provide feedback, we can already use with Vue 2.x the @vue/composition-api plugin.

Below is a walk-through of moving from using the "standard" Vue API to the Composition API.

The component I'm going to rewrite is the following:

<template>
  <div class="hello">
    <h1>{{ msg }}</h1>
    <label>Enter your name: </label>
    <input type="text" v-model="name" /><br>
    <label>Set your age: </label>
    <button type="button" @click="decreaseAge"> - </button>
    <span> {{age}} </span>
    <button type="button" @click="increaseAge"> + </button>
    <p><small>You made {{changes}} changes to your info</small></p>
  </div>
</template>

<script>
export default {
  name: 'HelloWorld',
  props: {
    msg: String,
    value: String,
    autoFocus: Boolean,
    select: Boolean,
  },
  data() {
    const info = this.splitInfo(this.value);
    return {
      ...info,
      changes: 0,
    };
  },
  computed: {
    personInfo() {
      return `${this.normalizeName(this.name)}-${this.age}`;
    },
  },
  watch: {
    value(outsideValue) {
      Object.assign(this, this.splitInfo(outsideValue));
    },
    personInfo() {
      this.changes += 1;
      this.$emit('input', this.personInfo);
    },
    autoFocus() {
      this.setFocus();
    },
    select() {
      this.setSelect();
    },
  },
  mounted() {
    this.setFocus();
    this.setSelect();
  },
  methods: {
    setFocus() {
      if (this.autoFocus) {
        this.$el.querySelector('input').focus();
      }
    },
    setSelect() {
      if (this.select) {
        this.$el.querySelector('input').select();
      }
    },
    normalizeName(name) {
      return name.toUpperCase();
    },
    increaseAge() {
      this.age += 1;
    },
    decreaseAge() {
      this.age -= 1;
    },
    splitInfo(info) {
      const [name, age] = info.split('-');
      return { name, age: parseInt(age, 10) };
    },
    setChanges() {
      this.changes += 1;
    },
  },
};
</script>

It's a "hello world" of the Vue components, accepting a v-model and a few other props. It emits an input event, changing the v-model.

Installation and setup

Install composition api:

$ npm i @vue/composition-api --save

In your main.js add the following two lines:

import VueCompositionApi from '@vue/composition-api';
Vue.use(VueCompositionApi);

Start with an empty setup

Add an empty setup function to the component. It is called before the beforeCreate hook and does not have access to component instance (this), but the properties returned from it will be exposed in the instance.
This function will be called with two parameters: props and context. The former being pretty self explanatory, while the latter being an object which exposes a selective list of properties that were previously exposed on this in 2.x APIs, among which the most important are: parent, refs, attrs, emit, slots.

Move data to reactive/refs

The model that is defined in data can now be defined with one of the functions reactive or ref, depending on the use case. The first takes an object and returns a reactive proxy of it while the second takes a value and returns a reactive mutable object with a single value property.

Moving the changes from data to setup:

import { ref } from '@vue/composition-api';

export default {
  setup() {
    const changes = ref(0);
    return {
      changes,
    };
  },
};

For the other two properties name and age, which are extracted from the value prop, you need to take into consideration that we have no access to this in setup, hence value needs to be taken from props parameter and splitInfo can to be defined outside the component info since it doesn't use the instance anyway.

import { ref, reactive, toRefs } from '@vue/composition-api';

const splitInfo = (info) => {
  const [name, age] = info.split('-');
  return { name, age: parseInt(age, 10) };
};

export default {
  setup(props) {
    // reactive properties
    const changes = ref(0);
    const info = reactive(splitInfo(props.value));
    // return the state with the reactive properties & methods
    // each property must be a ref
    return {
      // return properties
      // changes is a ref, can be returned as such
      changes,
      // to convert a reactive object to a plain object with refs, use toRefs
      ...toRefs(info),
    };
  },
}

Move the computed properties

import { ref, reactive, toRefs, computed } from '@vue/composition-api';

export default {
  setup(props) {
    // reactive properties
    const changes = ref(0);
    const info = reactive(splitInfo(props.value));

    // computed properties
    const personInfo = computed(() => `${normalizeName(info.name)}-${info.age}`);

    // return the state with the reactive properties & methods
    // each property must be a ref
    return {
      // return properties
      // changes is a ref, can be returned as such
      changes,
      // to convert a reactive object to a plain object with refs, use toRefs
      ...toRefs(info),
      // return computed properties
      personInfo,
    };
  },
}

Move the methods

Declare those that don't use the instance outside of the component declaration

const normalizeName = name => name.toUpperCase();

Declare those that use the state inside the setup

In order to have access to the reactive properties, methods that use them, need to be defined in the same scope.

  setup(props) {
    // reactive properties
    // ...
    // computed properties
    // ...
    // methods
    const increaseAge = () => {
      info.age += 1;
    };
    const decreaseAge = () => {
      info.age -= 1;
    };
    const setChanges = () => {
      // refs need to be accessed with the value property
      changes.value += 1;
    };
    // return the state with the reactive properties & methods
    // each property must be a ref
    return {
      // return properties
      // ...
      // return computed properties
      // ...
      // return methods
      increaseAge,
      decreaseAge,
      setChanges,
    };
  },

`this.$el` needs to be handled differently

Again, having no instance, we don't have this.$el, but we do have refs on the context object passed to setup. Hence we can add a ref attribute to the root node of the component and use that

<template>
  <div ref="el" />
</template>

<script>
export default {
  setup(props, context) {
    // reactive properties
    // ...
    // computed properties
    // ...
    // methods
    // ...
    const setFocus = () => {
      if (props.autoFocus) {
        context.refs.el.querySelector('input').focus();
      }
    };
    const setSelect = () => {
      if (props.select) {
        context.refs.el.querySelector('input').select();
      }
    };

  },
};
</script>

Move the watch functions

import { 
  ref, reactive, toRefs, computed, watch, onMounted,
} from '@vue/composition-api';

export default {
  setup(props, context) {
    // reactive properties
    // ...
    // computed properties
    // ...
    // methods
    // ...
    // define watches
    // props, refs and reactive objects can be watched for changes
    // can watch a getter function
    watch(() => props.autoFocus, setFocus);
    watch(() => props.select, setSelect);
    // optionally, can have be lazy (won't run on component initialize)
    // defaults to false, contrary to how watches work in Vue 2
    watch(() => props.value, (outsideValue) => {
      Object.assign(info, splitInfo(outsideValue));
    }, { lazy: true });
    // watch a specific ref (computed)
    watch(personInfo, () => {
      setChanges();
      context.emit('input', personInfo.value);
    });
  },
};

Define lifecycle hooks

In this case, mounted becomes onMounted which is called in the setup.

import { 
  ref, reactive, toRefs, computed, watch, onMounted,
} from '@vue/composition-api';

export default {
  setup(props, context) {
    // ...
    // lifecycle hooks
    onMounted(() => {
      setFocus();
      setSelect();
    });
    // ...
  },
};

References:
Vue Composition API RFC
VueMastery Vue 3 Cheat sheet
GitHub Repo

Reduce Promises memory usage in Node.js

Andy G — Sun, 23 Jun 2019 20:59:44 +0000

I recently had to fix a Node.js lambda function that was abruptly stopped by AWS before it completed processing, reaching the maximum memory given to the function. On a bare metal server you can add one more RAM module and hope for the best. In a serverless environment there are limitations. In AWS in particular, the most you can give to a lambda function is 3,008 MB. Quite enough you would think... And you would be wrong, as we were.

This function was not particular complicated. It had to parse a CSV and for each record do a bunch of things: validate, read something from DynamoDB then do one or two writes per record, depending on some data.

The complicated thing was that it had to wait until all rows were processed and return a result: when the overall process completed and how many of the rows were processed successfully, how many gave an error and which error (validation).

The even more complicated thing was that at some point someone wanted to process a 70k records file. The 3,000 MB was not enough for this it seems.

Proposed solutions

1. Don't do serverless

Of course, the first thing we thought was to just move this outside of lambda. In AWS this could be done with ECS (Elastic Container Service). Could work, but it would add yet one more service to maintain and know about.

2. Split the CSV

Possible, but error prone. How few is too few and how do we ensure this is done? The CSVs were uploaded by a third party. Most synchronized nightly. Probably automated. Ugly.

3. Try to improve the code

Probably time consuming, but easily the solution that scales best if it proves to have effect.

Implementing solution #3

The code was pretty outdated, built on Node v6, with the well known callback hell, a bit managed with the famous async library.

Step 0: Refactor

Tasks:

use a newer version of node
rethink the logic

Up until recently AWS supported 6 and 8.10, so we went with 8, which brings support for Promises and native async/await to get rid of some of that callback hell.

The initial implementation had a pretty major issue: each record was processed individually, although it contained some data that was duplicate with other records. So there were duplicate reads from DynamoDB. A lot of them.

A better solution was to group the records by the common criteria and then process the groups in parallel and for each group all the records in parallel. Promise and async/await FTW! The resulting code was way smaller, easier to understand, did ~90% less reads from the DB and ... still reached the memory limit.

Here I have the result from a demo repo I set up to test this (processsing 100 groups with 1000 records each):

$ node index.js
Memory used before processing all records: 9.17 MB
Memory used after processing all records: 92.79 MB
Process time: 3352.570ms

Step 1

After digging up what could eat up all the juicy RAM, it turns out that Promise is not that particularly memory friendly. Bluebird was suggested, so let's try it.

Changes required:

$ npm i bluebird

const Promise = require('bluebird');

Easy fix. Memory dropped. By ~30%. But the function still timed out for the big files. Not good.

Here's the test output:

$ node index.js
Memory used before processing all records: 9.3 MB
Memory used after processing all records: 67.32 MB
Process time: 3169.421ms

Step 2

It turns out that waiting for all the promises to continue means that we have all those promises stored in memory. Go figure...
So we need to reduce the number of requests we do in parallel. Bluebird to the rescue again, with Promise.map. Using the concurency option of this function we can set how many concurrent items should be processed at a given time.

And the final test output:

$ node index.js
Memory used before processing all records: 9.29 MB
Memory used after processing all records: 17.34 MB
Process time: 30132.855ms

What's even better is that with this approach the memory peak is stable. It does not increase with the number of items there are to process, because after each batch of records is processed, the GC kicks in.
Granted, this did increase the total time it takes to process the entire set, but for this particular scenario we're only interested in not consuming all the memory.

The real world code uses ~400 MB of memory and processes 10k records in about 30 seconds. We deemed that acceptable.

Check the commits in this GitHub repository to follow the above steps:

andyghiuta / promise-performance

Promise performance improvements in Node.js (v8.10.0)

The script tries to emulate processing a matrix of records. EG:

const records = [[1, 2], [3, 4]];

To know when all records are processed, we need to know when each row has been processed and when all rows have been processed.

Improvements

Step 0 (no improvements)

The idea is to handle each record with a promise and for each row, await Promise.all the rows, returning only after all records in row have processed. Then for the entire set, await Promise.all the promises returned for the rows.

Observation

Memory usage is high. Script uses ~99.8MB and does not free up memory after each row has processed. Quite interesting...

Step 1

Looks like Bluebird could help: nodejs/node#6673

Changes required:

$ npm i bluebird

const Promise = require('bluebird');

Observation

Memory usage dropped…

View on GitHub

DEV Community: Andy G

Rewriting a Vue 2.x component with Vue Composition API

Installation and setup

Start with an empty setup

Move data to reactive/refs

Move the computed properties

Move the methods

Declare those that don't use the instance outside of the component declaration

Declare those that use the state inside the setup

this.$el needs to be handled differently

Move the watch functions

Define lifecycle hooks

Reduce Promises memory usage in Node.js

Proposed solutions

1. Don't do serverless

2. Split the CSV

3. Try to improve the code

Implementing solution #3

Step 0: Refactor

Step 1

Step 2

andyghiuta / promise-performance

Promise performance improvements in Node.js (v8.10.0)

Improvements

Step 0 (no improvements)

Observation

Step 1

Observation

`this.$el` needs to be handled differently