The Vue.js London conference returned this year albeit at a bigger and grander venue, the O2 Arena. The conference organisers had positioned the theme of this year's edition to herald the long-anticipated release of features and tools in Vue 3.0. The series of talks covered an array of current best-practice topics in the morning sessions, while Vue 3.0 features and updates (in particular the Composition API) were squarely in the spotlight after lunch.

Here are some of the highlights from Vue.js London 2019!

Vue's point of view - opinionated approaches in Vue.js projects

Vue.js London 2019 opened with a series of three talks on topics often associated with "polish and optimisation" in intermediate to advanced Vue.js projects. Vue Mastery's slick presentation work clearly communicated in Adam Jahr's talk on the UX benefits of using animations in a front-end interface to direct users' focus. Vue's built-in transition and transition-group components make creating organic and reusable CSS transitions a breeze when compared to a vanilla CSS implementation.

The contentious topic of CSS-in-JS was the second topic of the day as Maya Shavin led the audience through a Brief History of Front-end development for the web. Developers using Vue.js out-of-the-box are offered the option of encapsulating component styles with Scoped CSS. CSS Modules is another common approach (especially in the React world) to scope CSS classes locally with the added ability to compose classes. The second alternative to Scoped CSS is styled-components, presented by Shavin as the only "true" CSS-in-JS option allowing for encapsulation, extensibility and theming. However, strong caveats against styled-components were added concerning dynamically in-lined classes on runtime (without the possibility of caching), and potential security issues due to string template interpolations if users are allowed to input styles.

Filip Rakowski followed on with a practical live demo of some easy-to-do Webpack optimization drastically reducing initial-load times in production apps with the help of dynamic imports and pre-fetching.

As an interesting side note to these presentations, all the topics had previously been discussed in Factorial's front-end working group meetings.

It's all about the DOM

With data visualisation an ever useful front-end development tool-in-the-box to have, the next talk dived into the world of SVGs, interactive charts, and D3.js. Ramona Biscoveanu highlighted some key considerations to keep in mind when integrating Vue.js in D3.js based data visualisations. Firstly, although both libraries are centred around data driven DOM manipulation, the Vue.js renderer is virtual DOM based while D3.js renders SVGs by selector-based manipulation of the DOM. Vue's virtual DOM and templating layer in turn allow developers to create SVG based charts in a more intuitive and declarative manner. Secondly, Vue.js offers a first-class reactivity layer compared to D3.js (which is intrinsically not reactive). Finally, a key (if not the main) benefit of using D3.js is the rich set of visual and geospatial analytics layouts, projections and helper methods which would be impractical to write from scratch.

Getting to the route of things

As a segue into more Vue 3.0 centred topics after lunch, the morning talks concluded with an update from Eduardo San Martin Morote's update on improvements coming soon to the Vue Router. Rather than brand-new features, updates to the Router focused on addressing current shortcomings and limitations in the current version, and features aligned with Vue 3.0. Vue developers can expect: out-of-the-box TypeScript support, scoped slots for the router-link component, improved navigation failure handling, (finally) path ranking, truly dynamic routing, and support for Vue 3.0's Composition API.

The Path to Vue 3.0

The afternoon sessions kicked off with a couple of talks by Greg Pollack and Thorsten Lünborg about the new Composition API. In a similar vein to Vue Mastery's Vue 3 Cheat Sheet (also released during Vue.js London), Greg outlined the main shortcomings of current code sharing techniques, while highlighting the key benefits and reasons for adopting the new API. Thorsten complemented introduction with more concrete use cases and implications on production scale apps.

As experienced in large projects undertaken at Factorial, Vue components can quickly grow into unwieldy monoliths which are hard to reason about, and harder to maintain or even refactor. Larger apps also tend to feature recurring fragments of business logic as code which is often copy-and-pasted due to Vue's options based syntax.

A typical approach to sharing logic across components is the use of mixins, which in turn introduces the problem of naming conflicts and non-explicit traceability of methods and properties. The new Composition API enables business logic to be abstracted into reusable Composition Functions, which are as easily understood and used as utility functions. Granted that some concepts of the Composition API are completely new and non-trivial (e.g. the difference between reactive and ref and using toRef), it is a learning curve that will be overcome with experience and a worthwhile price for a cleaner codebase. And, if we haven't forgotten it already, the Composition API is 100% non-breaking and does not hinder beginners from picking up the easy-to-grasp options based Vue API we all know and love.

