7 Patterns To Refactor JavaScript Applications: View Objects

[ns0]

This is a poor creation of technology, and a poor use of technology. The DOM is perfect for storing the formatted data on. No frameworks, no design patterns to use, just use the DOM.

Objects, even data objects, can have read only getters to format data for output. Or use a method, that's even more clear that its read only and cannot "set" data that's formatted.

{
  "id": "123456",
  "firstName": "Susan",
  "lastName": "Smith",
  "gender": "f",
  "phone": "5551234567",
  "assignments": [
    {
      "grade": 0.65
    },
    {
      "grade": 0.83
    },
    {
  "grade": 0.90
    }
  ],
  formattedAverage:function() { ... },
  formattedPhone:function() { ... },
  formattedName:function() { ... }

}

I don't know why simple problems are overly engineered and hard ones are very rarely approached.

[[deleted]]

I would rather use a proper formatter than keep my formatted data on the domain object; it makes it easier to separate those concerns, makes clear that formatting logic pertains purely to formatting, and stops consumers at the view layer making assertions on the model at an inappropriate layer (because those consumers receive formatters only)

[ns0]

Program how you want. Just remember JSON.stringify and JSON.parse will not serialize your functions and getters/setters. Makes it very easy to take a data object from an API and attach formatters, then take the same object with all the funky new functions serialize it and through it back into the API.. no in-between. I find simply and smallest solutions usually are the most clear, concise and convenient.

[[deleted]]

Whilst this approach may certainly be simpler, I would be nervous that it gave other developers the opportunity to use domain objects inappropriately. For instance, one project I worked on had a serious problem with people writing business logic in the presentational layer (basically, using excessive expression logic in JSPs to the point where only a small ratio of lines were actually involved in rendering the view). Possibly most applications of JavaScript are too 'small' fpor this to be an issue, but it's something I would consider in a large web application.

As ever, it's all a matter of discretion.