Page Comparison

...

• to check if the code is working as intended by using information/warning/error messages at appropriate places in the code. You do not need to worry about removing these messages later on. Just ensure that when you create such messages you are using the appropriate log level (log levels are explained in appropriate detail in RFC5424, PS: Wikipedia link  or RFC5424 link).
• to provide opportunity for other developers to have a standardised record of warnings/errors etc. that he/she can then share with appropriate developer(s) or with the team for analysis and resolution. This is possible by sharing the log file (and mentioning timestamp if necessary).
• to record errors generated on stable platform where no one is actually looking at the console messages. If errors are important/serious in nature, the historical record of log files can be used for analysis and resolution (IMPORTANT: Pls read comments at the end of this document).

To use the custom logger built in SWIK-835, developers should import the following in their respective code blocks (not in react components but can be used in Flux actions, platform services, routes etc). Please ensure that you are providing correct path inside require.

const cloglog = require('./log/clog');

Then in your code, you can use the custom logger as follows:

// In case of error, in the below code we are also sending metadata such as filepath and err in final log message.
cloglog.error(context, payload, {filepath: __filename, err: err});


// In case you want to send debug message
cloglog.debug(context, payload, 'This is my debug message');

Parameters

1. There are three parameters: context, payload and When using custom logger in action code, context, must be the first parameter and then you can add your own (optional) message. context and payload parameters are used to Your message can be an object or a string.
2. context is used to provide access to request id and navigation stack. Also to know the user who has sent the request.
3. message parameter Your own message can take a string or a JavaScript object. Treat this as metadata that you want to send in your log message. You can send whatever you want.

...

1. id , as it appears in log message is set in server.js. For every new request SlideWiki Platform receives, a new UUID is generated and used as request id.
2. If the developer is using (optional) message parameter for sending metadata then all of those metadata will appear in the log message after the json key message (example: message=filepath:/home/user1/Workspace/slidewiki-platform/actions/loadFeatured.js, err:TypeError: Cannot read property 'update' of undefined)
3. navStack is a sequential control flow that the request took in SlideWiki Platform. Example: navStackActions=[navigateAction, action, loadDeck, loadContentModules, loadCommentsCount] can be written as: navigateAction → action → loadDeck → loadContentModules → loadCommentsCount.

...

• For configuration: ./configs/log.js
• For production configuration copy code from ./configs/log_prod_sample.js to ./configs/log.js . This should be done in travis and docker configuration.
• Propagation of log message from developer's code to appropriate transport: ./actions/log/clog.js and ./services/logservice.js
• Log directory: ./logs   (IMPORTANT: Pls read comments at the end of this document)
• NPM package: Winston and winston-daily-rotate-file