Composing compositions on a keyboard-keyboard

As a light-hearted and thoroughly informative and entertaining dive into the Composition API, Jason Yu's live-coding demo of Keyboard-Keyboard was certainly the highlight of the conference on sheer entertainment value. Jason's humour, confidence and approachability balanced his presentation's role of showcasing the features and benefits of Composition Functions while communicating the pure joy he finds in both creating code and music.

You has the final say

As always, Evan You concluded Vue.js London with updates on the progress of Vue 3.0. Probably in a follow up to the update given the year prior, this year's update centred around Vue's internals, with key compiler optimisations made. In keeping with the spirit of doing things "live" at conference, Evan officially open sourced the Vue 3.0 branch on GitHub in the strongest indication yet of the imminent arrival of Vue's next version.

Conclusion

The underlying theme of creating performant and polished applications with Vue.js is certainly a testament to the progress both core contributors and the wider community has made in recent months and years. As concepts in one ecosystem gain traction and acceptance as "best practices", it is my hope to be still challenged by new approaches and the cross-pollination of ideas between frameworks and communities. Finally, credit must be extended to Vue.js London organiser Blake Newman and his team for another successful edition of the conference.

First presented at Hamburg Vue.js Meetup #5

Testing Times

Quality assurance for software products and services typically spans multiple teams from project owners and managed to designers, and even dedicated QA teams. The standardised adoption of CI/CD pipelines to deliver software has allowed automated testing to become part of day-to-day DevOps. Automated software testing can generally be categorised into three groups, visually represented by the Testing Pyramid; 1. Unit Testing, 2. Integration Testing, and 3. End-to-end Testing. The layers of the pyramid visually quantify the proportion of each type of test should be covered within a software project.

Test-driven Development (TDD) is a software development process which is focused on QA and Unit Testing from the moment a developer writes their first line of code. In its "purest" form, TDD always begins with writing a unit test, and ends when the software written against the test passes the test.

What is Unit Testing anyway?

Unit Testing has a very simple definition:

Testing individual software units in isolation.

Going further, a software unit can be defined as:

The smallest, testable part of a software

In the world of Functional Programming (FP), pure functions are the undisputed units to write tests for. Consider, for example, the factorial function where each value of n always produces a corresponding term:

/** The factorial! 😂 function
  * i.e. the product of all positive integers
  * less than or equal to n
  * n!=1.2.3.4...(n−2).(n−1).n
  * n!=n.(n−1)!
  */
const factorial = n => {
  if (n === 1) {
    return 1;
  }
  return n * factorial(n - 1);
};

A Vuex store module may similarly composed of different mutation and/or getter functions:

const state = { myList: [] };

const addListItem = (
  state, listItem
) => {
  state.myList = [
      ...state.myList,
      listItem
  ];
};

const mutations = { addListItem };

export default {
  state,
  mutations,
  namespaced: true
};

Things get a little more interesting once components are added to the equation:

<template>
    <!-- Vue template markup -->
</template>

<script>
export default Vue.extend({
    // Vue component logic
    props: { /* some props */ },
    methods: { /* some methods */ }
});
</script>

<style>
// Vue component styling
</style>

But what about more complex (and typical) Vue.js components which map Vuex functionality:

<template>
    <div>
        <button @click="fetchList" />
    </div>
</template>

