Define action name to be as the function name

[nadavkaner]

Thanks for taking the effort to create a PR!

If you are creating an extensive PR, you might want to open an issue with your idea first, so that you don't put a lot of effort in an PR that wouldn't be accepted. Please prepend pull requests with WIP: if they are not yet finished
PR checklist:

• Added unit tests
• Updated changelog
• Updated /docs. For new functionality, at least API.md should be updated
• Added typescript typings
• Verified that there is no significant performance drop (npm run perf)

Feel free to ask help with any of these boxes!

The above process doesn't apply to doc updates etc.

[nadavkaner]

Do I need to make these changes also in v4 folder?

[danielkcz]

Do I need to make these changes also in v4 folder?

Once the v5 is polished, the v4 will be needed as well for sure.

[danielkcz]

LGTM, but perhaps add one more test where name would be created within the test as non-configurable? To avoid regressions in the future.

[nadavkaner]

How I can change functions name to be non-configurable inside the test?
I tried something like this Object.defineProperty(Function, "name", { configurable: false }), but it doesn't seems to work

[danielkcz]

I suppose you cannot make that particular property non-configurable, but let's "cheat" and use Object.seal which makes everything ... well, sealed :)

Oh, that won't work because you are creating a new object for that check every time. That's not ideal, but I cannot think of a different approach.

It could work with Object.seal(Function.prototype), but there is no way to "unseal".

[nadavkaner]

With Object.seal I can seal only specific function instance and not every function instance that being created which this is what I need in this case, am I missing something here?
It doesn't work with Object.seal(Function.prototype) either :\

[danielkcz]

You not missing anything, I haven't realized how is the check done. I suppose it would have to be enough. Complicating the code further for the sake of tests is probably not worth it.

[nadavkaner]

I agree :)

[danielkcz]

Oh, btw, next time please don't tick the box that you have updated changelog. Clearly you did not and I forgot to check. Nevermind now, I will add it there directly

[elektronik2k5]

This is awesome! BTW, why not do this in production mode too?

[danielkcz]

@elektronik2k5 That would work only if the action name is passed as a string in the first arg. Function names are usually minified. It would be inconsistent. Besides, this is intended for debugging purposes mostly.

[elektronik2k5]

@FredyC, digging a bit further into the code, I see it isn't that simple. I understand that and am not challenging it any further right now - and definitely not as part of this PR.

However, I still want to address some of your assertions and perhaps we can improve it in the future:

Function names are usually minified.

You're right: function names are usually mangled. Practically always in browsers and often in node packages which go through a build/compilation step.

However, that is not always the case:

• I always configured the minifiers in my projects to not mangle function names cause I value readable stack traces in production much more than the negligible size decrease which mangling produces. You can have minification and keep readable names thanks to gzip/brotli. And it doesn't negate all other minification tricks. :)
• Thanks to all modern browsers supporting ESM, dynamic import() hitting stage 4, HTTP >= 2 and Brotli we have things like https://www.snowpack.dev/, where we're able to go back to working like once: via <script> tags and without bundling. It is a valid approach and a breath of fresh air in light of our currently tooling-heavy workflows.
• In node, there's absolutely no need to minify anything, and we know mobx is used in node too.
• Due to the fact that every application's target environment is different and package sources are written in different languages using different standards, there's talk of reversing the current standard of shipping ES5 packages and instead:
  • Shipping different target environment bundles: ES5, ES2015 without ESM, ESM + latest. Some packages already do this and bundler support is in place.
  • Ignoring bundled package artifacts altogether and having the bundler take care of compilation, polyfilling, minification, etc of raw source code. React Native does this, for example.

It would be inconsistent.

Only if we let it be inconsistent.

this is intended for debugging purposes mostly

In my view, debugging isn't a nice to have, but a first class feature of any tool/package I consider using.