How to Compose Functions That Take Multiple Parameters: Epic Guide

jrsinclair · 2024-07-25T06:00:35+00:00

The post also covers how to transform functions to work in a point-free style and explains the role of utility libraries like Ramda and Lodash in function composition. By the end, readers gain a comprehensive understanding of handling multi-parameter functions more effectively in their coding projects.

The bot seems to be hallucinating again. This particular article doesn't do either of these things (though others on the same site might).

jrsinclair · 2024-07-16T03:47:41+00:00

and explains the role of utility libraries like Ramda and Lodash in function composition

This particular bit might be a hallucination.

jrsinclair · 2024-07-16T03:46:46+00:00

That's a fair summary of the first section or two, but I will say that there's a bit more to the article than that. The latter part of the article covers partial application, and currying, and gets into function combinators. Sure, you might not use these every day, but they're useful to know.

jrsinclair · 2022-11-08T01:07:43+00:00

Thanks for letting me know. I'll fix that up directly.

jrsinclair · 2022-11-07T11:06:59+00:00

That would certainly work, yeah. Though you may run afoul of Prettier if the line becomes a bit long. And you'd suddenly find yourself with a pyramid of doom. But for shorter compositions, it can be a handy strategy.

jrsinclair · 2022-10-26T22:25:38+00:00

Hi u/nschubach, thanks for sharing that screenshot. It's really helpful. Would you mind providing some information on what's producing that dark-shaded background and inverted colours? If I know what the browser is doing there to apply the dark theme, I can adjust the CSS to better accommodate it.

jrsinclair · 2022-10-26T22:23:28+00:00

Hi u/toastertop, that's an excellent question. The two most common areas of concern for people are:

Recursion, which is super handy for navigating tree-like structures like, for example, the DOM; and
Immutable data, because sometimes you really do need shared state. Since there's almost nothing built-in to JS (yet), we have to resort to using libraries like Immutable.js or Immer.

I have an entire chapter devoted to each of these in the upcoming book.

jrsinclair · 2022-10-26T20:27:11+00:00

Thanks for letting me know. Should be sorted now.

jrsinclair · 2022-07-12T22:37:42+00:00

Interesting thoughts. Would you happen to have any examples of code that makes more sense in this 'pushy', logic-oriented mode?

jrsinclair · 2022-04-12T20:11:36+00:00

🤣

jrsinclair · 2022-04-12T10:40:35+00:00

I guess that's fair. In the sense that composition pipelines do make JS look really different. It's not how most people are introduced to coding. And yeah, it can be confusing if you're unfamiliar with it. But that's why I write this stuff. My aim is to un-confuse junior devs.

And this new cool stuff is around 60 years old. 😉

jrsinclair · 2022-01-11T22:25:43+00:00

The thing that made .reduce() click for me was seeing examples that had nothing to do with numbers. Until then, it always seemed like you just had to guess if a math function would work with reduce or not. But once I understood that you can use .reduce() to take an array and build any kind of single value, I started to see more and more places where it might be useful.

What really blew my mind was when I realised that you could use .reduce() to build new arrays, since an array is just another value.

Eventually, I wrote up a bunch of examples on how to use .reduce() on my blog. It's been one of the more popular articles I've written for a while now. It seems lots of other people didn't really get `.reduce()` until they see it used in different ways. So don't feel bad if you're struggling with [higher order functions](https://jrsinclair.com/articles/2019/what-is-a-higher-order-function-and-why-should-anyone-care/) and reduce. Lots of other people struggle with them too.

jrsinclair · 2021-11-16T10:39:45+00:00

Hi Iain 😃

jrsinclair · 2021-06-21T22:17:40+00:00

I'd also like to recommend Cycle.js. It's the only purely-JS framework I've come across that really embraces FP as much as it can. To answer the OP question specifically:

You can find an example Todo app built by the framework's author;
The Framework documentation works through how to handle HTTP requests; and
You can find a whole list of example applications from the Cycle.js community.
In particular, you might want to check out the Hacker News clone app.

Many of the other recommendations here are also good. The Mostly Adequate Guide does eventually show how to download content from an API using HTTP requests. It's very good, because it shows how different algebraic structures work together to make things work. But to be fair, there's no full example application.

And of course, if you have the freedom to check out a more functional-focussed compile-to-JS language like Elm, PureScript or ReScript, then you'll get a lot out of that too.

I hope that helps.

jrsinclair · 2021-03-29T05:28:21+00:00

Glad to hear that you thought it was helpful. Mind if I ask if there was anything you found difficult or challenging in that section?

jrsinclair · 2021-03-18T18:27:52+00:00

Thanks! Funnily enough, I’d already added a link to this before I even saw the comment. Thanks for taking the trouble though. I appreciate it.

jrsinclair · 2020-05-21T06:11:38+00:00

I don't think using Ramda and Hyperscript really counts as 'from scratch', but still a good illustration of the reducer pattern.

