I don't understand the reason MobX outputs this message in production build:
An invariant failed, however the error is obfuscated because this is an production build.
Does an obfuscated error bring any benefit?
bundle size. it probably means we cannot not throw, as the behavior is
undefined / different than what it would be in Dev. So it means you missed
an important code path in your dev testing. If you load the exception with
the corresponding source maps (most bug tracking tools can do this), it
should still be quite easy to figure out which one you hit by looking at
the stack.
On Tue, Feb 11, 2020 at 3:21 PM Roman notifications@github.com wrote:
I don't understand the reason MobX outputs this message in production
build:An invariant failed, however the error is obfuscated because this is an
production build.
- If this invariant is not a critical problem, just don't check it on
production.- If this invariant is critical, don't hide the error from the
user/developer. How else should one diagnose the problem?Does an obfuscated error bring any benefit?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/mobxjs/mobx/issues/2280?email_source=notifications&email_token=AAN4NBF46FBYFMRXSIUEWM3RCK665A5CNFSM4KTC2YCKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4IMS6WPQ,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAN4NBHZC3N7FO575BVL7BTRCK665ANCNFSM4KTC2YCA
.
You could essentially decide to use DEV bundle of mobx in production. I doubt it would be too much slower if you don't care about bundle size much. Most decision paths are about verbose dev checks, but it's far from React style where performance can differ vastly.
we cannot not throw, as the behavior is undefined / different than what it would be in Dev
If the bundle size is the main reason for such behavior, maybe at least show an error code to indicate which error has happened?
You could essentially decide to use DEV bundle of mobx in production.
The problem is, I will have to re-defined the "global" process.env.NODE_ENV for that. This will also influence how other modules are built, including the "react" itself. Or do I miss an option to do that for MobX only?
If the bundle size is the main reason for such behavior, maybe at least show an error code to indicate which error has happened?
Ideas / PRs are welcome :)
Possibly a stupid idea: Externalize all error texts as if they were subject to i18n.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
This issue has been automatically unmarked as stale. Please disregard previous warnings.
@mweststrate The idea from @Maaartinus might be worth including in V6, what do you think? Otherwise, close this if it's not worth the effort for now.
@FredyC good point, I'll add the same mechanism as in immer, where at least a unique code per error is preserved. Note that some errors will still not occur in production if the checks themselves are expensive at runtime.
Hi there, I'd like to add my support for this proposal as well! We are currently being hit hard by this as I am trying to debug React Native crashes that are only happening in production builds, which throw this error and not much else to go by.
An error code would be super useful, so I think that's a great idea.
For what it's worth, we aren't really concerned with bundle sizes as this is a mobile app and still in beta, so some way of running MobX in "dev mode" (without affecting the rest of our build) while we're still trying to smooth out rough edges would also be great - appreciate that that might be a bit more difficult though.
Thanks a lot! :)
In V6 error codes will be thrown instead, so this is being planned
On Fri, May 1, 2020 at 1:06 PM Harry Lachenmayer notifications@github.com
wrote:
Hi there, I'd like to add my support for this proposal as well! We are
currently being hit hard by this as I am trying to debug React Native
crashes that are only happening in production builds, which throw this
error and not much else to go by.An error code would be super useful, so I think that's a great idea.
For what it's worth, we aren't really concerned with bundle sizes as this
is a mobile app and still in beta, so some way of running MobX in "dev
mode" (without affecting the rest of our build) while we're still trying to
smooth out rough edges would also be great - appreciate that that might be
a bit more difficult though.Thanks a lot! :)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/mobxjs/mobx/issues/2280#issuecomment-622361913, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAN4NBG326PDOSFTC43BSVLRPK3L5ANCNFSM4KTC2YCA
.
Most helpful comment
In V6 error codes will be thrown instead, so this is being planned
On Fri, May 1, 2020 at 1:06 PM Harry Lachenmayer notifications@github.com
wrote: