Today I was implementing some feature using “use case as object” approach – where use case tells a story about interactions between actor and domain entities. It’s a simple object with few methods and each of those methods is invoked as a result of control flow or interaction via UI or services. It should emanate actions at the same abstraction level, so higher use cases can use lower ones.

It’s obvious that use case gives you some context – in Buying use case it could be Shop context (or buying because maybe distinction between context and use case is not needed). Those contexts can divide actor definition into raw “common-abilities-and-data” model and roles that actor can take. That’s how I understand DCI approach.

But your app is not only domain logic, but also has some UI layer to get some interactions with real user. As a presentation layer it should show current state of application, current context. So why don’t we bind UI to use case with something like controller – use case doesn’t know anything about UI, and UI presents state of use case. I mean if some component is hidden in this use case’s context it should be hidden by this controller. If current use case disables some paths they should be presented as disabled.

Ok, but what about all the “view should present domain models” stuff? My first thought was – maybe view changes, in DCI approach, are triggered by use case actions, not by domain entities, like in classic MVC? So they should present current context (within use case), probably with shared presentation behaviours extracted for reuse.

Or… Maybe views should still present current domain entities states, but also with their abilities in current context. So extending domain entity with role would trigger view changes to present roles behaviours.

Currently I’m not sure which way is good – I’ve written some production code with view-as-use-case-state-presentation and it seems nice, but second approach looks also interesting. What are your thoughts about that?

We had interesting discussion about one of commits, which changed way for delivering stubbed server responses in our test suite. In short: we have jasmine-based acceptance tests for client-side, which uses jQuery .click and other event triggers to simulate interaction with user. All requests to server-side are stubbed, so we have to produce some JSON-like data structures to respond with them. Almost every test use the same data, but sometimes we need to change something to test specific scenario.

1st solution

It was based on global object ServerResponses with few fields for each type of request. That fields contained objects, which were stub responses for specific request. Take a look at the code (CoffeeScript):

OK, not bad, but what if I want to change something in player attributes, for examples his points?

Now you see where the problem is – if we want to change inner object we have to clone it. It sucks.

2nd solution

Here’s the point, where the discussion begins – I replaced initialData object with initialData object factory. In CoffeeScript the change is syntactically small:

So as you see each response is represented by new object, instead of shared one. We can pollute these responses with everything we need, we don’t have to think about global state. But there is one problem – it’s a function, so we have to remember about “()”. That’s sad, awful and too complicated.

Is there any chance to get this as beautiful as furry bunnies on green grass?

3rd solution

So let’s design perfect solution for this problem. Let’s have a function “merge”, which would create new object from object given as first parameter, and new values in second one. “Perfect code”:

It looks nice. If we assume, that every object can only update its fields or extend with additional fields – it seems doable. We can live with this assumption, but let’s think how it can be implemented… First of all – for each field of second parameter object we must create clone of corresponing object in first parameter. It has to be deep clone of object sometimes, so it isn’t easy to implement. Please, remember the context – we want it as tests helper. So to get “perfect code” we would have to implement helper, which also needs to be tested. But ok, we can do it in 1 hour – because we love “perfect code”.

What’s the biggest problem with that solution? That it doesn’t protect us from affecting global state of tests. We still can do ServerResponses.initialData.player.points = 10.

Summary

Object factory:

• has ugly “()” in every use (eeeew, worst thing ever)
• always use new object, without reference to global state
• has ugly name – factory
• has simple implementation

Merge function:

• syntactically beautiful
• has complex implementation (we are awesome, so we’ll write it with full test suite)
• doesn’t protect global state

tl;dr

Handlebars > other JS templating libs/tools (ps. maybe except dust.js)

Here’s the story

I work for startup GameBoxed.com. My job is to implement new game scenarios, improve old ones and few other things. All games are written in JavaScript/CoffeeScript, all of them are one screen only – every view change is made by JS. For few months we used to render all views on server-side (statically and dynamically), sometimes updating old static templates with new values with jQuery. It was quite clear to us we should change the way we render views – we should only use static, not prefilled templates with easy way to fill them with data. First try was Mustache, next is Handlebars. We’re also thinking about Pure.js, but this blog will show you, that Pure.js is hard.

Templating trash

• EJS – too easy to add logic to template
• jquery-tmpl – collection support is too poor
• underscore.js template – also oto easy to add logic
• Mustache – too simple

Pros and cons of Handlebars

compilable

You don’t have to process same template on one runtime – Handlebars.compile simply creates function, which can be applied to context to render HTML.

extendable

Nice API to extend template logic, but with little pain, that makes you to think twice about putting logic into template.

simple

Create template with holes, fill them with JSON data, add to DOM with third-party tool.

only for render

It’s created for one thing only – rendering templates. There is no support for updating existing components. There is also no support for DOM management.

Why I like Handlebars.js over Pure.js

First of all it’s too complicated. You can pass your data (context) as crappy JSON with matchers as field names, or leave translating matchers in directives. Matchers seems to be hard to manage – for each piece of data you must define one, so your templates are not so friendly to get filled. Of course you can use conventions, so it can be easier, but than you have to use ugly css class-based convention. It is also too complicated to render template for collections.

Pure.js is much bigger than handlebars – in sense of functionality. It can manage DOM, update easily rendered view. Maybe it’s worth it to write matchers to get this ease of updating? I’m almost 100% sure, that it is easier to render template with Handlebars and than update it with jQuery – it’ll need some conventions, but much more flexible than those from pure.js. In next blog I will show how to write Handlebars templates that are easy to update.

Ps. While I was about to finish this blog post, Andrzej tweeted about dust.js in LinkedIn. Fuuuu…