{"id":2368,"date":"2014-11-01T14:42:40","date_gmt":"2014-11-01T14:42:40","guid":{"rendered":"http:\/\/www.garysieling.com\/blog\/?p=2368"},"modified":"2014-11-01T14:42:40","modified_gmt":"2014-11-01T14:42:40","slug":"trace-logging-react","status":"publish","type":"post","link":"https:\/\/www.garysieling.com\/blog\/trace-logging-react\/","title":{"rendered":"Trace Logging with React"},"content":{"rendered":"

Long ago, when I was a Delphi (Pascal) programmer, I encountered a neat language feature called properties<\/a>, which are awesome for debugging (and more well known now, as they are in C#). <\/p>\n

\n  Property Area   : Longint read fArea;\n  Property Left   : Longint Index 0 read GetCoord write SetCoord;\n<\/pre>\n
Properties are accessed with the same syntax as a class-level variable. The consequence of this is that you can turn any variable into a property by adding three or four lines of code, which gives you a chokepoint where you can put a breakpoint to find out whenever that variable is set, which can be pretty awesome for understanding how an application works. I found this taught me to visualize an application as a plumbing problem: data goes from point A to point B, and all you need to do to fix a defect is figure out where it stops or gets mangled.<\/p>\n
In the new world of React programming, we’re taught to treat a UI code as simply a mapping from state to DOM objects, which is similarly freeing (although without the rigidity that XSLT imposed). <\/p>\n
If you use JSX, you can write composable components that are pretty easy to read (this is rendering a proposal editor):<\/p>\n
\nreturn (\n  \n    
\n      <\/PickList>\n    <\/div>\n    \n      \n        {sections}\n      <\/Accordion>\n      
\n        \n        <\/PickList>\n        \n      <\/div>\n    <\/Accordion>\n  );\n<\/pre>\n
All the state that controls the UI is passed in. <\/p>\n
This design causes one or more large top-level objects. I split these into three classes of state: the ‘input’ data model (things from the database), the ‘output’ data model (what the end user thinks they picked), and transient UI state (which text box is focused, which tabs are open, etc).<\/p>\n
The top level state object exposes event handlers which correspond to things a user does:<\/p>\n
\nvar events = {\n  selectProposal: function (proposal, event, id) {\n    data.ui.sectionIndex = 0;\n    data.ui.selectedSections = proposal.sections;\n\n    page.setState(data);\n  }\n...\n}\n<\/pre>\n
Most of these event handlers look almost the same (using cursors<\/a> may be eventually a helpful simplification).<\/p>\n
In essence, we’ve replicated the “property” functionality that C# and Delphi have, which some fun results.<\/p>\n
We can trivially write a function which takes the above events list and wraps each event in logging code:<\/p>\n
\nfunction trace(events, log) {\n  return _(events).reduce(\n    function (accum, fn, key) {\n      accum[key] = _.partial(log, fn, key);\n      return accum;\n    },\n  {});\n}\n<\/pre>\n
The ‘log’ function can just write to the console output, although that can get verbose fast:<\/p>\n
\nlog.before = function (fn, key, args) {\n  console.log(key + ': ' + args.join(', '));\n}\n<\/pre>\n
Rather than logging everything, I’ve chosen to provide pre\/post event hooks – this lets you focus the log on the particular piece of state you’re interested in.<\/p>\n
\nfunction log() {\n  fn = arguments[0];\n  key = arguments[1];\n\n  var newArgs = _(arguments).slice(2);\n\n  if (!!log.before) {\n    log.before(fn, key, newArgs);\n  }\n\n  fn.apply(this, newArgs.value());\n      \n  if (!!log.after) {\n    log.after(fn, key, newArgs);\n  }\n}\n<\/pre>\n
An interesting side effect of this approach is that you can add conditional breakpoints that fire when a value is set:<\/p>\n
\nlog.after = function (fn, key, args) {\n  console.log('data.ui.accordionIndex: ' + data.ui.accordionIndex);\n\n  if (data.ui.accordionIndex === undefined) {\n    debugger;\n  }\n}\n<\/pre>\n
You can also record checkpoints of the top level state – this lets you return at any time to the point right before your error occurred:<\/p>\n
\nlog.before = function (fn, key, args) {\n  console.log('data.ui.accordionIndex: ' + data.ui.accordionIndex);\n\n  if (args[0] === undefined) {\n    checkpoints.push(_.cloneDeep(data));\n  }\n}\n<\/pre>\n
Alternately, if data became wrong earlier in the process, you could record constant snapshots, allowing you to replay everything in a test case.<\/p>\n
Overall, this style of programming is a huge improvement in working with the otherwise very chaotic nature of Javascript development.<\/p>\n","protected":false},"excerpt":{"rendered":"
Long ago, when I was a Delphi (Pascal) programmer, I encountered a neat language feature called properties, which are awesome for debugging (and more well known now, as they are in C#). Property Area : Longint read fArea; Property Left : Longint Index 0 read GetCoord write SetCoord; Properties are accessed with the same syntax … <\/p>\n
Continue reading “Trace Logging with React”<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"om_disable_all_campaigns":false,"_monsterinsights_skip_tracking":false,"footnotes":""},"categories":[4,29],"tags":[302,345,440,449,542],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t