Remove commands #221
Remove commands #221
Conversation
|
Thanks @paulfalgout! This doesn't quite resolve #187, though; there are still a few additional changes I'd want to make. No reason to hold back this PR, but if you could change the OP so that Github doesn't autoclose that issue that would be dope. |
|
I'll explain the reasoning of this for posterity. Commands don't have a notable benefit over Requests. In fact it is almost identical code with only one difference: Commands have no return value. The problem with this comes from testing. When you want to do something asynchronous in a command, you have virtually no way of testing it that doesn't tie itself to the implementation. As where in Requests you can simply return a promise and have everything work nicely. We discussed adding in message queuing a la Backbone.Wreqr Commands. However there still wasn't a very good use case here over Requests and you run into the issue where you would likely rather know that a command has not yet been registered. For example, say I Hopefully this explains just about everything. I haven't seen many people use commands so I doubt this will be an issue with anyone. We're simply trying to narrow things down to the very best API. |
| @@ -74,62 +72,19 @@ myBus.trigger('some:event'); | |||
| ``` | |||
|
|
|||
| This is the first principle of Backbone.Radio: building a message bus out of Backbone.Events is useful. But before we go more | |||
| into that, let's look at the two other messaging systems of Backbone.Radio. | |||
| into that, let's look at another messaging system of Backbone.Radio. | |||
There was a problem hiding this comment.
the other
This explicitly repeats the fact that there are exactly two, rather than n.
paulfalgout
force-pushed
the
remove-commands
branch
from
249aea1
to
b36581e
Compare
Resolves #186
Edited to remove unresolved issue