I have gone through the documentation understand what exactly is stub.callsArgWith here:
http://sinonjs.org/releases/v1.17.7/stubs/
But I could not not understand what it makes sense when we chain it like below:
stub.callsArgWith(1, null, "ok")
.callsArgWith(1, new Error("Error!"));
So, basically what it mean is param at index 1 is a callback function and it should be called with first param = null and 2nd param as "ok". But what I could not understand is in what situation we do chaining of callsArgWith and in what sequence are they get used.
Please help me in understanding what exactly is the meaning of above two lines how they will be executed, mean when will it take 'Ok' and when will it return an error.
In older versions of Sinon (specifically versions 1.5 - 1.7), this was how you described behaviour for consecutive calls.
Otherwise, the second callsArgWith call replaces the behaviour of the first callsArgWith.
So in the your example (and assuming the version of Sinon is v1.5 - 1.7):
stub.callsArgWith(1, null, "ok")
.callsArgWith(1, new Error("Error!"));
When the stubbed function is called for the first time,
it will call the 2nd parameter of the stubbed function with the parameters null and "ok".
The second time the stubbed function is called, it will call the 2nd parameter of the stubbed function with an Error object.
So in the your example (and assuming the version of Sinon is NOT v1.5 - 1.7):
stub.callsArgWith(1, null, "ok")
.callsArgWith(1, new Error("Error!"));
Every time the stubbed function is called it will call the 2nd parameter of the stubbed function with an Error object.
Documentation Link: http://sinonjs.org/releases/v1.17.7/stubs/#defining-stub-behavior-on-consecutive-calls
Related
What's the proper way to interrupt a long chain of compose or pipe functions ?
Let's say the chain doesn't need to run after the second function because it found an invalid value and it doesn't need to continue the next 5 functions as long as user submitted value is invalid.
Do you return an undefined / empty parameter, so the rest of the functions just check if there is no value returned, and in this case just keep passing the empty param ?
I don't think there is a generic way of dealing with that.
Often when working with algebraic data types, things are defined so that you can continue to run functions even when the data you would prefer is not present. This is one of the extremely useful features of types such as Maybe and Either for instance.
But most versions of compose or related functions don't give you an early escape mechanism. Ramda's certainly doesn't.
While you can't technically exit a pipeline, you can use pipe() within a pipeline, so there's no reason why you couldn't do something like below to 'exit' (return from a pipeline or kick into another):
pipe(
// ... your pipeline
propOr(undefined, 'foo'), // - where your value is missing
ifElse(isNil, always(undefined), pipe(
// ...the rest of your pipeline
))
)
So I have this in a PhpUnit test:
$alias_manager = $this->prophesize(AliasManagerInterface::class);
$alias_manager->cacheClear($source)->shouldBeCalledTimes(1);
And I would like to tell Prophecy that this is all the alias manager should be called with, no other methods should be called nor this method with any other argument. The latter I can do
$alias_manager->cacheClear(Argument::any())->shouldBeCalledTimes(1);
but how do I say "nothing else" for Prophecy?
With Prophecy, if you call reveal() on the object prophet immediately, the object is assumed to be a dummy object. This means that it'll return null for all public methods of the object it's prophesizing.
However, as soon as you add one method prophet (e.g. by doing your shouldBeCalled...() call or a willReturn() call), the returned object will be a mock or a stub object. In this case, only the configured calls will work and all other calls that are executed will trigger failure.
In other words: You don't have to do anything, this is the standard behaviour.
I'm writing a program in Scala and trying to remain as functionally pure as is possible. The problem I am facing is not Scala specific; it's more to do with trying to code functionally. The logic for the function that I have to code goes something like:
Take some value of type A
Use this value to generate log information
Log this information by calling a function in an external library and evaluate the return status of the logging action (ie was it a successful log or did the log action fail)
Regardless of whether the log succeeded or failed, I have to return the input value.
The reason for returning the input value as the output value is that this function will be composed with another function which requires a value of type A.
Given the above, the function I am trying to code is really of type A => A i.e. it accepts a value of type A and returns a value of type A but in between it does some logging. The fact that I am returning the same value back that I inputted makes this function boil down to an identity function!
This looks like code smell to me and I am wondering what I should do to make this function cleaner. How can I separate out the concerns here? Also the fact that the log function goes away and logs information means that really I should wrap that call in a IO monad and call some unsafePerformIO function on it. Any ideas welcome.
What you're describing sounds more like debugging than logging. For example, Haskell's Debug.Trace.trace does exactly that and its documentation states: "These can be useful for investigating bugs or performance problems. They should not be used in production code."
If you're doing logging, the logging function should only log and have no further return value. As mentioned by #Bartek above, its type would be A -> IO (), i.e. returning no information () and having side-effects (IO). For example Haskell's hslogger library provides such functions.
I understand what recursive functions are, but consider the following example of a function meant to get the local version of data on an item, check if there is new data about it available online based on locally stored cache time, and if there is, updating the local data with the new version, returning up-to-date data about it either way.
function getItemData(id){
var local=getLocalItemData(id);
if(!local.cacheTime.upToDate()){
var newData=getOnlineItemData(id);
updateLocalItemData(id, newData);
return getItemData(id);
}
else{
return local.returnHumanReadable();
}
}
My argument against considering it a recursive function is the fact that it will only end up calling itself on rare occasions when the cache time indicates the data has expired, and that the function only calls itself for convenience.
Instead of using return getLocalItemData(id).returnHumanReadable(); I can use return getItemData(id); because it will return the same result, as the newly saved data won't need to be refreshed again in the several microseconds it will take the function to call itself. Also, it is much shorter: in the actual code, I would use lower level commands instead of those function calls, resulting in code duplication which would make the entire function harder to read and maintain.
So, do you think that my argument makes any sense, or do you consider this to be nothing more than a matter of code organization?
The short answer is: yes it is recursive
It becomes important if you consider a platform that does not support recursion
Since it can call itself, your code will not work on that platform because it is technically recursion
For a trivial case like this replacing the recursive call with getLocalItemData(id).returnHumanReadable(); will allow it to work on this platform. In fact, you can change your code to:
function getItemData(id){
var local=getLocalItemData(id);
if(!local.cacheTime.upToDate()){
var newData=getOnlineItemData(id);
updateLocalItemData(id, newData);
local=getLocalItemData(id);
}
return local.returnHumanReadable();
}
NOTE: If you cannot 100% guarantee that only one call is needed, change the if to while
Looking at Tracker.autorun, this mostly works magically...but I'd like to know how it decides which variables are going to form the dependency for the computation. It picks out only "reactive" vars, for example the following:
window.bar = 1
Tracker.autorun (c) =>
bar = window.bar
foo = Session.get('foo')
console.log('autorun', foo, bar)
If I change the value of Session.set('foo') this will cause the computation to run again.
whereas just changing window.bar doesn't cause a rerun. If I use a subscribe result (not a collection) this also works, so that I guess is reactive too.
Are there any guides to understanding this behavior a bit better?
EDIT:
thanks for the comments below that clarify the computation is able to be inferred because accessors are used for reactive vars, so meteor can track deps.
However I need a bit more clarity to understand when a var is flagged. for instance in this example below, the subscribe call is outside the autorun, but it puts the results into an array. So that means that Tracker is not just tracking calls to (reactive var) accessor methods, but also any variables that are referenced within a block - even if the calls to setup those methods are outside the autorun() block.
subList = [
Meteor.subscribe("Players"),
Meteor.subscribe("Stuff" )
]
Tracker.autorun (c) =>
subReady = _.filter subList, (item) ->
return item.ready()
allDone = (subList.length == subReady.length)
# this code will rerun when the subs ready() are true
maybe i should add this as a new question... it's related to this question .
I'm not an expert and haven't read much about it, but I can try to explain it briefly.
All reactive variables have a thing called a dependency. For example, when one creates a new ReactiveVar, an new dependency is created. See here.
To retrieve the value from a reactive variable, one must call a function. In that "getter", the dependency is instructed to remember that it has a dependency. For example, see here for ReactiveVar.get.
To change the value for a reactive variable, one must call a function. In that "setter", the dependency is notified that something has changed, and that signals that all functions depending on the dependency must rerun. For example, see here for ReactiveVar.set.
Not complicated, right? Well, that was just the easy part, all that remains now is building the infrastructure that makes it work :) That's harder and more complicated to explain.
Reactive variables aren't reactive by themselves; they must be evaluated in a reactive environment in order to be reactive. A reactive environment is created by calling Tracker.autorun. See here.
When you call Tracker.autorun, the function you passed to it will be executed in a new reactive environment, and all dependencies the reactive variables notifies of with the depend method will be tracked by the environment. When you call aDependency.depend, this function will be executed, and it kind of adds the dependency to the environments list over dependencies it depends on.
When a reactive variable changes its value, this function will be executed. It tells the environment that one of the reactive variables it depends on has changed, and invalidates all the dependencies in the environment. After this has happened, the entire function you passed to Tracker.autorun will be re-run, and the new dependencies will be tracked.
Do you get the big picture? It's implementation is a bit more complicated than I've explained, but I think that's kind of how it works.
Notice that whenever you access a reactive variable, it's through a function call, like Session.get(...), or collection.find(...).fetch(), or Meteor.status(). A function like Session.get does not only get the value of a Session variable, but also registers a dependency on the current computation (the current computation is dynamically scoped, so Session.get knows that it was called from an autorun).
Here's how you can implement your own reactive variable using Tracker.Dependency:
dependency = new Tracker.Dependency()
currentValue = null
#setCurrentValue = (newValue) ->
if newValue isnt currentValue
# rerun computations which depend on this Dependency
dependency.changed()
currentValue = newValue
#getCurrentValue = ->
# register this dependency on the current computation (if there is one)
dependency.depend()
return currentValue
And here's how you could use it:
setCurrentValue("hello")
Tracker.autorun ->
console.log(getCurrentValue())
# => "hello" printed
setCurrentValue("goodbye") # => "goodbye" printed
For more information, you could look at this guide: https://meteor.hackpad.com/DRAFT-Understanding-Deps-aAXG6T9lkf6 (note that Tracker was originally called Deps in older versions of Meteor)