CategoryJavaScript

SVG libraries worth checking

https://frappe.io/charts
http://snapsvg.io/
https://svgjs.com/docs/2.7/

VueJS Plugins: developing with HRM

I’ve never being a fan of keeping backend and frontend codebase together, though some of the well known project achieve it quiet well like Discourse.

Keeping JavaScript aside for backend solutions, as part of standalone UI elements seemed as decent solution. But when you have to develop Vue components as plugins and keep the project running – testing becomes messy.

I spent half a day trying to figure out the ways how you can use symlinks to pick local packages to work in dummy VueJS app, but no luck. Both for yarn and npm. There’ve been a long story of resolving these issues for numerous packages like here, or here.

Simple solution with mocking an App behaviour with a sprinkle of chokidar package solves this problem. Well, at least to some extend:

  • You can independently develop Vue Components as plugins
  • From the box testing
  • Once e2e and unit tests are done, you can publish and integrate these plugins in to your application.

Hot Reload for Development environment

First things first – tools being used:

  • vue: 2.9.6
  • node: v10.16.0 (LTS)
  • yarn|npm: whatever make you happy!
  • webpack-dev-server: ^3.7.2

Build instructions are split in 3 parts (base, dev, prod). I’m using webpack-merge to overwrite base with required instructions, depending on the yarn command:

//package.json part with live reload instructions
"scripts": {
     "serve": "webpack-dev-server --config ./build/webpack.dev.config.js --hot --progress -d",
     "test": "jest"
}

Going further – HRM specs, to make things run:

const merge = require('webpack-merge')
const chokidar = require('chokidar')
const HtmlWebpackPlugin = require('html-webpack-plugin')
const base = require('./webpack.base.config.js')

module.exports = merge(base, {
  entry: './dev/dev.js',
  plugins: [
      new HtmlWebpackPlugin({
        template: './dev/index.html',
        inject: true,
      }),
  ],
  optimization: {
   noEmitOnErrors: true,
  },
  mode: 'development',
  devtool: '#eval-source-map',
  devServer: {
    hot: true,
    hotOnly: true,
    open: true,
    inline: true,
    stats: {
      children: false,
      modules: false,
      chunks: false,
    },
    port: 8080,
    before (app, server) {
      chokidar.watch([
        './**/*.html',
      ]).on('all', function () {
        server.sockWrite(server.sockets, 'content-changed');
      })
    },
  }
})

Whenever we run yarn serve script, it will load a node server, and open a ./dev/index.html file template which solely has a <div id="app"></div> container.

Example of Dev structure

Now we simply add a wrapper component Dev.vue that will contain whatever we want to test:

//dev.js
import Vue from 'vue'
import Dev from './Dev.vue'

Vue.config.productionTip = false

new Vue({
  render: h => h(Dev)
}).$mount("#app")

Let’s say we have a simple Calendar.vue component we need to load when running serve script:

<template>
  <div id="app">
    <Calendar/>
  </div>
</template>
<script>
import Calendar from '@/components/Calendar.vue'

export default {
  components: {
    Calendar
  }
}
</script>

Fullcalendar.io for Vue: No more custom scripts

Few years, ago, I had to dance around fullcalendar.io library to get it working nicely in VueJS framework. Some wrappers, custom components and lots of external jQuery code to make it work.

No more of it! Now, cakephp-calendar can be re-written using fullcalendar-vue package. And it sound like a perfect weekend task:

  • Getting rid of custom event treating
  • RFC all the way with Recurrences
  • Clean State Management and stand-alone JS npm package (instead of all-in-one solution)

Congratulations to developers from fullcalendar community, who did a great job moving away to TypeScript, and making the codebase more incorporating with modern frameworks like Vue/React/Angular.

SPA reload after deploy

John Resig, founder of jQuery, recently raised a great discussion on how to handle Single Page Application reloading after deployment.

Some of the options included:

  • Pass build version with each Ajax response and reload if mismatched.
  • Send a version hash to a server and force 412 code if versions not matching.
  • Notification on version update to leave refresh up to user to decide.
  • Client version passed in HTTP header to check for updates.
  • Log out all the clients at midnight
  • Turning on the servers only from 9 till 5.

Dashboards with GraphQL & ElasticSearch

Here’s an example of creating Dashboards with GraphQL and ElasticSearch from React community.

As a big fan of VueJS framework, it’s still nice to check what’s happening on the other side of the fence from React community fellow coders. 

Mitch Clay published an article on how you can utilise GraphQL with ElasticSearch to design dashboards for the your projects.

The stack is pretty common for JS environment:

  1. NodeJS
  2. React
  3. GraphQL with Apollo

But, the only bit I missed using – ElasticSearch engine, as more and more projects use it – it seems that I need to give it another look.