Closed zaceno closed 4 years ago
@zaceno there is a potential alternative to making custom named methods:
const originalFunction = () => {
// this could be an action, or effect
}
const wrap = fn => {
const name = `wrapped(${fn.name})`;
const temp = {
[name]: (...args) => {
return fn(...args);
},
};
return temp[name];
}
console.log('original:', originalFunction.name); // expected "originalFunction"
console.log('wrapped:', wrap(originalFunction).name); // expected "wrapped(originalFunction)"
I haven't done a deep dive into your implementation, but you could do something like that, and we can avoid ._name
. Of course, we can just use ._name
, there wouldn't be much of a penalty to that at all.
Yeah that’s what I was thinking. There isn’t much cost to checking and giving priority to ._name. And doing so won’t break for those who go for that more involved method. I just think it makes sense to have a “designated alternative” to .name
In large apps I believe it will become common to use tools such as hyperapp-map or other ways of transforming actions before dispatching them. When we do that, typically, the .name of the action which is dispatched will be undefined or something meaningless like “map”. This would make the debugger hard (or even pointless) to use in those cases.
To amend the situation, I propose the convention that transformed actions are given a ._name property, with whatever value is appropriate (typically copy the .name of the transformed action).
Correspondingly I propose that hyperapp-debug, when detecting the name of the action dispatched, first checks for a ._name property, and prefers it to any eventual .name.