Let's imagine, in a OO world, I want to build a Torrent object which listens to the network and lets me interact with it. It would inherit an EventEmitter and would look something like this:
var torrent = new Torrent(opts)
torrent.on('ready', cb) // add torrent to the UI
torrent.on('metadata', cb) // update data in the UI
and I can also make it do things:
torrent.stop()
torrent.resume()
Then of course if I want to do delete the torrent from memory I can call torrent.destroy().
The cool thing about this OO approach is that I can easily package this functionality in its own npm module, test the hell out of, and give users a nice clean reusable API.
My question is, how do I achieve this with Cycle.js apps?
If I create a driver it's unclear how I would go about creating many torrents and having their own independent listeners. Also consider I'd like to package functionality in a way that others get to easily reuse it in other Cycle.js apps.
It seems to me that you are trying to solve a problem thinking about it as you would write "imperative code".
I think creating Torrent instances with their own listeners is not something you should be using in cycle components.
I would go about it differently - creating Torrent module and figuring out what would be its sources and sinks. If this module should be reusable and published, you can create it as a function that would receive streams as arguments. Maybe something similar to TodoMVC Task component (which is then used in its parent component).
Since this module can be created as a pure function, testing it should be at least just as easy.
This implementation of course depends on your requirements but communication with the module would then be done only with streams and since it would be declarative there would be no need for methods like stop() and destroyed() which you would call from elsewhere.
How do I test it?
In cycle.js you'd write a component with intent model and view functions.
You'd test intent(), for given input Streams, produces Streams of actions that you want. For models, you'd test that given http and action streams, you get the state you want, and for view, you test that given a state you get the VDom you want.
One tricky bit with cycle.js is that since it passes functions around, normal JavaScript objects that use the 'this' keyword are not worth the trouble due to 'this' context problems. If you are working with cycle.js and you think you might write a JS class for use with Isolate, Onionify, or Collections most likely, you are going in the wrong direction. See MDN docs about 'this'
how I would go about creating many torrents
The Cycle.js people have several ways to deal with groups of things like this.
This ticket describes some things that might work for that:
Wrap subapp in Web Component
Stanga and similars.
Cycle Collections
Cycle Onionify
Related
So I have done a lot of research and for some reason I can't find an implementation of the Event Aggregator pattern in Javascript. In fact, the only language that's always used is C# and there's always generics being used. It's a very useful pattern so I fail to realize why it only seems to be 'meant' for .NET. I was hoping that someone would be able to provide an implementation in Javascript or at the very least Java and NOT C# (I've seen enough of that). Thank you!
How to:
Get one on the many general purpose publish/subscribe libraries that are implemented and ready to use. ie https://github.com/mroderick/PubSubJS (or roll your own - it ain't that hard)
Instantiate your event source objects, implement publishing of events.
Instantiate your aggregator, make it subscribe to your source objects, and offer publishing of received events.
Instantiate your target objects, make them subscribe to your aggregator.
In Javascript the Event Aggregator pattern does not need its own implementation. It is just an object that subscribes to multiple publishers and also publishes to multiple subscribers.
Since there are no type checking or interfaces anything of that sort, you dont need the pattern implemented before you use it, it is just a trivial exercise in pub/sub, which is probably why you can't find it anywhere as an "abstract" implementation.
Look into redux if you want to see something reusable that solves problems in the same domain as the event aggregator pattern, but offers a lot more.
In most modern JS frameworks, the best practice for loosely coupling your UI components is with some implementation of Pub / Sub.
The question I have is doesn't this make debugging, maintaining your app more difficult, whereas dependency injection could achieve the same result (loose coupling)?
For example, my component should open a dialog when clicked. This needs to happen or else the UI will appear broken. To me it seems more readable to have the component make an explicit call to some dialog service. In the wild, I see this problem solved more with pub sub, so maybe I am missing something.
When using both methods together, where is a good place to draw the line when something should fire an event or fulfill that action with an injected service?
Pub-sub is great for application-wide events where the number of potential subscribers can vary or is unknown at the moment of raising an event.
Injection always sets the relation between two, sure, you can create decorators/composites and inject compound objects made of simple objects but it gets messy the moment you start to do it.
Take a tree and a list for example. When you click a node, the list should be rebuilt. Sounds like injection.
But then you realize that some nodes trigger other actions, headings are updated, processes are triggered in the background etc. Raising an event and handling it in many independent subscribers is just easier.
I would say that injection works great through layers, when you compose a view and a controller or a view and its backing storage.
Pub-sub works great between objects in the same layer, for example different independent controllers exchange messages and react accordingly.
Background
We have a fairly complex Silverlight client which we are rewriting in HTML/Javascript/CSS, built on top of the same web services. Actually we have two Silverlight different clients which we are porting, which share some common functionality.
I read the article on http://addyosmani.com/largescalejavascript/ and am planning to use the proposed architecture, and in particular the mediator pattern.
A 10000 feet overview of the pattern described by Addy:
code is divided into small Modules
Modules are only aware of a mediator object; Modules cannot communicate directly with other modules
the mediator has a simple interface for publishing and subscribing to messages
Modules can subscribe to messages (through the mediator API), giving a callback function
Modules can publish messages to the mediator, with a parameter object, and the mediator calls the callback method of any modules subscribed to the message, passing the parameter object
One of the main goals here is to achieve loose coupling between modules. So we can reuse the modules in the two clients. And test the modules in isolation. And the mediator should be the only global object we need, which has got to be good.
But although I like the idea, I have the feeling it is overly complicated in some cases, and that some of my team members will not be convinced. Let me explain by example:
Assume we have a helper function which performs a calculation - lets say it formats a string - and assume this function should be available to any module. This function could belong in a 'tools' or 'helper' module which is then reusable and testable.
To call this function from an arbitrary module I have to post a message, something like formatString with my input string as parameter. And the helper function has subscribed to the formatString message. But before I post the formatString message I first have to subscribe to a message like formatStringResult, with a callback function which can receive the result. And then once I get the result back, I unsubscribe from the formatStringResult message.
Question(s)
Should the mediator rather offer this type of helper functionality directly in it's own interface?
Or should I extend the publish interface to allow an optional result parameter, where helper methods can directly write a result?
Is the tradeoff of having an extra mediator layer really worth the
benefit of achieving loose coupling?
I'd really appreciate advice from developers with experience of achieving loose-coupling in 'complex' JavaScript applications.
You actually perfectly described the BarFoos application Framework:
https://github.com/jAndreas/BarFoos
I don't think that mediator is the pattern what you are looking for, at least not for what you described.
Just think of 2 object triggering formatString the same time. What each would get back in their formatStringResult?
Mediator is for broadcasting events to everyone who is listening. Publishers don't want to broadcast requests (e.g. formatString) rather want to notify others about a change in their own state. Note how the source and consumer of the information is different. Having a mediator means those parties don't have to have a reference to each other to communicate, thereby its lowering the coupling.
After dabbling with javascript for a while, I became progressively convinced that OOP is not the right way to go, or at least, not extensively. Having two or three levels of inheritance is ok, but working full OOP like one would do in Java seems just not fitting.
The language supports compositing and delegation natively. I want to use just that. However, I am having trouble replicating certain benefits from OOP.
Namely:
How would I check if an object implements a certain behavior? I have thought of the following methods
Check if the object has a particular method. But this would mean standardizing method names and if the project is big, it can quickly become cumbersome, and lead to the java problem (object.hasMethod('emailRegexValidatorSimpleSuperLongNotConflictingMethodName')...It would just move the problem of OOP, not fix it. Furthermore, I could not find info on the performance of looking up if methods exist
Store each composited object in an array and check if the object contains the compositor. Something like: object.hasComposite(compositorClass)...But that's also not really elegant and is once again OOP, just not in the standard way.
Have each object have an "implements" array property, and leave the responsibility to the object to say if it implements a certain behavior, whether it is through composition or natively. Flexible and simple, but requires to remember a number of conventions. It is my preferred method until now, but I am still looking.
How would I initialize an object without repeating all the set-up for composited objects? For example, if I have an "textInput" class that uses a certain number of validators, which have to be initialized with variables, and a class "emailInput" which uses the exact same validators, it is cumbersome to repeat the code. And if the interface of the validators change, the code has to change in every class that uses them. How would I go about setting that easily? The API I am thinking of should be as simple as doing object.compositors('emailValidator','lengthValidator','...')
Is there any performance loss associated with having most of the functions that run in the app go through an apply()? Since I am going to be using delegation extensively, basic objects will most probably have almost no methods. All methods will be provided by the composited objects.
Any good resource? I have read countless posts about OOP vs delegation, and about the benefits of delegation, etc, but I can't find anything that would discuss "javascript delegation done right", in the scope of a large framework.
edit
Further explanations:
I don't have code yet, I have been working on a framework in pure OOP and I am getting stuck and in need of multiple inheritance. Thus, I decided to drop classes totally. So I am now merely at theoretical level and trying to make sense out of this.
"Compositing" might be the wrong word; I am referring to the composite pattern, very useful for tree-like structures. It's true that it is rare to have tree structures on the front end (well, save for the DOM of course), but I am developing for node.js
What I mean by "switching from OOP" is that I am going to part from defining classes, using the "new" operator, and so on; I intend to use anonymous objects and extend them with delegators. Example:
var a = {};
compositor.addDelegates(a,["validator", "accessManager", "databaseObject"]);
So a "class" would be a function with predefined delegators:
function getInputObject(type, validator){
var input = {};
compositor.addDelegates(input,[compositor,renderable("input"+type),"ajaxed"]);
if(validator){input.addDelegate(validator);}
return input;
}
Does that make sense?
1) How would I check if an object implements a certain behavior?
Most people don't bother with testing for method existance like this.
If you want to test for methods in order to branch and do different things if its found or not then you are probably doing something evil (this kind of instanceof is usually a code smell in OO code)
If you are just checking if an object implements an interface for error checking then it is not much better then not testing and letting an exception be thrown if the method is not found. I don't know anyone that routinely does this checking but I am sure someone out there is doing it...
2) How would I initialize an object without repeating all the set-up for composited objects?
If you wrap the inner object construction code in a function or class then I think you can avoid most of the repetition and coupling.
3) Is there any performance loss associated with having most of the functions that run in the app go through an apply()?
In my experience, I prefer to avoid dealing with this unless strictly necessary. this is fiddly, breaks inside callbacks (that I use extensively for iteration and async stuff) and it is very easy to forget to set it correctly. I try to use more traditional approaches to composition. For example:
Having each owned object be completely independent, without needing to look at its siblings or owner. This allows me to just call its methods directly and letting it be its own this.
Giving the owned objects a reference to their owner in the form of a property or as a parameter passed to their methods. This allows the composition units to access the owner without depending on having the this correctly set.
Using mixins, flattening the separate composition units in a single level. This has big name clash issues but allows everyone to see each other and share the same "this". Mixins also decouples the code from changes in the composition structure, since different composition divisions will still flatten to the same mixed object.
4) Any good resources?
I don't know, so tell me if you find one :)
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.