Whilst debugging 4004, I realised there were some things that we should do to the logging infrastructure in the app. The main new features:
Able to post to bugsnag and RNBGL log from wocky-client code
Able to post to bugsnag and RNBGL log from any component (ie. absinthe-socket)
Depending on what we're doing, we may need to insert logging into wocky-client code OR any component that we use. Furthermore, the logging isn't just console.log()-ish logging, but should also include the ability to post to bugsnag, and to write to the RNBGL log.
I find the RNBGL log very useful because it's persisted on the device and can be retrieved by the user (and sent to the developer). Having this log (almost?) replaces the need to be able to retrieve native OS logs (ie. 'adb logcat', iOS console logs) from a device.
(However, since I've been using the RNBGL log for general purposes, it's a bit misleading to call it the RNBGL log. I've been calling it the 'debug' log (but I'm also thinking of calling it the 'persisted' log).)
Moving forward, I think more and more debug will be written to the RNBGL log. We'll be generalising it sooner or later.
(As an anecdote, my debugging for 4004 resulted in modifying code in wocky-client and absinthe-socket to post to the RNBGL log. And I intend to insert code in absinthe-socket to post to bugsnag when the error condition of 4004 is detected.)
However, implementing these new features also requires:
Able to run wocky-client and tests in nodejs ie. when bugsnag and RNBGL aren't available
so we don't break existing infrastructure.
Then ... as I was looking at the code, I also realised:
Verify/ensure that console.log()-ish logging is stubbed-out when in release mode (ie. !__DEV__). (See actionLogger. What about simpleActionLogger?)
This is already done in logger.ts but it might be insufficient. For example, actionLogger.ts and mst-middlewares.simpleActionLogger both directly call console.log().
And finally:
Tidy-up
Such as removing lots of commented out console.log() calls (which are obsolete) and DRYing up logger.ts.
My proposed solution:
Create a new class/object which can post to the console/RNBGL/bugsnag.
Inject into Wocky.ts (via environment?)
Inject into Transport.ts somehow
In nodejs environment, replace it with a version that stubs out RNBGL/bugsnag functionality.
This would allow all wocky-client code to use it.
Modify the global console object
Add a function to post to bugsnag
Add functions to post to RNBGL log
Stub out log|warn|error etc. if in release mode
This would allow any component (ie. absinthe-socket) to post to bugsnag/RNBGL, and disable console logging (in release mode) for all code in components.
bengtan
commented
4 years ago
Whilst debugging 4004, I realised there were some things that we should do to the logging infrastructure in the app. The main new features:
Depending on what we're doing, we may need to insert logging into wocky-client code OR any component that we use. Furthermore, the logging isn't just
console.log()-ish logging, but should also include the ability to post to bugsnag, and to write to the RNBGL log.I find the RNBGL log very useful because it's persisted on the device and can be retrieved by the user (and sent to the developer). Having this log (almost?) replaces the need to be able to retrieve native OS logs (ie. 'adb logcat', iOS console logs) from a device.
(However, since I've been using the RNBGL log for general purposes, it's a bit misleading to call it the RNBGL log. I've been calling it the 'debug' log (but I'm also thinking of calling it the 'persisted' log).)
Moving forward, I think more and more debug will be written to the RNBGL log. We'll be generalising it sooner or later.
(As an anecdote, my debugging for 4004 resulted in modifying code in wocky-client and absinthe-socket to post to the RNBGL log. And I intend to insert code in absinthe-socket to post to bugsnag when the error condition of 4004 is detected.)
However, implementing these new features also requires:
so we don't break existing infrastructure.
Then ... as I was looking at the code, I also realised:
console.log()-ish logging is stubbed-out when in release mode (ie.!__DEV__). (See actionLogger. What about simpleActionLogger?)This is already done in logger.ts but it might be insufficient. For example,
actionLogger.tsandmst-middlewares.simpleActionLoggerboth directly call console.log().And finally:
Such as removing lots of commented out console.log() calls (which are obsolete) and DRYing up logger.ts.
My proposed solution:
This would allow all wocky-client code to use it.
consoleobjectlog|warn|erroretc. if in release modeThis would allow any component (ie. absinthe-socket) to post to bugsnag/RNBGL, and disable
consolelogging (in release mode) for all code in components.And then: