Wednesday, September 19, 2018

POI 10, tests and coverage

The problem

You're using POI 10 with @poi/plugin-karma and want to get coverage of your unit tests. The way to do it is to specify:

  plugins: [
    require('@poi/plugin-karma')({
      coverage: true,
    })
  ]

and theoretically you should be all set. Only that it won't work:

TypeError: Cannot read property 'preLoaders' of undefined

I've looked everywhere and it seems that it is, unfortunately, not a known problem. What is even worse the GitHub repo with POI sources, version 10, is GONE! I mean I understand everything but removing history of an opensource project - that is a bit too much for me. SHAME ON YOU, EGOIST!

The solution

The problem is that @poi/plugin-karma taps directly to options of the vue-loader whist seems to be undefined at that point. The quick and dirty solution is to add those options:

  plugins: [
    require('@poi/plugin-karma')({
      coverage: true,
      chainWebpack (config) {
        config.module.rule('vue').use('vue-loader').options({})
      }
    })
  ]

I need to dig more into the matter why vue-loader isn't configured there and why the hell when testing a Vue.js SFC still causes errors but for now for testing just javascript code the above solution works

Happy coding

Friday, September 14, 2018

Replacing strings in proxied response using Apache mod_substitute

This is another quicky but it took me forever to finally figure it out - maybe someone will have that same problem...

The problem

You're working on a site that uses Apache2 proxy to merge your local frontend development environment with a remote site providing the content. That is easy to setup:

ProxyRequests Off
ProxyPreserveHost Off

ProxyPass "/path-to-a-resource" "http://localhost:3000/path-to-local-resource"
ProxyPass / http://remote-host/
ProxyPassReverse / http://remote-host/

Now all is nice and dandy until all you want to do is just to merge the remote site with local resources on localhost. It starts to get interesting when you want to modify the content sent by upstream server. Why? Well... let's say links in that sent HTML are absolute and you'd like them to be relative. There's a ton of options that are available once you can do that!

The solution

To be able to substitute strings in the response sent by upstream server there are 3 things that need to happen:

  • Enable the mod_substitute ($ sudo a2enmod substitute)
  • Enable filtering using mod_substitute
  • Specify replacement rules

The second part is what gave me a headache Today. Basically you need to understand 2 things: when Apache does the substitution it needs to have the full page received to be able to perform the substitution. That doesn't happen automatically. And then once the substitution is done Apache needs to put it all back together and send it to the browser. It's all done using the following for HMTL files only:

AddOutputFilterByType INFLATE;SUBSTITUTE;DEFLATE text/html

And last but not least: we need some substitutions to see the effect. For the purpose of demonstration we'll replace all class attributes with TEST:

Substitute "s|class|TEST|i"

That's it! It's easy as pie when you know the deal :) I know I'll be using it more and more in the future!

Happy coding!

Friday, July 6, 2018

Handling new POI's publicPath

Today I wasted over 3 hours frantically looking for explanation why the hell POI's publicPath setting thinks I am an idiot and it knows better what I want. So this is a quick post to let you know what you should do if you really want to change the output.publicPath in a POI-managed project.

The problem

Imagine you're working on some project that has pre-existing sources and their location is (surprisingly) not in the root of your server. That's the case every single time when you're working on existing apps trying to induce some build system on them to bundle up the scripts and stylesheets.

Usually, for those cases Webpack has a special configuration option output.publicPath that handles everything for you and life's good. POI, on the other hand, has that option exposed at the top level - but with a twist: it only works in final build and not in development mode.

The problem is, however, that if you'd like to work against an existing server that produces HTML and other artifacts you need to comply with that structure regardless of the mode. Unfortunately, POI fucking knows better! And here's the relevant point in POI's code that does it:


function getPublicPath(command, publicPath) {
  if (command === 'build' && typeof publicPath === 'string') {
    return /\/$/.test(publicPath) || publicPath === ''
      ? publicPath
      : publicPath + '/'
  }
  return '/'
}

module.exports = getPublicPath

I have no idea what was going through EGOIST's head at the time of writing but it must have been something really, really strong. Not good for opensource as it breaks the fundamental rule of least surrprise.

The fix

Instead of setting the publicPath in poi.config.js or setting it via command-line parameter override it in the resulting Webpack configuration like so:

