Should you bind the computed properties in Vue?

Short Answer

No you shouldn’t.

Philosophy

Computed properties are non-integral parts of the presentation layer and what presentation is for? – to represents. If you are changing the presentation layer then you are using the presentation layer for reverse information flow. Information flow must be in a single direction – From Top to Bottom. By using binding computed properties you will probably end up in having a loop because X changes Y and Y changes X so one. This circular flow of information will be easy to detect as either it will crash or the browser will stop responding

What do use then?

You can bind two different data and send the results of computed data along with form data.

Worth Sharing?

How to parse boolean or numeric values in fastify query string

Imagine that you have a root route and you are sending query parameter as below:

http://localhost:3000/?status=true&page=80

If you log request.query it will be printing like this:

{ status: 'true', page: '80' }

Obviously if now you are planing to do something like following, it will have an unexpected results:

if(request.query.status === true){
 // Always true because status=false will be interpreted as a string
}

Solution – Schema

  fastify.get('/', {
    schema: {
      query: {
        $id: 'example-parser',
        properties: {
          page: {
            type: 'number'
          },
          status: {
            type: 'boolean'
          }
        }
      }
    }
  }, function (request, reply) {
    const query = request.query
    return { query }
  })

Now the output will be following:

{ status: true, page: 80 }

Defaults

Another problem is when you have an empty query string then what? For instance is you have opened url like this:

http://localhost:3000/

Out will be an empty objection

{}

Avoid undefined check

First you might be tempted to go with standard way of JS which is to check for undefined like this:

if(typeof request.query.status !== 'undefined' && request.query.status === true){

}

Fastify Way

But you can avoid this by adding default key in properties keys as following:

  fastify.get('/', {
    schema: {
      query: {
        $id: 'example-parser',
        properties: {
          page: {
            type: 'number',
            default: 1
          },
          status: {
            type: 'boolean',
            default: true
          }
        }
      }
    }
  }, function (request, reply) {
    const query = request.query
    return { query }
  })

This will result in status=true and page=1 instead of an empty object as following so now you can avoid it.

{ status: true, page: 1 }

Worth Sharing?

Critical Decision of Re-Writing a Wheel!

I have been in cross-roads – when the officially supported libraries are not in the language in which our app is coded. Have you? Did you re-write it or did you use it as it is?

I had both good and bad experience with that however, with enough experience, I can distinguish why it was good and why it was bad.

The Bad

Officially supported library was in Node. However, we only had at that moment expertise in PHP. We went ahead and coded a library full of YAML in PHP. Our app became popular, and we just couldn’t scale without giving heavy cost for servers! We accepted PHP is there because it is too big to kill.

The Bad in Good

Officially supported library was in Node again. This time we re-coded it in Go. We were using in node as the usage was vast and it would take us three months at least to rewrite before we even began to use it. In Go, immediately we were able to reduce the servers and then most of the errors/bugs were caught in compile time. Yet it wasn’t worth it at all since server cost saved was nothing comparison to manpower we have put to keep it updated and retaining these talents!

The Good

Officially supported library was in PHP. We were already burnt once so shying away to use it. We wrote it – it took us little over 2 months. Damn, you have to write a lot in Go. Obviously we had reduced server cost a lot but since app demanded almost real time updates, we were able to pull it off without a lot of overheads like Redis and RabbitMQ.

Our conclusion

As long as language is multi threaded we will be better off using it. If not, re-write it.

Worth Sharing?