<script>
export default Vue.extend({
    // Vue component logic
    props: { /* some props */ },
    methods: {
        ...mapActions("list", [
            "fetchList"
        ]
    }
});
</script>

<style>
// Vue component styling
</style>

In this scenario, the last two words in the Unit Testing definition plays its crucial role; in isolation. Testing the fetchList click handler against this component would not be necessary as the actual implementation would already have been tested when the Vuex store was created.

The general rule of "do not test dependencies and dependants" can be applied when unit testing mid-to-high complexity Vue.js components:

• Avoid directly test Vuex store functions
• Avoid testing UI/CSS libraries, e.g. Vuetify, material-web-components
• Avoid testing API modules
• Avoid testing ...anything producing side-effects

Tried-and-tested

As developers, and part of a wider product development team, the benefits of adopting Unit Testing as part of the development process are wide ranging. From the perspective of a developer, a TDD approach with an emphasis on unit testing generally results in code which is more modular (complex architectures composed from units), predictable, and ultimately maintainable. Similarly, from a product lifecycle perspective, creating unit test scripts early in the sprint enables the developer to clarify any vague acceptance criteria with the product owner before implementing features.

A familiar TDD cycle may look something like this:

1. Write a failing test against the acceptance criteria (clarify if necessary)
2. Implement the feature in code
3. Run the code against the test
4. Repeat steps 2-3 until all tests scenarios for the unit pass

With vue-cli 3, setting up a new or existing Vue.js project for unit testing is a breeze with a single entered in the terminal (or graphically with the Vue CLI UI):

$ vue add @vue/unit-jest

Other automated development tooling including git pre-commit hooks and pre-build scripts for CI/CD allow developers to take their minds off when and how to run unit tests, focusing their efforts instead on delivering reliable features and enhancements.

A 5-point Approach

Moving towards a TDD-based process may seem daunting, but thinking about an approach with these general points could be beneficial:

1. Apply white-box testing

White-box testing involves isolating software units in a testing environment and testing provided input against some expected output. In contrast to black-box testing, where the implementation details of the software tested are opaque, white-box testing requires transparent knowledge of the units implementation. This becomes apparent when unit testing more complex parts of a Vue.js app, for instance an action function in a Vuex store. The presentation above visually describes the difference between white-box, black-box (E2E) and grey-box (integration) testing.

2. Validate scenarios using simple assertions

The saying "simpler is better" applies to the approach of asserting input against output. If a function is expected return an array with three strings, the following assertion is something to avoid:

expect(array).toHaveLength(3);
expect(array[0]).toBe("quick");
expect(array[1]).toBe("brown");
expect(array[2]).toBe("fox");

This assertion is direct and understandable:

expect(array).toEqual(["quick", "brown", "fox"]);

With the previous example of the factorial function, the assertion below using Jest verifies whether the function works in finding the 5th and 10th factorial expressions:

it("Should return the nth factorial", () => {
  expect(factorial(5)).toBe(120);
  expect(factorial(10)).toBe(3628800);
});

The presentation and accompanying repository provides more examples in creating assertions for Vuex mutations/getters and actions (with Jest mocks).

3. Ensure tests are run in an isolated environment (i.e. tests do not change the state of any other part of the software/system)
4. Pick the appropriate (i.e. well supported) tooling

• framework/runner/assertion library

Many frameworks provide officially supported unit testing frameworks where developers do not have to worry much about configuration. With vue-test-utils, out-of-the-box unit testing is provided with Jest serving not only as the test framework, but also the runner and assertion library.

With vue-test-utils, individual Vue components are mounted in isolation to a JSDOM environment via a wrapper based API with the shallowMount method. Unlike mount, shallowMount stubs a component's children components rather than the entire subtree.

When unit testing Vue components, deciding which areas of code should be covered by tests can be complicated:

we recommend writing tests that assert your component's public interface ...
A component's interface comprises several inputs and their corresponding outputs:

• Inputs: props, user interaction, Vuex store
• Outputs: events, rendered/updated UI, mutations, actions

A subjective but practical approach to minimise duplication when testing would be to exclude testing of any of the Vuex related features (e.g. mapActions or mapMutations) within a .vue SFC component, as coverage should have been provided when the store was implemented. These features are not directly covered directly by the component's contract.

Snapshot testing may also be a quick way of providing plenty of coverage with very few lines of test code. However, the following caveats need to be considered:

• Large snapshot files generated
• False positives/negatives
• Deterministic testing

5. Use minimal mocking

While Jest provides an excellent solution for mocking functions, modules and dependencies, relying on many mocks in a single unit signs is a likely indication of tight coupling and over-complexity of the code, and indication often described as a "code smell". In these cases, the software could likely be broken down into smaller units.

Wrapping it up!

What this presentation and article hopes to inspire is that unit testing (with Vue.js and in general) is an easy process to adopt within a development team. Start (unit) testing NOW! When coupled with sound software design principles (like SOLID), coding and testing software becomes a question of which parts of the codebase should be covered, rather than how many lines.

Beyond unit testing, the topic of integration testing still holds many unanswered questions; from experience, most bugs encountered in the wild are the result of integration related issues (e.g. changed API assumptions/requirements). However, setting up good integration tests is orders of magnitude more complex than unit testing. The last section of the presentation covers some basic aspects of integration testing within Vue.js apps (Vuex + .vue integration and Parent-Child integration).

References

• Software Testing Fundamentals
• Testing Vue.js Applications
• Vue.js Testing Workshop by Edd Yerburgh
  • Slides
  • Repo
• JavaScript Scene
  • Unit testing the RITE way
  • TDD
• Companion repo
• More complex scenarios

Websites and web applications often require embedding of some content or core business logic from third-parties. Think of videos provided by YouTube, or maps from Google Maps. For a long time, we have turned to HTML iFrame technology to implement these features. With the introduction of Web Components and the promise of "reusable and encapsulated" functionality, what then does the future hold for iFrame technology?

iFrame – Background and Use Cases

The iFrame or Inline Frame element is used to embed another HTML document into the body of the currently browsed page. This creates a nested browsing context in which useful content from third-party sites or services can be directly enclosed without much configuration. A second and related use-case for iFrames is to enable reuse of business logic already implemented in an existing web application as embedded widgets (think of real-time chat widgets).

Drawbacks of iFrame technology

There are, however, several drawbacks in using iFrames for either of the use-cases described. These include (and are not limited to):

1. The nested context created in embedded pages could result in decreased SEO credit for the host page, as search engines will attribute content to the iFrame's source URL.
2. iFrames effectively create "browser windows" within the existing page, a potential User Experience nightmare resulting in unintended nested and vertical scrollbars if not carefully configured.
3. The isolated browsing context of an iFrame means that any link within an iFrame will redirect the iFrame's location to that link, while remaining on the original host URL inside the web browser.

Despite these drawbacks, precautions can be taken to minimise and event eliminate problems faced.

The Promise of Web Components

Enter Web Components; a set of four web technologies to help developers implement customised UI controls which are strongly encapsulated (non-conflicting) and reusable (modular and composable).

1. The Custom Elements API enable custom HTML elements (named and defined with custom attributes/events) to be defined and used like any other element.
2. The Shadow DOM API allows an encapsulated DOM element which is attached to a host DOM element. CSS styles applied in the Shadow DOM will not bleed into the host document, and vice versa.
3. The HTML Templates API provides
4. The HTML Import API allows the import of Web Components from separate resource definitions.

Together, Web Components technology points towards a future of more streamlined, less repetitive (more DRY - don't repeat yourself!), and extensible web application development. Weather widgets which have to "look and feel" different across multiple sites will no longer custom development in multiple projects. Instead, a custom element could be developed once and potentially imported, configured and run on any other site.

The Future is Now

Given the lofty promise of Web Components, the reality of limited developer tools and poor browser compatibility mean that this future will not be realised soon. As developers, we can only realistically target newer, feature-ready browsers like Chrome or Firefox, and not evergreen browsers which are still part of hard requirements set by clients. Choice is also limited when it comes to libraries and frameworks to build Web Components in:

• Create "Vanilla" web components using the "(non-)standard" Web Component APIs
• Polymer: library developed by Google to build and distribute web components
• Wrapping other web app libraries by registering Vue/React/Angular components as Web Components
  • Vue-web-component-wrapper (Web Component as build target in Vue CLI)
  • Web-react-components

Hands-on @ Factorial and Conclusion

At Factorial, we combined our experience with Vue.js development in delivering two Web Components based projects. The first was a real-time chat interfacing integrated in a hybrid Drupal 7/Socket.IO setup. The second project was a reusable UI component library proof-of-concept targeted at progressive, decentralised design overhaul across a suite of existing web apps. The first-class developer experience the Vue.js ecosystem provides made creating reusable Web Components a breeze compared to "vanilla" or Polymer approaches. We hope that support for targeting Web Component builds will mature over time and across more frontend frameworks.

In conclusion, despite its shortcomings, iFrame technology looks set to stay for the foreseeable future. For the core use-case of embedding content like videos and maps, iFrame solutions are quick, dependable and well documented by providers. For more complex use-cases in building reusable and modular interfaces, Web Component technology is exciting and promising. It now requires a concerted effort from browser vendors, UI framework contributors, and us as web developers to drive Web Components forward.

This article was first published on the Factorial Blog here