module.exports = {
  configureWebpack(config, context) {
    // we're not setting publicPath as the general configuration option
    // because some sick bastard decided this will only have an effect
    // in production mode and we need it everywhere. Talk about predictability...
    config.output.publicPath = '/path/where/everything/lives/'
    return config
  },

With that life's good again (even thought it was so damn frustrating Today)

The architecture

Working on projects where the content is delivered from some sort of CMS or other app that has a fat backend isn't easy. It usually boils down to having everything running locally, even if we don't need it. There is, however, a better way of doing it! Use some reverse proxy to route traffic to your browser from 2 different sources: the backend and the frontend in development mode. Here's an example configuration with Apache2 but you can do much much more than that:

<VirtualHost :80>
    ServerName my-app.local

    # Make sure no caching is induced so that refresh always brings the latest version
    # run "sudo a2enmod headers" to enable headers module
    Header set Cache-Control no-cache

    # run "sudo a2enmod proxy_http" to enable http proxy
    ProxyRequests     off
    ProxyPreserveHost off

    # Serve all theme files from local development server
    ProxyPassMatch    "^\/path\/where\/everything\/lives\/(.*)$" "http://localhost:10001/path/where/everything/lives/$1"

    # Required by Hot Reload (run "sudo a2enmod proxy_wstunnel" to enable ws proxy)
    ProxyPassMatch    "^/(.+).hot-update.js$" "http://localhost:10001/$1.hot-update.js"
    ProxyPassMatch    "^/(.+).hot-update.json$" "http://localhost:10001/$1.hot-update.json"
    ProxyPassMatch    "^/sockjs-node/(.+)/websocket" "ws://localhost:10001/sockjs-node/$1/websocket"
    ProxyPassMatch    "^/sockjs-node/(.+)$" "http://localhost:10001/sockjs-node/$1"

    # Serve everything else from remote server
    ProxyPass         / http://dev-machine.somedomain.com/
    ProxyPassReverse  / http://dev-machine.somedomain.com/

</VirtualHost :80>

Also, don't forget to set NameVitualHost *:80 or the name-based virtual hosting just won't work. Now with that in place add the following entry to your /etc/hosts file:

127.0.0.1   my-app.local

and you're all set.

You can of course fiddle with it, add SSL support if your backend server requires it, but the point here is that it is possible and you can work without installing heavy backend to work on frontend!

Happy coding!

Saturday, June 23, 2018

Scaffolding a new Vue.js component

I've been working for the past few months on a travel portal rewriting parts of it from old jQuery code to Vue.js - and learning a lot of stuff in the process. One thing that I learned the hard way is that scaffolding that's built in into Vetur is just not for me. It is too simple.

The naming convention we have for our component files is for them to have the same name as the file they exist in. So basically TestMe.vue becomes

<template>
  <div class="test-me">
    ...content
  </div>
</template>

<script>
import Vue from 'vue'
import Component from 'component'

@Component({})
export default class TestMe extends Vue {
}
</script>

<style lang="scss" scoped>
.test-me {
}
</style>

Makes sense?

The problem is that having to type this in every time I create a new component (and the number of those grows like creazy!) is tedious. So I finally got to it and created a snipped that works for me:

That's it! You type "sfc", press [Tab] and the component is ready to be worked on by magic of the VS Code templating engine.

The first thing that'll be edited is the name of the exported class. If it is OK then just press [Tab] to move to the name of the CSS class. Edit it if you must then press [Tab] again and you'll be able to select the processor for styles. The next thing that you get to customize is if the styles should be scoped. Once on it either press [Tab] to go with scoped styles or [Delete] and then [Tab] to go without scoped styles. Finally you arrive at the Hello, world! text where the editing of your component begins.

Have a nice day!

Saturday, June 16, 2018

Vue.js - editor components

When talking about creating applications in Vue.js it is not hard to find one that does something to data. Obviously for state management there's Vuex, Redux and other stores but in this post we're going to focus strictly on passing state via props to components that one could generally call controls - so more on the lines of custom inputs.

The 3 cases

There are 3 cases that we will encounter when passing data down to controls:

  • We're passing in primitive values (strings, numbers, booleans)
  • We're passing in complex reactive objects (think: list of people)
  • We're passing in a complex reactive object but we'd like to treat it as a primitive and have atomic changes to all its fields

Primitives

In the case of primitives the situation is dead simple: use v-model, you can react to changes by hooking up to the input event - done. The documentation is fantastic in that area so if you'd like to know more about it dig in!

Reactive complex objects

Imagine you have a data structure like this:

data = { firstName: 'John', lastName: 'Doe' }

In this case if you create a control (we'll call it DataEdit.vue) that you'd like to immediately edit the fields you could do something like that:

<template>
  <div>
    <input v-model="value.firstName">
    <input v-model="value.lastName">
  </div>
</template>

<script>
export default {
  props: {
    value: Object
  }
}
</script>

This means that if used in a parent component (ContactForm.vue) like so:

<template>
  <div>
    <h1>{{ person.firstName }} - {{ person.lastName }}</h1>
    <DataEdit :value="person" />
  </div>
</template>

<script>
import DataEdit from './DataEdit.vue'

export default {
  components: {
    DataEdit
  },
  data() {
    return {
      person: { firstName: 'John', lastName: 'Doe' }
    }
  }
}
</script>

then changes to values in inputs in DataEdit.vue component will immediately be reflected in ContactForm.vue. Vue's reactive system at its best.

Treating complex objects like a value

This is the trickiest one because even though we're passing on a complex, reactive object we'd like to get all the changes at once or none at all. You might ask why would you want such a thing? The answer is quite simple: you'd like to implement "OK/Cancel" functionality or (if the edits drive some kind of Ajax requests) limit the number of actions upon edits. It is quite obvious that there will be a need for a copy of the reactive object. For that I use cloneDeep method from Lodash and it works just great so far.

<template>
  <div>
    <input v-model="internal.firstName">
    <input v-model="internal.lastName">
    <button @click="$emit('input', internal)>Save</button>
  </div>
</template>

<script>
import cloneDeep from 'lodash/cloneDeep'

export default {
  props: {
    value: Object
  },
  data () {
    return {
      internal: cloneDeep(this.value)
    }
  }
}
</script>

Now if that component is used in the ContactForm.vue (note the change from :value to v-model)

<template>
  <div>
    <h1>{{ person.firstName }} - {{ person.lastName }}</h1>
    <DataEdit v-model="person" @input="personUpdated" />
  </div>
</template>

<script>
import DataEdit from './DataEdit.vue'

export default {
  components: {
    DataEdit
  },
  data() {
    return {
      person: { firstName: 'John', lastName: 'Doe' }
    }
  },
  methods: {
    personUpdated(newValue) {
      console.log('Person has been updated to: ', newValue)
    }
  }
}
</script>

you won't see any changes to the header until they are saved by clicking the Save button. Pretty neat, right? On top of that you can be notified when the change occurred so if some additional action needs to take place (like updating list of people from an external database) by listening to the input event. That is just pure awesome!

One more thing...

If the editor persists it will now share the internal and value objects which will make it behave like the case where everything is reactive. Not good - let's do something about it

<template>
  <div>
    <input v-model="internal.firstName">
    <input v-model="internal.lastName">
    <button @click="$emit('input', internal)">Save</button>
  </div>
</template>

<script>
import cloneDeep from 'lodash/cloneDeep'

export default {
  props: {
    value: Object
  },
  watch: {
    value: {
      handler (newValue) {
        this.internal = cloneDeep(newValue)
      },
      deep: true
    },
  },
  data () {
    return {
      internal: cloneDeep(this.value)
    }
  }
}
</script>

The introduced watch updates the internal state so that it is again disconnected from the ContactForm.vue. Of course in a situation where the DataEdit.vue component is removed from DOM due to let's say closing a popup then the watch is completely unnecessary. It does however come in handy if there might be a possibility that the data object in question (or some of its parts) can be modified from the parent component. The internal state will be out of sync in such case. This might happen if some of the details come from an Ajax request or a timer. The watch covers both cases so it is basically a universal way for data synchronization on changes from parent component.

Working example

I know this is a lot to take in at once. Therefore I have prepared a test application for you that illustrates all the pieces. You can find it at https://github.com/padcom/vue-editor-components

That's it, folks!

Monday, April 9, 2018

Vue.js and functional single file components

Single file components (SFC) is probably the most powerful feature (structure-wise) in Vue.js. They are simple in nature but very powerful when it comes to bundling things together:

<template>
  <h1 class="my-header>Hello!</h1>
</template>

<script>
export default {
}
</script>

<style>
.my-header {
  color: red;
}
</style>

There are times when you want your component to be stateless. Such components are great for bundling together functionality that would otherwise be created by putting together other components. I call them template components, because they are predefined with places where you can override the defaults. Those components do not have state hence we call them stateless or functional.

The problem with SFCs is that unlike regular .vue components they don't pass data down. Especially the class and style properties are not passed automatically. To mitigate that I went through a few iterations to find the nicest solution. Here's what I came up with that seems to do the job very well. Let's assume we're creating a predefined component for animation. We want the styles to be bundled with the component so SFC is the right way to go.

<script>
export default {
  functional: true,
  render: (h, { data, children }) => (
    <transition-group { ...data } tag="ul" name="slide">
      { children }
    </transition-group>
  )
}
</script>

<style>
.slide-move {
  transition: transform 1s cubic-bezier(0.68, -0.55, 0.265, 1.55);
}
</style>

A quick explanation: { data, children } is a destructing assignment from the second parameter to 2 fields that we'll use later. Then the { ...data } means "apply all elements passed on (including but not limited to class and style).

That's all there is to it.

Thursday, March 22, 2018

HttpHandler registration on XSP4 vs IIS

The problem

You're developing an ASP.NET HttpHandler on Mono using XSP and now you need to deploy your app on IIS. What worked on XSP4 isn't working anymore and strange errors appear.

Let's start with the config that works on XSP4

<?xml version="1.0"?>
<configuration>
  <system.web>
    <httpHandlers>
      <add verb="*" path="*" type="MyHandler" />
    </httpHandlers>
  </system.web>
</configuration>

But you put that same Web.config file on IIS it throws errors.

The solution

As you see the registration happens inside system.web/httpHandlers section. That works on XSP4 and older ASP.NET but it's not the case on modern IIS. In there you need to switch to system.webServer/handlers section like this:

<?xml version="1.0"?>

<configuration>
  <system.webServer>
    <handlers>
      <add name="name" verb="*" path="*" type="MyHandler" />
    </handlers>
  </system.webServer>
</configuration>

That's it! Happy coding!