Tag Archives: good

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

Bad Code: Too Many Object Conversions Between Application Layers And How to Avoid Them

Have you ever worked with an application where you had to copy data from one object to another and another and so on before you actually could do something with it? Have you ever written code to convert data from XML to a DTO to a Business Object to a JDBC Statement? Again and again for each of the different data types being processed? Then you have encountered an all too common antipattern of many “enterprise” (read “overdesigned”) applications, which we could call The Endless Mapping Death March. Let’s look at an application suffering from this antipattern and how to rewrite it in a much nicer, leaner and easier to maintain form.
Continue reading

Simple vs. Easy: Writing A Generic Code To Avoid Duplication (Representation of Data To Import)

In our batch jobs for data import we had many similar classes for holding the data being imported. Technically they are all different, with different fields, yet conceptually they are all same. I find this conceptual duplication discomforting and have written a single, more generic, class to replace them all.

The refactoring has been inspired by Clojure and its preference of few generic structures such as maps with many functions over the OO way of many case-specific data structures (i.e. classes), as explained for example in this interview of Rich Hickey, starting with “OO can seriously thwart reuse”.

Continue reading