Develop Reference

Knockout's purecomputed equivalent in Angular?

From my understanding of this article, (and please correct me if I'm wrong) Angular's two way binding model using $watch is equivalent to Knockout's computed observables.
According to the KnockoutJS documentation, pure computed observables prevent memory leaks and reduce CPU overhead. Does AngularJS have an equivalent?
I'm not very proficient with either Knockout or Angular but have used both very briefly. Now, lets say that I have an existing application using KnockbackJS which I want to move to AngularJS. Now I have the things like routing and templating covered, but What would I do for all the instances where purecomputed is being used?

AngularJS 1.x and KnockoutJS are similar, yet very different. Concerning your question, they are actually wildly different: Angular uses a digest cycle for change detection, where KnockoutJS uses a subscription-based approach under the cover.
Yes, watches in Angular look a lot like computeds from KnockoutJS, because they allow you to do a manual "subscription" which is checked during each digest cycle.
That is also where comparing apples and oranges starts to loose its potency. The difference between a computed and a pureComputed is a technical detail of KnockoutJS. AFAIK there is no direct equivalent of that in AngularJS, or perhaps you could argue that a watch is the equivalent.
Most likely you have an XY-problem, where you know how to solve X in KnockoutJS: with computeds and pureComputeds. Don't try to translate Y to AngularJS, but try to translate X to your new situation, and find an idiomatic way to solve that with AngularJS instead.

Classroom Examples for decoupling software components

I'm trying to get to grips with highly-decoupled, low-cohesion patterns for designing components.
I'm designing each Feature of a larger system as a Web Component - analogous to the concept of a "Module" in design patterns, e.g Export-PDF functionality, Boards functionality etc.
The issue is that some components are dependent between them - they call methods of each, have access to their public variables etc.
Since each component needs to be testable in isolation, must be highly-decoupled, must have low inter-dependency with other components, what are some classroom examples for decoupling one from one another?
Considering this scenario:
User presses CTRL+P
Keybindings are handled by the Shortcuts Component
Shortcuts Component calls Export-PDF Component .print() method.
Some solutions I've though about:
Use events
Each component dispatches an event which is then caught in the other component, e.g using this.addEventListener(...
Pros:
Allows testing in isolation since there are no direct calls to another component's methods.
Cons:
Will result in many dispatches/listeners which might impact performance.
There is still a lot of coupling and it has the potential of getting unmanageable.
Use direct calls to methods of the other component
Each component simply calls the other components method directly, e.g exportPDF.printPages().
Pros:
It's the most simple.
Cons:
Each component is interdependent to one another.
Component is NOT testable in isolation.
What are some other methods of decoupling components?
For the record, the language of interest is JavaScript.
Although concepts and methods might be applicable across many programming languages, I'm specifically talking about concepts and solutions to the problems using features that JavaScript has.

How does a directive affect performance?

I had a discussion with a colleague about when to use directives.
I say that it is better to use directives only when you need DOM manipulation or a controller, in the other cases you should use plain HTML (or at best ng-include) in order to avoid adding more useless complexity to the code
He says you should use a directive almost everywhere, that is, even for static elements with no logic, because it increases readability in the code.
We started looking for info against or in favor of our points (such as AngularJS: ngInclude vs directive ) but we couldn't find anything about performance about directives.
So my question is: how much and in which ways does a directive affect performance?

React Flux: Store dependencies

so I have recently playing with React and the Flux architecture.
Let's say there are 2 Stores A and B. A has a dependecy on B, because it needs some value from B. So everytime the dispatcher dispatches an action, first B.MethodOfB gets executed, then A.MethodOfA.
I am wondering what are the advantages of this architecture over registering A as a listener of B and just executing the A.MethodOfA everytime B emits a change event?
Btw: Think about a Flux implementation without the "switch case" of the example dispatcher from facebook!

The problem with an evented approach is that you don't have a guarantee as to which handlers will handle a given event first. So in a very large, complex app, this can turn into a tangled web where you're not really sure what is happening when, which makes dependency management between stores very difficult.
The benefits of the callback-based dispatcher are twofold: the order in which stores update themselves is declared in the stores that need this ordering, and it is also guaranteed to work exactly as intended. And this is one of the primary purposes of Flux -- getting the state of an app to be predictable, consistent and stable.
In a very small app that is guaranteed to not grow or change over time, I can't argue with what you are suggesting. But small apps have a tendency to grow into large ones, eventually. This often happens before anyone realizes it's happening.
There are certainly other approaches to Flux. Quite a few different implementations have been created and they have different approaches to this problem. However, I'm not sure which of these experiments scale well. On the other hand, the dispatcher in Facebook's Flux repo and the approach described in the documentation has scaled to truly gigantic applications and is quite battle tested.

In my opinion I think this dispatcher is somehow an anti-pattern.
In distributed architectures based on event sourcing OR CQRS, autonomous components do not have to depend on each others as they share a same event log.
It's not because you are on the same host (the browser/mobile device) that you can't apply these concepts. However having autonomous stores (no store dependencies) means that 2 stores on the same browser will probably have duplicate data as the same data may be needed by 2 different stores. This is a cost to pay but I think in the long term it has benefits as it removes the store dependencies. This means that you can refactor one store entirely without any impact on components that do not use that store.
In my case, I use such a pattern and create some kind of autonomous widgets. An autonomous widget is:
A store that listen to an event stream
A component
A LESS file (maybe useless now because of React Styles?)
The advantage of this is that if there is a bug on a given widget, the bug almost never involve any other file than the 3 mentionned above ;)
The drawback is that stores that host the same data must also maintain it. On some events, many stores may have to do the same action on their local data.
I think this approach scales better to larger projects.
See my insights here: Om but in javascript

On using mixins in a CoffeeScript game engine

I am working on a CoffeeScript game engine for Html5 canvas. I came up with the "cool" idea to utilize mixins after I checked a very neat CoffeeScript implementation. I thought, it may be a very cool idea to reduce the various hierarchy of objects that game objects usually provide, by developing a set of mixin-based components, each of which has a very specific functionality. Then, when developing an actual game, one could build unique game objects on the fly by basically starting from one component and mixing it with a bunch of other components. This reduces the hierarchies and allows for frequent changes.
Then I thought about the possible collisions that might come up, for example having a few components define a method with the same signature. Now, I am not as excited as before.
What should I do? Is this a good way? I still like it, especially because of JS' underlying prototype mechanism, which allows for such an easy way to combine stuff on the fly.

You're talking about an entity component system. There are a couple written in JS; the most popular is Crafty, which is big but worth looking at. I recently wrote one in CoffeeScript (just for funsies; will probably never release it).
A few notes about collisions:
So first, the problem may be worse than you think: collisions will happen if two methods have the same name; JS doesn't differentiate function signatures. It also might not be so bad: why don't you just create a namespacing convention, where each behavior (meaning method) is named after the component it belongs to, like burnable_burn?
To take a step back though, mixins aren't the only way to build this - behaviors (i.e. things a component can do) don't have to be methods at all. The motivating question I ask is, how do you trigger a behavior? For example, you might do:
if entity.hasComponent "burnable" #hasComponent provided by your framework
entity.burn()
But that doesn't sound right to me; it creates a weird coupling between what's happening in your game and what components you have, and it's awkward to check if your entities implement the relevant component. Instead, I'd like behaviors to be listeners on events:
entity.send("applySeriousHeat") #triggers whatever behaviors are there
And then have your component do whatever it needs to do. So when you add a component to an entity, it registers listeners to events. Maybe it looks like (just sketching):
register: (entity) -> #called when you add a component to an entity
entity.listen "applySeriousHeat", -> #thing I do when this event is sent to me
#do burnination here
To bring that point home, if you do that, you don't care about collisions, because your behaviors don't have names. In fact, you want "collisions"; you want the ability to have more than one component respond to the same event. Maybe it burns and melts at the same time?
In practice, I used both setups together. I made entity.addComponent mix in the component's functions, since it's occasionally convenient to just call a behavior as a method. But mostly, the components declare listeners that call those methods, which helped with decoupling and reduced the awkwardness of having to use scoped names, since I don't call them directly in most cases.