Tag Archives: javascript

Simple or Complex? Familiar Imperative Code Or Makes-Me-Think Declarative One?

We have had a heated discussion today about the two alternatives of JavaScript code that filters out elements with a different hardwareType (if supplied):

The imperative solution (1) is familiar to all of us and thus easy to grasp. However the declarative solution (2) is not familiar, we have to think about what it does, we need to know that .filter({bundle: {product: {type: filter.hardwareType}}}) keeps only bundles that have the given product.type and that .filter(null) does keep all. Thus (1) is easy to understand, (2) isn’t.

Continue reading

Advertisements

Link: Refactoring to an Adaptive Model – Martin Fowler

Martin Fowler’s Refactoring to an Adaptive Model, 11/2015 – replacing imperative logic with a declarative one, with rules encoded in JSON so that they can easily be shared across platforms and updated without re-installation. A few other nice refactoring points too.

Most of our software logic is written in our programming languages, these give us the best environment to write and evolve such logic. But there are circumstances when it’s useful to move that logic into a data structure that our imperative code can interpret – what I refer to as an adaptive model. Here I’ll show some product selection logic in JavaScript and show how it can be refactored to a simple production rule system encoded in JSON. This JSON data allows us to share this selection logic between devices using different programming languages and to update this logic without updating the code on these devices.

Declarative Beats Imperative: Transforming Data In JavaScript

The product I am working on is a fairly typical web application, based on React.js and Node.js. Its main task is to fetch data from different REST-ish services, combine them, and present them in an attractive manner to users. This data extraction and transformation – keeping only the items and properties we care about and structuring them in a way well aligned with the needs of the UI – is thus crucial. I would like to share our journey from an imperative implementation of this process to a much more reader-friendly declarative one.

For example, here is some JSON data we get back from a REST service:

[{
    productId: "42",
    type: "TEAPOT",
    subProducts: [{
        productNumber: "ch132",
        name: "Kyusu Teapot",
        dealerDetails: [
          { dealerGroup: "webshop", rank: 1 }
        ]}]}];

And here is what we would like to transform it into:

{
  "42": {
    "productId": "42",
    "variations": {
      "ch132": {
        "productNumber": "ch132",
        "name": "Kyusu Teapot",
      }
    },
    "selectedSubProductId": "ch132"
  }}

My first implementation was functional, using the wonderful functional library lodash, but rather imperative. We had a series of functions that transformed some vague JavaScript object / JSON into something else. It looked something like this:
Continue reading

Let the API Do the Hard Work: Promises in JavaScript with Q

Today’s lesson: Delegate the hard work orthogonal to your business logic – concurrency, asynchronicity, state maintenance during iteration etc. – to your language and API if you can. They are more likely to get it right and your code will be more focused on what you are actually trying to do. You should feel an unpleasant tingling when you have do these manually. We will look at JavaScript code that uses asynchronous calls to get data in a too manual (and incorrect) way and improve it to delegate the necessary synchronisation to the promises library Q that it already uses.

Continue reading

Improve This: Twitter Streaming And Transformation in JS (link)

In improve this we take a look at a reader submitted test, user interface, story or block of code and we try and improve it, without context, explaining what we did as we went.

In this issue, Mike sent a link to an event source to a realtime social media visualization.

Read the full original post.

Highlights: use of JSLint and JSHint, removal of unnecessary dependencies, nested callbacks, testing, refactoring  to split by responsibilities, … .

Intention Hidden In Implementation And Misty Edge of Validity

The code is the documentation” – except that from poorly written code you cannot tell what is an intrinsic part of the solution and what is an accidental implementation detail. And a piece of code can rarely handle any possible data – yet, without a good documentation or precondition checks, you can’t even guess at what are valid or unexpected inputs. Today we will explore a piece of JavaScript code that both hides the intention in the implementation (the “why” is not clear from the “what” the code does) and operates correctly only under particular but unstated conditions.

Continue reading