I am creating an ampify.js binding for the WebSharper. (https://github.com/aph5nt/websharper.amplifyjs). While testing my extension I found one issue with publish / subscribe implementation.
I declared a subscription handler:
let subscribeFn (data:obj) = JS.Alert(data :?> string)
I created a subscription:
Amplify.Amplify.Subscribe("tryPubSub", subscribeFn)
When I want to unsubscribe then I do:
Amplify.Amplify.Unsubscribe("tryPubSub", subscribeFn)
the problem is that, the subscribeFn is was translated into 2 different functions.
If I debug the js code and check what's happening under amplify.js lib, then I get the following:
//this is what has been saved when I created a subscription
subscriptions[ topic ][ i ].callback
(L){return i.subscribeFn(L);}
.
//this is what was passed as a callback for the unsubscribe function
callback
(S){return i.subscribeFn(S);}
There is no difference in the logic, but the args are different and because of that I'm unable to unsubscribe.
WebSharper 3 can't optimize calls to module functions as a function value (which are represented in the quotation as a lambda), so it becomes a new function on every call site.
A solution is to capture the module function as a local function value:
let subscribeFn = fun (o: obj) -> subscribeFn o
(WebSharper 4 beta already has this optimization.)
Related
I tried to understand difference between sinon library's fake, spy, stub and mock but not able to understand it clearly.
Can anybody help me to understand about it?
Just for understanding purpose call:
FuncInfoCollector = is a Function that records arguments, return value, the value of this(context) and exception thrown (if any) for all of its calls.
(this FuncInfoCollector is dummy name given by me, it is not present in SINON lib)
Fake = FuncInfoCollector + can only create a fake function. To replace a function that already exists in the system under test you call sinon.replace(target, fieldname, fake). You can wrap an existing function like this:
const org = foo.someMethod;
sinon.fake((...args) => org(...args));
A fake is immutable: once created, the behavior can't be changed.
var fakeFunc = sinon.fake.returns('foo');
fakeFunc();
// have call count of fakeFunc ( It will show 1 here)
fakeFunc.callCount;
Spy = FuncInfoCollector + can create new function + It can wrap a function that already exists in the system under test.
Spy is a good choice whenever the goal of a test is to verify something happened.
// Can be passed as a callback to async func to verify whether callback is called or not?
const spyFunc = sinon.spy();
// Creates spy for ajax method of jQuery lib
sinon.spy(jQuery, "ajax");
// will tell whether jQuery.ajax method called exactly once or not
jQuery.ajax.calledOnce
Stub = spy + it stubs the original function ( can be used to change behaviour of original function).
var err = new Error('Ajax Error');
// So whenever jQuery.ajax method is called in a code it throws this Error
sinon.stub(jQuery, "ajax").throws(err)
// Here we are writing assert to check where jQuery.ajax is throwing an Error or not
sinon.assert.threw(jQuery.ajax(), err);
Mock = Stub + pre-programmed expectations.
var mk = sinon.mock(jQuery)
// Should be called atleast 2 time and almost 5 times
mk.expects("ajax").atLeast(2).atMost(5);
// It throws the following exception when called ( assert used above is not needed now )
mk.expects("ajax").throws(new Error('Ajax Error'))
// will check whether all above expectations are met or not, hence assertions aren't needed
mk.verify();
Please have a look at this link also sinon.replace vs sinon.stub just to replace return value?
Just to add some more info to the otherwise good answer, we added the Fake API to Sinon because of shortcomings of the other original APIs (Stub and Spy). The fact that these APIs are chainable led to constant design issues and recurring user-problems and they were bloated to cater to quite unimportant use cases, which is why we opted for creating a new immutable API that would be simpler to use, less ambiguous and cheaper to maintain. It was built on top of the Spy and Stub Apis to let Fakes be somewhat recognizable and have explicit method for replacing props on objects (sinon.replace(obj,'prop',fake)).
Fakes can essentially be used anywhere a stub or spy can be used and so I have not used the old APIs myself in 3-4 years, as code using the more limited fakes is simpler to understand for other people.
My first time writing a js library. The library is intended to execute, at specific times, functions in the file that required the library. Kind of like Angular executes user implemented hooks such as $onInit, except that, in my case, user can define an arbitrary number of functions to be called by my library. How can I implement that?
One way I have in mind is to define a registerFunction(name, function) method, which maps function names to implementations. But can user just give me an array of names and I automatically register the corresponding functions for them?
Unless you have a specific requirement that it do so, your module does not need to know the names of the functions it is provided. When your module invokes those functions, it will do so by acting on direct references to them rather than by using their names.
For example:
// my-module.js
module.exports = function callMyFunctions( functionList ) {
functionList.forEach( fn => fn() )
}
// main application
const myFunc1 = () => console.log('Function 1 executing')
const myFunc2 = () => console.log('Function 2 executing')
const moduleThatInvokesMyFunctions = require('./my-module.js')
// instruct the module to invoke my 2 cool functions
moduleThatInvokesMyFunctions([ myFunc1, myFunc2 ])
//> Function 1 executing
//> Function 2 executing
See that the caller provides direct function references to the module, which the module then uses -- without caring or even knowing what those functions are called. (Yes, you can obtain their names by inspecting the function references, but why bother?)
If you want a more in-depth answer or explanation, it would help to know more about your situation. What environment does your library target: browsers? nodejs? Electron? react-native?
The library is intended to execute, at specific times, functions in the file that required the library
The "at specific times" suggests to me something that is loosely event-based. So, depending on what platform you're targeting, you could actually use a real EventEmitter. In that case, you'd invent unique names for each of the times that a function should be invoked, and your module would then export a singleton emitter. Callers would then assign event handlers for each of the events they care about. For callers, that might look like this:
const lifecycleManager = require('./your-module.js')
lifecycleManager.on( 'boot', myBootHandler )
lifecycleManager.on( 'config-available', myConfigHandler )
// etc.
A cruder way to handle this would be for callers to provide a dictionary of functions:
const orchestrateJobs = require('./your-module.js')
orchestrateJobs({
'boot': myBootHandler,
'config-available': myConfigHandler
})
If you're not comfortable working with EventEmitters, this may be appealing. But going this route requires that you consider how to support other scenarios like callers wanting to remove a function, and late registration.
Quick sketch showing how to use apply with each function:
// my-module.js
module.exports = function callMyFunctions( functionList ) {
functionList.forEach( fn => fn.apply( thisValue, arrayOfArguments ) )
}
Note that this module still has no idea what names the caller has assigned to these functions. Within this scope, each routine bears the moniker "fn."
I get the sense you have some misconceptions about how execution works, and that's led you to believe that the parts of the program need to know the names of other parts of the program. But that's not how continuation-passing style works.
Since you're firing caller functions based on specific times, it's possible the event model might be a good fit. Here's a sketch of what that might look like:
// caller
const AlarmClock = require('./your-module.js')
function doRoosterCall( exactTime ) {
console.log('I am a rooster! Cock-a-doodle-doo!')
}
function soundCarHorn( exactTime ) {
console.log('Honk! Honk!')
}
AlarmClock.on('sunrise', doRoosterCall)
AlarmClock.on('leave-for-work', soundCarHorn)
// etc
To accomplish that, you might do something like...
// your-module.js
const EventEmitter = require('events')
const singletonClock = new EventEmitter()
function checkForEvents() {
const currentTime = new Date()
// check for sunrise, which we'll define as 6:00am +/- 10 seconds
if(nowIs('6:00am', 10 * 1000)) {
singletonClock.emit('sunrise', currentTime)
}
// check for "leave-for-work": 8:30am +/- 1 minute
if(nowIs('8:30am', 60 * 1000)) {
singletonClock.emit('leave-for-work', currentTime)
}
}
setInterval( checkForEvents, 1000 )
module.exports = singletonClock
(nowIs is some handwaving for time-comparisons. When doing cron-like work, you should assume your heartbeat function will almost never be fired when the time value is an exact match, and so you'll need something to provide "close enough" comparisons. I didn't provide an impl because (1) it seems like a peripheral concern here, and (2) I'm sure Momentjs, date-fns, or some other package provides something great so you won't need to implement it yourself.
I have problems attempting to test a piece of code that is similar to the following function.
Basically the question boils down to: is it possible to change the Scheduler for the debounce operator without passing a separate Scheduler to the function call?
The following example should explain the use case a bit more concrete. I am trying to test a piece of code similar to the following. I want to test the chain in the function (using a TestScheduler) without having to pass a scheduler to the debounce() operator.
// Production code
function asyncFunctionToTest(subject) {
subject
.tap((v) => console.log(`Tapping: ${v}`))
.debounce(1000)
.subscribe((v) => {
// Here it would call ReactComponent.setState()
console.log(`onNext: ${v}`)
});
}
The test file would contain the following code to invoke the function and make sure the subject emits the values.
// Testfile
const testScheduler = new Rx.TestScheduler();
const subject = new Rx.Subject();
asyncFunctionToTest(subject);
testScheduler.schedule(200, () => subject.onNext('First'));
testScheduler.schedule(400, () => subject.onNext('Second'))
testScheduler.advanceTo(1000);
The test code above still takes one actual second to do the debounce. The only solution i have found is to pass the TestScheduler into the function and passing it to the debounce(1000, testScheduler) method. This will make the debounce operator use the test scheduler.
My initial idea was to use observeOn or subscribeOn to change the defaultScheduler that is used throughout the operation chain by changing
asyncFunctionToTest(subject);
to be something like asyncFunctionToTest(subject.observeOn(testScheduler)); or asyncFunctionToTest(subject.subscribeOn(testScheduler));
that does not give me the result as i expected, however i presume i might not exactly understand the way the observeOn and subscribeOn operators work. (I guesstimate now that when using these operators it changes the schedulers the whole operation chain is run on, but operators still pick their own schedulers, unless specifically passed?)
The following JSBin contains the runnable example where i passed in the scheduler. http://jsbin.com/kiciwiyowe/1/edit?js,console
No not really, unless you actually patched the RxJS library. I know this was brought up recently as an issue and there may be support for say, being able to change what the DefaultScheduler at some point in the future, but at this time it can't be reliably done.
Is there any reason why you can't include the scheduler? All the operators that accept Schedulers already do so optionally and have sensible defaults so it really costs you nothing given that you production code could simply ignore the parameter.
As a more general aside to why simply adding observeOn or subscribeOn doesn't fix it is that both of those operators really only affect how events are propagated after they have been received by that operator.
For instance you could implement observeOn by doing the following:
Rx.Observable.prototype.observeOn = (scheduler) => {
var source = this;
return Rx.Observable.create((observer) => {
source.subscribe(x =>
{
//Reschedule this for a later propagation
scheduler.schedule(x,
(s, state) => observer.onNext(state));
},
//Errors get forwarded immediately
e => observer.onError(e),
//Delay completion
() => scheduler.schedule(null, () => observer.onCompleted()))
});
};
All the above is doing is rescheduling the incoming events, if operators down stream or upstream have other delays this operator has no effect on them. subscribeOn has a similar behavior except that it reschedules the subscription not the events.
Preface:
in order to have clean and effective code, i want to use external functions in my mapreduce mongo script.
Problem:
given we have following map function (coffeescript syntax):
map: ->
key = foo(#field)
emit(key, value)
Calling an external function 'foo' raise an error
➜ rake mongo:mapreduce
MongoDB shell version: 2.0.5
connecting to: localhost:27017/connect_development
{
"assertion" : "map invoke failed: JS Error: ReferenceError: foo is not defined nofile_b:2",
"assertionCode" : 9014,
"errmsg" : "db assertion failure",
"ok" : 0
}
The same we will return for reduce context call.
Bad smell decision - self-called anonymous function:
map: ->
key = ( (field)->
# some business logic
)(#field)
emit(key, value)
Self-called anonymous function could be very big and not effective to test and may cause leaking memory (not sure on this).
How to resolve this problem?
UPD:
When i said "external function", meant function declared in same file (in same class) with "map/reduce" functions. Of Course, it's invoked on server-side.
Map/reduce functions must run on the db servers, in another context, so they can't touch anything "external".
There is nothing wrong with using anonymous functions inline, they are extremely cheap - just avoid deep recursion. CoffeeScript has syntax for creating closures which you might want to use:
map: ->
key = do =>
k = #field.doSomething()
return k
emit key, value
Map/Reduce code executes on the MongoDB servers. You do have the option of storing functions server-side that can be called from Map/Reduce, but best practice suggests keeping functions with the rest of your code in version control. Anonymous functions are commonly used in JavaScript and should not be an issue.
I noticed the following pattern in socket.io-node:
// e.g. 1
socket.volatile.emit('bieber tweet', tweet);
// e.g. 2
socket.broadcast.json.send({ a: 'message' });
more generally, it seems to be of the style:
someObject.functionFlagA.functionFlagB.functionFlagEtc.someFunction(/* etc */);
What is this pattern called, where you add flags which may affect the execution of a function, in a chain of accessors which each return the target function (with any other available/appropriate chainable accessors)? When is it appropriate over, say, just passing some parameters to a function?
Looking at it gave me the idea of creating a sync object for my HTML5 web app like so:
// Saves someObj to localStorage AND to server-maintained session
sync.toLocalStorage.toServer.save(someObj);
...since it would be more self-documenting than:
// Saves someObj to localStorage AND to server-maintained session
sync.save(someObj, true, false, true);
Is this an appropriate use of above pattern?
EDIT 2011-12-06 13:06:15
For the curious, this is how socket.io implements it:
Socket.prototype.__defineGetter__('volatile', function () {
this.flags.volatile = true;
return this;
});
Which is used in chain to ultimately call the following internal function which sends a packet and clears the flags:
Socket.prototype.packet = function (packet) {
/* snip */
this.setFlags(); // clears this.flags
return this;
};
I would call it an example of a fluent interface.
From the Wikipedia article:
In software engineering, a fluent interface (as first coined by Eric
Evans and Martin Fowler) is an implementation of an object oriented
API that aims to provide for more readable code. A fluent interface is
normally implemented by using method chaining to relay the instruction
context of a subsequent call.
Of course in your example you have properties instead of methods. But looking at the socket.io-node code, the 'properties' are programmed as __defineGetter__ so you might as well say they are methods.
With regards to your sync object for HTML5: think about the state of the sync object after calling save. Is it reset to its original state or does it remember the configuration? What happens if you call save twice in a row?
If it's just about readability, you can also have callers pass in the configuration like so:
sync.save(someObj, { toLocalStorage: true, toServer: true });