the only thing changing between these cases is the value output. I would suggest that we separate the getting of the value from the dispatch; this way it is clear that only the value changes between the three cases

// can be outside of the scope
async function getExpressionValue(error, input) {
  if (error) {
    return { input, result: error };
  }
  if (!isPaused(getState()) {
    return await client.evaluate(wrapExpression(input));
  }
  return await dispatch(evaluateInputAtFrame(input));
}

// ... 

const value = await getExpressionValue(error, expression.input);

return dispatch({
  type: "EVALUATE_EXPRESSION",
  input: expression.input,
  value
});

I see two issues here:

ensureParserText is potentially.. doing a lot of things, and it is being used a lot. if a loadSource is in flight (for example, someone forgets an await somewhere), we may be retriggering it here, with no way of cancelling the original and as a result -- doubling the work.

second issue: "ensure" doesn't tell us that it is going to load the source text and then set the parser, so unless everyone who uses this function checks the definition, they will not see that it is not checking for a source (ensure suggests that "lets check if it is there, if not throw an error", similar to assert).

I think this needs to be renamed / possibly removed and the core problem addressed instead (better state management) -- what do you think?

Good points, and I'm curious how they should be addressed.

1. maybe a state of loading on the source with the promise? so that ensure can return it.

2. I was also confused at the beginning, but now it makes sense to me. ensure is not like assert. But you could also call it loadSourceTextIfMissing (similar scheme to performUpdateIfNecessary from https://github.com/facebook/react/blob/v15.6.1/src/renderers/shared/stack/reconciler/ReactReconciler.js#L184)

3. What do you mean in "better state management"?

By better state management i mean introducing sagas :P but jason will give me serious side-eye for that one