Pass wrapped function name to mobx action #18
Conversation
This allows for simpler debugging when using mobx-logger. Without this patch mobx-task actions appear in the log as: "ACTION task.<unnamed action>". This allows the logged action to appear similar to a natively logged mobx action.
src/task.js
Outdated
| @@ -118,7 +119,7 @@ function setupTask(fn, taskState, taskStateSchemaKeys, opts) { | |||
| * Assigns the given properties to the task. | |||
| * E.g. task.setState({ state: 'resolved', result: 1337 }) | |||
| */ | |||
| setState: action(opts => { | |||
| setState: action(opts.wrappedFnName, opts => { | |||
There was a problem hiding this comment.
Rather do it here than tack it on to opts, as that would require a typings update too.
| setState: action(opts.wrappedFnName, opts => { | |
| setState: action(fn.name || 'unnamed function', opts => { |
There was a problem hiding this comment.
@jeffijoe that was my first thought as well; however, at least in my testing, fn has already been replaced with the task wrapper at the point and thus fn.name points to the task wrapper function instead of the original function that is being wrapped in the task.
I'm open to a cleaner solution as this wasn't my first preference because it is a little messy looking, but it seemed a slightly more streamlined way to get the data their without multiple new arguments being passed through the functions. And adding a const seemed inappropriate for something this minor.
Is there a way to reference the wrapped function from the wrapper function without delving into using prototypes?
There was a problem hiding this comment.
Actually, why are we even setting it on the task's setState? 😮
There was a problem hiding this comment.
To what are you referring? The first parameter of an action needs to either be the named function or a string name of the function passed as the second parameter in order to compatible with mobx-logger.
There was a problem hiding this comment.
Yes but setState is not the fn, which is where you are setting it
There was a problem hiding this comment.
Because a Task has internal state that is observable, and to update observables you need to do it in an action.
There was a problem hiding this comment.
Ahh ok - because they are being mixed. Got it. I will adjust this PR to just be the "setState" added to the action(. I will work separately on figuring out a better solution for general task capture into log.
There was a problem hiding this comment.
Changes made to PR.
There was a problem hiding this comment.
Thanks! I was hoping to implement a custom I*RunInfo with spyReportStart and spyReportEnd the same way that action implements its event record creation. Sadly, this was apparently removed from the API between MOBX 3 and 4. So guess for now this is the best that can be without getting messy.
This allows for simpler debugging when using mobx-logger. Without this patch mobx-task actions appear in the log as: "ACTION task.". This allows the logged action to appear similar to a natively logged mobx action.