I have a class in which i use strategy pattern it looks something like this:
class Foo {
constructor() {
this.doStuff = function() { /* not used really */ }
}
create(config) {
this.type = config.type;
// assign other variables to this
this.doStuff = StuffStrategy(config.type);
this.doStuff();
}
}
StuffStrategy is a function that returns other functions which use this context differently based on type.
function StuffStrategy(type) {
switch(type) {
case A: return StrategyA;
case B: return StrategyB;
// ...
}
}
function StrategyA() {
if(this.someVarInFoo) {
return 'a thing'
} else
return 'a different thing' + this.otherVarInFoo
}
I assign particular Strategy function inside create method.
Then I would like to test the create method if it calls doStuff.
describe('how create method works', () => {
const instance = new Foo();
const spy = jest.spyOn(instance, 'doStuff');
instance.create(config);
expect(spy).toBeCalled();
});
But when I try to make spy before calling instance.create then it refers to default method assigned in constructor, which gets replaced inside create.
If i make spy after calling instance.create then it will not pick the call
.
I tried to add .bind when defining this.doStuff:
this.doStuff = StuffStrategy(config.type).bind(this);
but it does not work either.
Is there something wrong with my setup?
How can I make this test case work?
You have to spyOn the strategy methods of your Foo class. So for every config.type you check then which strategy method has been called.
export class Foo {
constructor(){
this.doStuff = null;
}
create(config){
this.type = config.type;
// assign other variables to this
this.doStuff = StuffStrategy(config.type);
this.doStuff();
}
strategyA(){...}
strategyB(){...}
StuffStrategy(configtype) {
switch (configtype) {
case "A": return this.strategyA;
case "B": return this.strategyB;
}
}
}
import { Foo } from 'anyPlaceFoo/foo';
describe('Strategy', () => {
it('should call strategy A', () => {
const foo = new Foo();
// here you can spy on every strategy method.
jest.spyOn(foo, 'strategyA');
jest.spyOn(foo, 'strategyB');
foo.create({ type: 'A' });
// check if the selected one has been called but not the others
expect(foo.strategyA).toHaveBeenCalled();
expect(foo.strategyB).not.toHaveBeenCalled();
})
})
I'd like to replicate the behavior of React Context in Nodejs but I'm struggling with it.
In React, by creating only one context, I can provide and consume different values in my components, depending on the value given to the <Provider/>. So the following works:
const MyContext = React.createContext(0);
const MyConsumer = () => {
return (
<MyContext.Consumer>
{value => {
return <div>{value}</div>
}}
</MyContext.Consumer>
)
}
const App = () =>
<React.Fragment>
<MyContext.Provider value={1}>
<MyConsumer/>
</MyContext.Provider>
<MyContext.Provider value={2}>
<MyConsumer/>
</MyContext.Provider>
</React.Fragment>;
ReactDOM.render(
<App/>,
document.getElementById("react")
);
<script src="https://cdnjs.cloudflare.com/ajax/libs/react/16.6.3/umd/react.production.min.js"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/react-dom/16.6.3/umd/react-dom.production.min.js"></script>
<div id="react"></div>
However I have no idea how to implement this in Nodejs. I've taken a look at the source code of React Context but it does not help much... Here is what I got so far:
// context.js
export const createContext = (defaultValue: number) => {
const context = {
value: defaultValue,
withContext: null,
useContext: null,
};
function withContext(value: number, callback: (...args: any[]) => any) {
context.value = value;
return callback;
}
function useContext() {
return context;
}
context.withContext = withContext;
context.useContext = useContext;
return context;
};
// functions.js
import { context } from "./index";
export function a() {
const result = context.useContext();
console.log(result);
}
export function b() {
const result = context.useContext();
console.log(result);
}
// index.js
import { createContext } from "./context";
import { a, b } from "./functions";
export const context = createContext(0);
const foo = context.withContext(1, a);
const bar = context.withContext(2, b);
console.log("foo", foo());
console.log("bar", bar());
Obviously, value is overwritten and 2 is logged twice.
Any help will be much appreciated!
2022 update
NodeJS is proposing a new built-in for doing exactly that: Asynchronous context tracking.
Thanks to #Emmanuel Meric de Bellefon for pointing this out.
Defining the desired behavior
If you only need it for synchronous code, you could do something relatively simple. All you need is to specify where the boundaries are.
In React, you do this with JSX
<Context.Provider value={2}>
<MyComponent />
</Context.Provider>
In this example, the value of Context will be 2 for MyComponent but outside of the bounds of <Context.Provider> it will be whatever the value was before that.
If I were to translate that in vanilla JS, I would probably want it to look something like this:
const myFunctionWithContext = context.provider(2, myFunction)
myFunctionWithContext('an argument')
In this example, I would expect the value of context to be 2 within myFunction but outside of the bounds of context.provider() it would be whatever value was set before.
How to work the problem
At its most basic, this could be solved by a global object
// we define a "context"
globalThis.context = 'initial value'
function a() {
// we can access the context
const currentValue = globalThis.context
console.log(`context value in a: ${currentValue}`)
// we can modify the context for the "children"
globalThis.context = 'value from a'
b()
// we undo the modification to restore the context
globalThis.context = currentValue
}
function b() {
console.log(`context value in b: ${globalThis.context}`)
}
a()
Now we know that it's never wise to pollute the global scope globalThis or window. So we could use a Symbol instead, to make sure there can't be any naming conflict:
const context = Symbol()
globalThis[context] = 'initial value'
function a() {
console.log(`context value in a: ${globalThis[context]}`)
}
a()
However, even though this solution will never cause a conflict with the global scope, it's still not ideal, and doesn't scale well for multiple contexts. So let's make a "context factory" module:
// in createContext.js
const contextMap = new Map() // all of the declared contexts, one per `createContext` call
/* export default */ function createContext(value) {
const key = Symbol('context') // even though we name them the same, Symbols can never conflict
contextMap.set(key, value)
function provider(value, callback) {
const old = contextMap.get(key)
contextMap.set(key, value)
callback()
contextMap.set(key, old)
}
function consumer() {
return contextMap.get(key)
}
return {
provider,
consumer,
}
}
// in index.js
const contextOne = createContext('initial value')
const contextTwo = createContext('other context') // we can create multiple contexts without conflicts
function a() {
console.log(`value in a: ${contextOne.consumer()}`)
contextOne.provider('value from a', b)
console.log(`value in a: ${contextOne.consumer()}`)
}
function b() {
console.log(`value in b: ${contextOne.consumer()}`)
console.log(`value in b: ${contextTwo.consumer()}`)
}
a()
Now, as long as you're only using this for synchronous code, this works by simply overriding a value before a callback and reseting it after (in provider).
Solution for synchronous code
If you want to structure your code like you would in react, here's what it would look like with a few separate modules:
// in createContext.js
const contextMap = new Map()
/* export default */ function createContext(value) {
const key = Symbol('context')
contextMap.set(key, value)
return {
provider(value, callback) {
const old = contextMap.get(key)
contextMap.set(key, value)
callback()
contextMap.set(key, old)
},
consumer() {
return contextMap.get(key)
}
}
}
// in myContext.js
/* import createContext from './createContext.js' */
const myContext = createContext('initial value')
/* export */ const provider = myContext.provider
/* export */ const consumer = myContext.consumer
// in a.js
/* import { provider, consumer } from './myContext.js' */
/* import b from './b.js' */
/* export default */ function a() {
console.log(`value in a: ${consumer()}`)
provider('value from a', b)
console.log(`value in a: ${consumer()}`)
}
// in b.js
/* import { consumer } from './myContext.js' */
/* export default */ function b() {
console.log(`value in b: ${consumer()}`)
}
// in index.js
/* import a from './a.js' */
a()
Going further: the problem of asynchronous code
The solution proposed above would not work if b() was an async function, because as soon as b returns, the context value is reset to its value in a() (that's how provider works). For example:
const contextMap = new Map()
function createContext(value) {
const key = Symbol('context')
contextMap.set(key, value)
function provider(value, callback) {
const old = contextMap.get(key)
contextMap.set(key, value)
callback()
contextMap.set(key, old)
}
function consumer() {
return contextMap.get(key)
}
return {
provider,
consumer
}
}
const { provider, consumer } = createContext('initial value')
function a() {
console.log(`value in a: ${consumer()}`)
provider('value from a', b)
console.log(`value in a: ${consumer()}`)
}
async function b() {
await new Promise(resolve => setTimeout(resolve, 1000))
console.log(`value in b: ${consumer()}`) // we want this to log 'value from a', but it logs 'initial value'
}
a()
So far, I don't really see how to manage the issue of async functions properly, but I bet it could be done with the use of Symbol, this and Proxy.
Using this to pass context
While developing a solution for synchronous code, we've seen that we can "afford" to add properties to an object that "isn't ours" as long as we're using Symbol keys to do so (like we did on globalThis in the first example). We also know that functions are always called with an implicit this argument that is either
the global scope (globalThis),
the parent scope (when calling obj.func(), within func, this will be obj)
an arbitrary scope object (when using .bind, .call or .apply)
in some cases, an arbitrary primitive value (only possible in strict mode)
In addition, javascript lets us define a Proxy to be the interface between an object and whatever script uses that object. Within a Proxy we can define a set of traps that will each handle a specific way in which our object is used. The one that is interesting for our issue is apply which traps function calls and gives us access to the this that the function will be called with.
Knowing this, we can "augment" the this of our function called with a context provider context.provider(value, myFunction) with a Symbol referring to our context:
{
apply: (target, thisArg = {}, argumentsList) => {
const scope = Object.assign({}, thisArg, {[id]: key}) // augment `this`
return Reflect.apply(target, scope, argumentsList) // call function
}
}
Reflect will call the function target with this set to scope and the arguments from argumentsList
As long as what we "store" in this allows us to get the "current" value of the scope (the value where context.provider() was called) then we should be able to access this value from within myFunction and we don't need to set/reset a unique object like we did for the synchronous solution.
First async solution: shallow context
Putting it all together, here's an initial attempt at a asynchronous solution for a react-like context. However, unlike with the prototype chain, this is not inherited automatically when a function is called from within another function. Because of this the context in the following solution only survives 1 level of function calls:
function createContext(initial) {
const id = Symbol()
function provider(value, callback) {
return new Proxy(callback, {
apply: (target, thisArg, argumentsList) => {
const scope = Object.assign({}, thisArg, {[id]: value})
return Reflect.apply(target, scope, argumentsList)
}
})
}
function consumer(scope = {}) {
return id in scope ? scope[id] : initial
}
return {
provider,
consumer,
}
}
const myContext = createContext('initial value')
function a() {
console.log(`value in a: ${myContext.consumer(this)}`)
const bWithContext = myContext.provider('value from a', b)
bWithContext()
const cWithContext = myContext.provider('value from a', c)
cWithContext()
console.log(`value in a: ${myContext.consumer(this)}`)
}
function b() {
console.log(`value in b: ${myContext.consumer(this)}`)
}
async function c() {
await new Promise(resolve => setTimeout(resolve, 200))
console.log(`value in c: ${myContext.consumer(this)}`) // works in async!
b() // logs 'initial value', should log 'value from a' (the same as "value in c")
}
a()
Second asynchronous solution: context forwarding
A potential solution for the context to survive a function call within another function call could be to have to explicitly forward the context to any function call (which could quickly become cumbersome). From the example above, c() would change to:
async function c() {
await new Promise(resolve => setTimeout(resolve, 200))
console.log(`value in c: ${myContext.consumer(this)}`)
const bWithContext = myContext.forward(this, b)
bWithContext() // logs 'value from a'
}
where myContext.forward is just a consumer to get the value and directly afterwards a provider to pass it along:
function forward(scope, callback) {
const value = consumer(scope)
return provider(value, callback)
}
Adding this to our previous solution:
function createContext(initial) {
const id = Symbol()
function provider(value, callback) {
return new Proxy(callback, {
apply: (target, thisArg, argumentsList) => {
const scope = Object.assign({}, thisArg, {[id]: value})
return Reflect.apply(target, scope, argumentsList)
}
})
}
function consumer(scope = {}) {
return id in scope ? scope[id] : initial
}
function forward(scope, callback) {
const value = consumer(scope)
return provider(value, callback)
}
return {
provider,
consumer,
forward,
}
}
const myContext = createContext('initial value')
function a() {
console.log(`value in a: ${myContext.consumer(this)}`)
const bWithContext = myContext.provider('value from a', b)
bWithContext()
const cWithContext = myContext.provider('value from a', c)
cWithContext()
console.log(`value in a: ${myContext.consumer(this)}`)
}
function b() {
console.log(`value in b: ${myContext.consumer(this)}`)
}
async function c() {
await new Promise(resolve => setTimeout(resolve, 200))
console.log(`value in c: ${myContext.consumer(this)}`)
const bWithContext = myContext.forward(this, b)
bWithContext()
}
a()
Context on async functions without explicit forwarding
Now I'm stuck... I'm open to ideas!
Your goal of "replicating React's Context in NodeJS" is slightly ambiguous. From the React docs:
Context provides a way to pass data through the component tree without having to pass props down manually at every level.
There are no component trees in NodeJS. The closest analogy that I could think of (based also on your example) was a call stack. Additionally, React's Context also causes a re-render of the tree if the value changes. I have no idea what that would mean in NodeJS, so I'll happily ignore this aspect.
Thus I will assume that you are essentially looking for a way to make a value accessible anywhere in the call stack without having to pass it down the stack as an argument from function to function.
I propose you use one of the so-called continuation-local storage libs for NodeJS to achieve this. They use a pattern that is a little different from what you were trying to do, but it might be just fine.
My favourite has been CLS Hooked (no affiliation). It taps into NodeJS's async_hooks system to preserve the provided context even if there are asynchronous calls in the stack. Last published 4 years ago it still works as expected.
I rewrote your example using CLS Hooked, although I'd argue that it's not the nicest / most intuitive way to use it. I also added an extra function call to demonstrate that it's possible to override values (i.e. create sort of child contexts). Finally, there's one noticeable difference - the context must now have an ID. If you wish to stick with this React Contexty pattern, you'll probably have to make peace with it.
// context.js
import cls from "cls-hooked";
export const createContext = (contextID, defaultValue) => {
const ns = cls.createNamespace(contextID);
return {
provide(value, callback) {
return () =>
ns.run(() => {
ns.set("value", value);
callback();
});
},
useContext() {
return ns.active ? ns.get("value") : defaultValue;
}
};
};
// my-context.js
// your example had a circular dependency problem
// the context has to be created in a separate file
import { createContext } from "./context";
export const context = createContext("my-context", 0);
// zz.js
import { context } from "./my-context";
export const zz = function () {
console.log("zz", context.useContext());
};
// functions.js
import { context } from "./my-context";
import { zz } from "./zz";
export const a = function () {
const zzz = context.provide("AAA", zz);
zzz();
const result = context.useContext();
console.log("a", result);
};
export const b = function () {
const zzz = context.provide("BBB", zz);
zzz();
const result = context.useContext();
console.log("b", result);
};
// index.js
import { context } from "./c";
import { a, b } from "./functions";
const foo = context.provide(1, a);
const bar = context.provide(2, b);
console.log("default value", context.useContext());
foo();
bar();
Running node index logs:
default value 0
zz AAA
a 1
zz BBB
b 2
This would also work if there were all sorts of asynchronous calls happening in your stack.
How I use it
My approach is a little different. I wasn't trying to replicate React's Context, which also has a limitation in that it is always bound to a single value.
// cls.ts
import cls from "cls-hooked";
export class CLS {
constructor(private readonly NS_ID: string) {}
run<T>(op: () => T): T {
return (cls.getNamespace(this.NS_ID) || cls.createNamespace(this.NS_ID)).runAndReturn(op);
}
set<T>(key: string, value: T): T {
const ns = cls.getNamespace(this.NS_ID);
if (ns && ns.active) {
return ns.set(key, value);
}
}
get(key: string): any {
const ns = cls.getNamespace(this.NS_ID);
if (ns && ns.active) {
return ns.get(key);
}
}
}
// operations-cls.ts
import { CLS } from "./cls";
export const operationsCLS = new CLS("operations");
// consumer.ts
import { operationsCLS } from "./operations-cls";
export const consumer = () => {
console.log(operationsCLS.get("some-value")); // logs 123
};
// app.ts
import { operationsCLS } from "./operations-cls";
import { consumer } from "./consumer";
cls.run(async () => {
cls.set("some-value", 123);
consumer();
});
How CLS works
I prefer to view CLS as magic, as it's always worked fine without my intervention, so can't comment much here, sorry :]
I've got a Function that I want to be able to call in 2 ways - and it should behave the same.
Is there any ES6 syntax that will allow me to call the function doBar below using both ways with the same result?
Consider a function like this:
const doBar = ({ foo = 'bar' }) => {
console.log(foo) // should log 'baz'
}
I'm using a framework that binds events like so:
<x-component on-some-event="doBar"></x-component>
which will essentially cause an invocation like so:
// where e = { detail: { foo: 'baz' } }
doBar(e)
.. but I'd like to be able to both call my Function explicitly as well, albeit with a proper call signature like so:
doBar({ foo: 'baz' })
You can use a default parameter. If foo is not found, it will use the value of detail.foo.
const doBar = ({ detail = {}, foo = detail.foo }) => {
console.log(foo) // should log 'baz'
}
doBar({ foo: 'baz' })
doBar({
detail: {
foo: 'baz'
}
});
You can't do this properly in the parameter declaration. Just put your destructuring assignment in the function body:
function doBar(e) {
const { foo = "bar", qux } = e.detail || e;
consoel.log(foo, qux);
}
I'd like to be able to both call my function explicitly as well
I would recommend to not do that. A function should have one signature only and not be overloaded to different types of arguments. Just be explicit about when to use what:
function doBar({ foo = "bar", qux }) {
console.log(foo);
}
function withDetail(fn) {
return e => fn(e.detail)
}
<x-component on-some-event="withDetail(doBar)"></x-component>
doBar({ foo: 'baz' })
No. Not unless you consider this to be an adequate alternative:
const thing = {
detail: {
foo: 'baz'
}
};
doBar(thing.detail);
I want to keep this in class methods.
I can use arrow functions, but I want to override some methods in extended class.
Now I have this solution and it works:
class Foo {
bar = "Context preserved.";
constructor() {
this.foo = this.foo.bind(this);
}
foo() {
alert(this.bar);
}
}
class Foo2 extends Foo {
foo() {
alert(this.bar + " Class extended");
}
}
class Bar {
bar = "Context lost.";
}
let foo = new Foo2();
let bar = new Bar();
foo.foo.apply(bar); // Context preserved. Class extended
Is it a good practice to do it such way? If it is, is there some keyword in typescript to do it automatically?
like
class Foo() {
public conserved foo() { }
}
which generates:
var Foo = (function () {
function Foo() {
this.foo = this.foo.bind(this);
}
Foo.prototype.foo = function () { };
return Foo;
}());
It's a valid practice and it's being used.
I'm unaware of a way to tell typescript to do this automatically, but you can search the issues for something like it.
You can have a decorator that does that for you, for example:
function construct(constructor: Function, methods: string[], args: any[]) {
var c: any = function () {
return constructor.apply(this, args);
}
c.prototype = constructor.prototype;
let instance = new c();
methods.forEach(name => {
instance[name] = instance[name].bind(instance);
});
return instance;
}
function BindMethods(constructor: Function) {
const methods = [] as string[];
Object.keys(constructor.prototype).forEach(name => {
if (typeof constructor.prototype[name] === "function") {
methods.push(name);
}
});
return (...args: any[]) => {
return construct(constructor, methods, args);
};
}
#BindMethods
class Foo {
bar = "Context preserved.";
foo() {
console.log(this.bar);
}
}
let foo = new Foo();
setTimeout(foo.foo, 10);
(code in playground)
I tested it with this simple use case and it worked just fine.
I have read "How to implement a typescript decorator?" and multiple sources but there is something that i have nor been able to do with decorators.
class FooBar {
public foo(arg): void {
console.log(this);
this.bar(arg);
}
private bar(arg) : void {
console.log(this, "bar", arg);
}
}
If we invoke the function foo:
var foobar = new FooBar();
foobar.foo("test");
The object FooBar is logged in the console by console.log(this); in foo
The string "FooBar {foo: function, bar: function} bar test" is logged in the console by console.log(this, "bar", arg); in bar.
Now let's use a decorator:
function log(target: Function, key: string, value: any) {
return {
value: (...args: any[]) => {
var a = args.map(a => JSON.stringify(a)).join();
var result = value.value.apply(this, args); // How to avoid hard coded this?
var r = JSON.stringify(result);
console.log(`Call: ${key}(${a}) => ${r}`);
return result;
}
};
}
We use the same function but decorated:
class FooBar {
#log
public foo(arg): void {
console.log(this);
this.bar(arg);
}
#log
private bar(arg) : void {
console.log(this, "bar", arg);
}
}
And we invoke foo as we did before:
var foobarFoo = new FooBar();
foobarFooBar.foo("test");
The objectWindow is logged in the console by console.log(this); in foo
And bar is never invoked by foo because this.bar(arg); causes Uncaught TypeError: this.bar is not a function.
The problem is the hardcoded this inside the log decorator:
value.value.apply(this, args);
How can I conserve the original this value?
Don't use an arrow function. Use a function expression:
function log(target: Object, key: string, value: any) {
return {
value: function(...args: any[]) {
var a = args.map(a => JSON.stringify(a)).join();
var result = value.value.apply(this, args);
var r = JSON.stringify(result);
console.log(`Call: ${key}(${a}) => ${r}`);
return result;
}
};
}
That way it will use the function's this context instead of the value of this when log is called.
By the way, I would recommend editing the descriptor/value parameter and return that instead of overwriting it by returning a new descriptor. That way you keep the properties currently in the descriptor and won't overwrite what another decorator might have done to the descriptor:
function log(target: Object, key: string, descriptor: TypedPropertyDescriptor<any>) {
var originalMethod = descriptor.value;
descriptor.value = function(...args: any[]) {
var a = args.map(a => JSON.stringify(a)).join();
var result = originalMethod.apply(this, args);
var r = JSON.stringify(result);
console.log(`Call: ${key}(${a}) => ${r}`);
return result;
};
return descriptor;
}
More details in this answer - See the "Bad vs Good" example under "Example - Without Arguments > Notes"
I believe you can use
var self = this;
in order to preserve the 'this' at that specific point. Then, just use self at the later point where you would have wanted that particular this