Monster? It's very straightforward, functional and easy to follow. You could easily refactor that and break it up without fuss. Not sure what the big deal is here. The fact that it operates on a state machine makes it even easier. You can see all the different ways the UI will render by stubbing the state value.

The problem is when you have a large app with multiple components and plenty of state to manage. These things always look easy when they are small toy isolated projects.

This sort of thing in a production app would be littered with global state, it would be difficult to change anything / refactor without serious anxiety, if you have multiple developers good luck getting them to program the same predictable way, importing libraries see previous point, etc, etc.

Yes it's okay for this example. I think it can get out of hand.

Not the worst. Seems acceptable imo, yes its a long function with giant switch statement but its pretty clear what it does and easy to read.

Adding a few more fields would require me to update every case plus add some more, no? Resulting in an hard to maintain explosion of state? Or am I missing something.

https://statecharts.dev/state-machine-state-explosion.html

What are the other options here then? Not trolling just wondering. If an app has state it has to be dealt with somewhere...

You can dispense with the whole intermediate state variable and just do everything directly

  function calcState() {
    // Return field disabled for one-way trips
    elems.return.disabled = isOneWay();
    
    let allOk = true;
    
    // All enabled fields are valid?
    for (const f of [elems.departure, elems.return]) {
      const isInvalid = (
        !f.disabled &&
        isBadFormat(f.value)
      );
      setInvalid(f, isInvalid);
      if (isInvalid) allOk = false;
    }
    
    // Return trip after departure trip?
    if (allOk && !isOneWay() && isEarlyReturn()) {
      allOk = false;
    }
    
    // Enable submit if everything is OK
    elems.submit.disabled = !allOk;
  }

  function setInvalid(elem, invalid) {
    elem.setAttribute(ARIA_INVALID, invalid);
  }

This follows the problem description quite closely, eg. "The return textfield is enabled if the combobox’s value is return flight" is implemented by one line, and not spread across seven different enable/disable calls.