An oft-overlooked tradeoff when writing functional code in JavaScript. When learning functional programming in JavaScript, it is very tempting to write code in a as much as possible. pointfree style What is pointfree style? Writing functions in pointfree-style means you write a function without mentioning the input argument. Consider this function that takes an object representing a person, and returns the full name: fullName ( ) { [ .firstName, .middleName, .lastName].filter( => ).join(' ')} function personObject return personObject personObject personObject element element me = {firstName: 'Thai',lastName: 'P'} const fullName(me) // => 'Thai P' Notice the names, and . We needed to give names to our input variables, so that we could process them to derive a result. **_personObject_** **_element_** But do we really have to do that? What if we could create this function by piecing together smaller functions? For example, contains a bunch of utility functions that helps us do this: Ramda turns an array of property names into a function that takes an object and returns an array of values: **R.props** nameComponents = R.props(['firstName','middleName','lastName']) const nameComponents(me) // => [ 'Thai', undefined, 'P' ] takes a predicate and generates a function that can filter an array using that predicate. is equivalent to . **R.filter** **R.identity** element => element rejectEmpty = R.filter(R.identity) const rejectEmpty([ 'Thai', undefined, 'P' ]) // => [ 'Thai', 'P' ] takes a separator string, and generates a function that joins an array into into a single string with the separator in between. **R.join** unwords = R.join(' ') const unwords([ 'Thai', 'P' ]) // => 'Thai P' So, our function can be written as a pipeline consisting of these three smaller functions: **fullName** fullName = R.pipe(nameComponents,rejectEmpty,unwords) const Let’s inline them, so that when we read the definition of , we know exactly what’s going to happen: **fullName** fullName = R.pipe(R.props([ 'firstName', 'middleName', 'lastName' ]),R.filter(R.identity),R.join(' ')) const fullName(me) // => 'Thai P' As you can see, now we no longer need to make up names like and . Naming things is a hard computer science problem. Creating functions this way helps reduce the need to name things! **_personObject_** **_element_** I am only using as an example. You can also use , , or write these functions yourself. The thing is that you don’t write functions yourself, but you compose (reuse) smaller functions to create larger functions. Note: ramda lodash/fp sanctuary You’re doing pointfree style when you are partially applying functions: multiply = (a, b) => a * b const const double = multiply.bind(null, 2) or when you are calling a curried function: multiply = (a) => (b) => a * b const const double = multiply(2) Either way, you ended up with a function that’s generated by another function. But should we always use it? Short answer: Not always, as it could obfuscate the JavaScript stack trace. Read on for more explanation. An example… Let’s say we have an array of blog comments: comments = [{author: { firstName: 'Thai', lastName: 'P' },text: 'I like functional programming!'},{author: {firstName: 'A',middleName: 'random',lastName: 'commenter'},text: 'Why?'},{author: { firstName: 'Thai', lastName: 'P' },text: 'Where should we begin?'}] let Now, I want to obtain a list of people who commented, sorted alphabetically. I could come up with something like this: fullName ( ) { [ .firstName, .middleName, .lastName].filter( => ).join(' ')} function personObject return personObject personObject personObject element element commenters ( ) { = .map( => fullName( .author)) Array.from(new Set( )).sort()} function comments const nameList comments comment comment return nameList commenters(comments) // => [ 'A random commenter', 'Thai P' ] With our knowledge of pointfree-style, we could refactor the above into something like this: fullName = R.pipe(R.props([ 'firstName', 'middleName', 'lastName' ]),R.filter(R.identity),R.join(' ')) const commenters = R.pipe(R.map(R.pipe(R.prop('author'), fullName)),R.uniq,R.sortBy(R.identity)) const This is much more concise and declarative! Then something unexpected happens Later, the comment system allows people to comment anonymously. This means the of the comment can now be . author **null** comments = [ ...comments, {author: ,text: 'How about referential transparency?'} ] null Since we can’t read , the app crashed. comment.author.firstName Let’s now compare the stack traces between the two versions… Version 1 (not pointfree) at fullName (app1.js:4)at comments.map.comment (app1.js:15)at Array.map (<anonymous>)at commenters (app1.js:15)at index2.html:35 Uncaught TypeError: Cannot read property 'firstName' of null In this version, the stack trace above showed exactly where the error occurred: In the function called from ’ mapping function passed to . fullName commenters comments.map Version 2 (pointfree) No red squiggly lines here? But my app’s code lives here! at props (ramda.js:7314)at ramda.js:138at f1 (ramda.js:31)at ramda.js:2061at ramda.js:2061at ramda.js:205at ramda.js:2061at ramda.js:205at _map (ramda.js:572)at map (ramda.js:848)at ramda.js:470at ramda.js:138at f1 (ramda.js:31)at ramda.js:2061at ramda.js:2061at ramda.js:205at index2.html:35 Uncaught TypeError: Cannot read property 'firstName' of null In this version, all we see is Ramda. (app2.js) Indeed, we never created any function in that file. We just composed Ramda functions together, perhaps in a wrong way… Our application code is never mentioned in the stack trace. In this example, we used only once, so we know where to look. But what if the app is larger and is used at many places? R.props R.props Have fun figuring that out! Again, this is not a problem with Ramda (or other FP libraries). We just used it to generate functions to make our code more declarative and pointfree, so Ramda is cool. What’s not cool is writing pointfree code without considering its impact on the stack trace. Note: The function trace When concerns about debugging are raised, functional programming advocates with this problem using a function: would suggest dealing trace() trace = text => (value => (console.log(text, value), value)) const This allows us to see the values that flowed through a pipeline: pipeline = R.pipe(trace('input'),f,trace('after f'),g,trace('after g (output)')) const So let’s go ahead and put those calls into our app! trace fullName = R.pipe( ,R.props([ 'firstName', 'middleName', 'lastName' ]), ,R.filter(R.identity), ,R.join(' '), ) const trace('fullName - input') trace('fullName - after getting components') trace('fullName - after filtering') trace('fullName - output') commenters = R.pipe( ,R.map(R.pipe( ,R.prop('author'), ,fullName, )), ,R.uniq, ,R.sortBy(R.identity), ) const trace('commenters - input') trace('commenters - item - input') trace('commenters - item - before fullName') trace('commenters - item - after fullName') trace('commenters - raw list of authors') trace('commenters - after unique') trace('commenters - after sort (output)') Now, this allows us to see the cause of errors more easily: Ok, so in we tried to send into **_commenters_** null fullName While this debugging technique works during development, it’s not practical for apps running on production, like, on the customer’s browser. Would you leave lot of tracing code like this in a production app? (otherwise, our tests would have caught them), so now, all we have left is an error report with the stack trace. We can’t just tell our customer to edit our app’s source code and put in the calls! Unexpected errors on production usually occur on customer’s browser trace() This is especially important if that error could not be reproduced deterministically. When something goes wrong, the error report should contain enough information for developers to fix it. Sure, this problem could have been better prevented had we have better test suites that covers all the edge cases. But unexpected things happen anyway. Being able to easily deal with unexpected errors on production is something that should not be overlooked. When I learned functional programming from many sources, everyone marveled at how you can use curried functions to make functions snap together like lego pieces. They say that is equivalent to just . But no one ever mentioned about how, in practice, this could eliminate a stack frame that’s crucial for tracking the source of error. **const** g = (x) => f(x) **const** g = f So what can we do? How can we make our functional code easier to debug? How can we make our stack trace more meaningful? Create a function yourself to establish a stack frame We can create non-pointfree functions that calls the pointfree functions where appropriate: fullNamePipeline = R.pipe(R.props([ 'firstName', 'middleName', 'lastName' ]),R.filter(R.identity),R.join(' ')) const fullName (personObject) { fullNamePipeline(personObject)} function return commentersPipeline = R.pipe(R.map(R.pipe(R.prop('author'), fullName)),R.uniq,R.sortBy(R.identity)) const commenters (comments) { commentersPipeline(comments)} function return Now our stack trace is a bit more meaningful: Uncaught TypeError: Cannot read property 'firstName' of nullat props (ramda.js:7314)at ramda.js:138at f1 (ramda.js:31)at ramda.js:2061at ramda.js:2061at ramda.js:205at at ramda.js:2061at ramda.js:205at _map (ramda.js:572)at map (ramda.js:848)at ramda.js:470at ramda.js:138at f1 (ramda.js:31)at ramda.js:2061at ramda.js:2061at ramda.js:205 at index.html:35 fullName (app2.js:9) at commenters (app2.js:19) But now there’s more code. Inject a stack frame dynamically We can inject a stack frame by using this helper function. It helps injecting an artificial stack frame when called: // Note: This function only works correctly in Chrome. /* yourNameIs */ 名は (名, f) { キー = `(╯°□°）╯︵ ${名}` {[キー] () { f.apply( , arguments) }}[キー]} function const return return this Then we can use it like this: fullName = R.pipe(R.props([ 'firstName', 'middleName', 'lastName' ]),R.filter(R.identity),R.join(' ')) const 名は('fullName', ) commenters = R.pipe(R.map(R.pipe(R.prop('author'), fullName)),R.uniq,R.sortBy(R.identity)) const 名は('commenters', ) The stack trace now looks like this: Uncaught TypeError: Cannot read property 'firstName' of nullat props (ramda.js:7314)at ramda.js:138at f1 (ramda.js:31)at ramda.js:2061at ramda.js:2061at ramda.js:205at at ramda.js:2061at ramda.js:205at _map (ramda.js:572)at map (ramda.js:848)at ramda.js:470at ramda.js:138at f1 (ramda.js:31)at ramda.js:2061at ramda.js:2061at ramda.js:205at at index.html:35 (╯°□°）╯︵ fullName (util.js:3) (╯°□°）╯︵ commenters (util.js:3) Our function is more clearly seen in the stack trace, but now we lost the information about where our function is created (app2.js). Record the origin of a function We can improve our function by making it record the call site when we try to name a function: 名は // Note: This function only works correctly in Chrome. 名は (名, f) { atOrigin = (String( Error('ヤバい！').stack).split('\n')[2] || '').trim() キー = `(╯°□°）╯︵ ${名} (created ${atOrigin})` {[キー] () { f.apply( , arguments) }}[キー]} function const new const return return this Now our stack trace looks like this: Uncaught TypeError: Cannot read property 'firstName' of nullat props (ramda.js:7314)at ramda.js:138at f1 (ramda.js:31)at ramda.js:2061at ramda.js:2061at ramda.js:205 (util.js:5)at ramda.js:2061at ramda.js:205at _map (ramda.js:572)at map (ramda.js:848)at ramda.js:470at ramda.js:138at f1 (ramda.js:31)at ramda.js:2061at ramda.js:2061at ramda.js:205 (util.js:3)at index.html:35 at (╯°□°）╯︵ fullName (created at app2.js:2:18) at (╯°□°）╯︵ commenters (created at app2.js:8:20) Now this tells us not only the name of the function, but also where it got created. Have libraries inject meaningful stack frames for us This is just an idea… but would it be great if FP libraries could inject auxiliary stack frames for us where appropriate? When an error occurs, maybe the stack trace could look like this: Uncaught TypeError: Cannot read property 'firstName' of nullat props (ramda.js:7314:19)at ramda.js:138:46 (ramda.js:31:17)at ramda.js:2061:27at ramda.js:2061:27 (ramda.js:204:43)at ramda.js:2061:14 (ramda.js:204:43)at _map (ramda.js:572:19)at map (ramda.js:848:14)at ramda.js:470:15at ramda.js:138:46 (ramda.js:31:17)at ramda.js:2061:27at ramda.js:2061:27 (ramda.js:204:43)at index2.html:43:13 at R.props([firstName,middleName,lastName]) at R.pipe(R.props([firstName,middleName,lastName]),R.filter(R.identity),R.join(' ')) at R.pipe(R.prop(author),fullName) at R.map(R.pipe(R.prop(author),fullName)) at R.pipe(R.map(R.pipe(R.prop(author),fullName)),R.uniq,R.sortBy(R.identity)) This would make it much easier for developers to debug production problems. Use a typed language that guarantees that your functions will never receive an invalid data Languages like Haskell and helps prevent runtime exceptions at the type level. This means you could write pointfree functions and be confident that it will receive unexpected values. Elm never Pointfree-style codes in these languages are often seen. They’re even considered a ‘good discipline.’ Quoting the : Haskell wiki This style is particularly useful when deriving efficient programs by calculation and, in general, constitutes good discipline. It helps the writer (and reader) think about composing functions (high level), rather than shuffling data (low level). By the way, have fun dealing with and those s! These safety features can make your code very verbose when it comes to dealing with data from external services, but . JSON decoders Maybe this could be well worth it in the long run In my experience, refactoring Elm code is much more fun than refactoring JavaScript code, as the compiler helped me at every step. Or just don’t go overboard with pointfree style in JavaScript fullName (personObject) { [ 'firstName', 'middleName', 'lastName' ].map(key => personObject[key]).filter(R.identity).join(' ')} commenters (comments) { nameList = comments.map(comment => comment.author).map(fullName) R.sortBy(R.identity, R.uniq(nameList))} function return function const return Conclusion Writing functional code in pointfree style can make your code more concise and declarative. There are less things to name. But it also comes with a cost. You no longer get stack trace clarity for free. Unless handled carefully, it could make your stack trace very obscure, making it hard to track down the source of errors in production apps. Have more ideas on how to improve debuggability in functional JavaScript code? Please write a response! :)

BUNCH

Trace

Too Long; Didn't Read

In your car, at home, or at work — Bosch technology shapes many areas of life.

Partially-applied (or curried) functions could obfuscate the JavaScript stack trace

Too Long; Didn't Read

Companies Mentioned

Thai Pangsakulyanont

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

Partially-applied (or curried) functions could obfuscate the JavaScript stack trace

Too Long; Didn't Read

Companies Mentioned

Thai Pangsakulyanont

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES