Consider this javascript function:

    var someArr = [...];
    var someObj = {...};
        if (matchItem(item)){

Assuming that given code works correctly, let's take a look at it's design. As you can notice, someArr.forEach is passed a callback function. Meanwhile, object someObj belongs to the scope of that callback. So from inside the callback function we can manipulate someObj.

I.e., in this case the callback produces side effects.

We could also bind someObj to this object of the callback:

    var someArr = [...];
    var someObj = {...};
            if (matchItem(item)){

Again, we are producing some side effects here, though in more explicit manner. In general, this approach can not be considered functional, because it violates the no-side-effects principle.

How should we design code in such situations? Which way is more robust? What are the best practices?

Thank you!

  • 1
  • 3
    Generally speaking, if you want your forEach to be "functional," you create a new collection incorporating the forEach "side-effects", and leave the original collection intact. – Robert Harvey May 8 '15 at 14:26
  • Side effects do not affect the input collection. They affect some other object in the scope. What is the way to incorporate them? – iTollu May 8 '15 at 14:42
  • 1
    By returning a copy of the object, rather than modifying the original. – Robert Harvey May 8 '15 at 14:51
  • 2
    @RobertHarvey nails it. Purely functional programming is about computing with values. Immutable values go in, new values come out. That's it. The rest is just a matter of "how can I make this reusable/generic?" and "how can I make this more efficient?", which aren't entirely specific to functional programming. But also realize that 1) every useful program has side effects (otherwise there's no point in running it) and 2) JavaScript doesn't support side effect-free programming particularly well (most things are deeply mutable). – Doval May 8 '15 at 15:22

The Array.prototype.forEach is meant for side effects, it doesn't return anything. Whether you like it or not depends on your application, there's no clear best practice.

Object oriented programming is stateful by design, it's meant for side effects and for objects changing other objects, that's the entire point.

Functional programming is immutable by design*, the idea is that you have little to no side effects in your application, except on the very edge of your application (You have to exert output somehow, that's a side effect). You generally want every function to accept input, process it somehow, and then return an output, without modifying any of the inputted objects.

* That's not entirely accurate. Functional encourages immutability, and there are functional languages which enforce the no-side-effects rule, but you can produce side effects in functional style programming.

Personally, I like the functional style more, I keep my objects immutable or as immutable as possible. I can guarantee that if I have

var obj = {hello: 'world'};

At the end of the scope, obj would still be {hello: 'world'}, regardless of what functions it was passed into. None of the functions modified it along the way.

TL;DR - There's no clear best practice here. It's OK to have side effects, as long as you're aware of the risks of things changing under your feet.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.