Is it an antipattern to pass an object that stores the application state from one function to another?

Question

The program is written in JavaScript. To give you a rough idea what I am thinking of:

function State() {
  return {
    color: 'green',
    size: 100,

    // ... there are other properties here
  }
}

function init() {
  const state = State()
  const otherObj = OtherObj()
  
  // ...something like an event fires `foo`
  foo(state, otherObj)
}

function foo(state, otherObj) {
  state.size = calcNewSize(state) // state changes
  state.color = pickNewColor(state, otherObj) // state changes
  // ...   
}

function pickNewColor(state, otherObj) {
  const someInformation = getSomeInformation(state)

  // ... do other stuff

  return newColor
}

const a1 = init()
const a2 = init()
const a3 = init()

Right now, I have 3 objects that I should pass from function to function, but I am wondering, if this would scale well.

I am also wondering, if it is better to pass the entire object, instead of only the properties that are needed by these functions. Maybe it would be a good idea, to draw a line at 2-3 arguments, and if more is necessary, then pass the entire object.

Also, this could possibly be refactored into a single class, with methods (like pickNewColor, getSomeInformation) having access to the properties (like size, color), in which case there wouldn't be any need to pass around objects. However, I was wondering, if the above approach of passing around objects could work well.

Answer 1

Some frameworks, like React, use this pattern. React and Redux get used together a lot. This sounds like it will tightly-couple your code.

Essentially you want to make a "demi-god" object or set of objects that store and manage application state. I used the word demi-god because you'll likely run into several issues associated with god objects like.

1. Poor handling of concurrent events. Just like a god object, you're likely to have weird errors where the state magically changes on you, and there isn't an obvious reason why. You haven't guarded access to state variables, just broke them into multiple classes.

2. Lots of state to pass around. Instead of passing 1 big object you're passing a bunch of small ones. If you have to pass several of them per screen you're you're essentially passing a god object piece by piece.

Your example looks kind of like some of the React tutorials before they explain Redux. I couldn't find an anti-pattern name for what you're doing, but it sounds like you'll couple almost all your classes together through these state objects (bad).

How can you abstract this state? How many objects will need to be refactored if you have a bug in the state objects? This is what highly coupled code looks like.