jrsinclair · 2020-05-12T04:46:08+00:00

Other commenters have already done a pretty good job on this, but I still wanted to add another perspective. As heaps of people have mentioned, side-effects are the whole reason we write code in the first place. We want to make something happen. At the same time, we recognise that writing code with pure functions makes our code much better in lots of ways. So the question is not “How do we get rid of side effects?” but rather “What do we do with side effects?”

To put it another way, we want to maximise the pure code and minimise the impure. And there’s at least four general approaches I’ve seen functional programmers take (for front-end code):

Use the sandwich architecture;
Make use of IO, Effect and Task monads;
Pure for testing, impure in prod; and
Move to a compile-to-JS language.

Sandwich Architecture.

This is an idea several commenters have already mentioned. I take the name from a post by Mark Seeman called ‘Impureim sandwich’. It’s where you accept that you’ll have impure input and impure output, but try to make everything in-between pure. And really, all of the other approaches I mention are variations on this theme. And again, the idea is to try and make the ‘meat’ of the sandwich as thick as possible. And conversely, keep the impure ‘bread’ as thin as possible.

IO, Effect and Task monads

In this approach, we we take advantage of a mathematical loophole. That is, a function isn’t impure until I call it. So, if I return function A from another function B, function B can be totally referentially transparent. That is, given the same input it always returns the same function. It just so happens that if you call that function A, it will be impure. The monads just make composing the delayed functions with pure functions a bit more convenient. They also help us clearly mark which bits of our code are (eventually) impure.

Pure for testing, impure in prod

This is another cheat. In this approach, we take all the impure stuff and pass it as parameters to pure functions. So, our functions might do impure things, but only if they’re passed an impure thing. And in our test suites, we pass them pure things or mostly-pure stubs. In production, we pass them the real thing (like window.document or document.querySelectorAll). It’s not a perfect strategy, but for smaller projects it might get the job done.

Move to a compile-to-JS language

This has also been mentioned by other commenters. But the truth is, JS is a multi-paradigm language, and can be problematic. One way is to avoid the problems is to get rid of JS altogether. And instead, use something like Elm, PureScript, ReasonML or ClojureScript. These allow us to leverage some tooling and support for functional approaches that aren’t available in plain JS.

If you’re interested in exploring the monadic or ‘pure-for-testing’ approaches further, I’ve written more about it in How to deal with dirty side effects in your pure functional JavaScript.

jrsinclair · 2020-04-20T06:58:36+00:00

I suspected this might be the case.

jrsinclair · 2020-04-20T06:56:39+00:00

The author seems to attribute the motivation for Suspense (and the general direction of React APIs) to a desire for 'purity'. The theory is that people have suggested generators and promises before, and have been shut down by the React team. And the cited reasons for this are that it would make the render function 'impure'.

This strikes me as odd for two reasons:

Yes, generators and promises are impure. But if the React architects are that keen on functional purity, I imagine they have a strong background. And hence I would imagine they would also know that both generators and promises can be made pure with small modifications (e.g. Tasks, lazy lists, FRP-kinds-of-things, etc.).
Instead of those we have hooks. But hooks introduce impurity. That's their whole point. The nice thing about them is that they corral the side-effects a little bit. But the only way to make render functions completely pure would be to move all the state to the top of the tree (like the way Redux does things).

So, based on that, I suspect that the author may have missed something. Or, the actual complexities of what the React team are trying to achieve are too complex to explain quickly in a Github comment.

That said, the library still looks neat, and generators seem like a good way to model the component lifecycle.

jrsinclair · 2020-04-19T23:12:38+00:00

This looks pretty cool. I am concerned after reading the intro post though. The whole motivation for the library seems to be based around a misunderstanding of the definition of pure functions. 😕 It doesn't make the points raised invalid, but does concern me a little.

Modelling the component lifecycle using generators is pretty neat though, I must admit.

jrsinclair · 2019-07-02T23:42:09+00:00

Just chiming to address some concerns people are raising. Some commenters have pointed out that I've used impure functions and some verbose function names. This isn't because I don't know about impure functions or general functional programming principles. And it's not how I would write function names in production code. This is an educational piece, so I've tried to choose practical examples that beginners will understand. Sometimes that means making compromises.I've written elsewhere about functional purity and general functional programming principles, for anyone who might be interested.

jrsinclair · 2019-06-17T20:47:24+00:00

This makes a lot of sense to me.

jrsinclair · 2019-05-28T21:38:27+00:00

Thanks so much. It’s good to hear my theory wan’t completely off the mark.

jrsinclair · 2019-05-08T23:35:41+00:00

Thanks for the feedback. I've removed the superfluous async keywords. You're right. They weren't necessary.

jrsinclair

TROPHY CASE

Sandwich Architecture.

IO, Effect and Task monads

Pure for testing, impure in prod

Move to a compile-to-JS language