Functions should be treated as objects for purposes of updating computations

[Rich-Harris]

This example shows the bug (which I did just encounter in a real application, as bizarre as the example looks) — computed values are recomputed if one or more of their dependencies a) are among the changed items AND b) the value has changed from its previous value or is a non-primitive value (since objects and arrays could have been mutated).

That doesn't take account of functions, whose return value might be dependent on a closure. So the check needs to be updated:

Current code:

function applyComputations ( state, newState, oldState, isInitial ) {
  if ( isInitial || ( 'time' in newState && typeof state.time === 'object' || state.time !== oldState.time ) ) {
    state.getFoo = newState.getFoo = template.computed.getFoo( state.time );
  }
	
  if ( isInitial || ( 'getFoo' in newState && typeof state.getFoo === 'object' || state.getFoo !== oldState.getFoo ) ) {
    state.foo = newState.foo = template.computed.foo( state.getFoo );
  }
}

Better code:

function differs ( a, b ) {
  return ( a !== b ) || ( a && typeof a === 'object' ) || ( typeof a === 'function' );
}

function applyComputations ( state, newState, oldState, isInitial ) {
  if ( isInitial || ( 'time' in newState && differs( state.time, oldState.time ) ) ) {
    state.getFoo = newState.getFoo = template.computed.getFoo( state.time );
  }
	
  if ( isInitial || ( 'getFoo' in newState && differs( state.getFoo, oldState.getFoo ) ) ) {
    state.foo = newState.foo = template.computed.foo( state.getFoo );
  }
}

[Conduitry]

In that example, isn't getFoo arguably no longer a pure function? That's not to say there's not still some bug here, or that there's not some other less insane-looking way to reproduce this.

On the other hand I guess in this case burdening everyone with an extra typeof to handle this case isn't really all that much of a burden.

[Rich-Harris]

or that there's not some other less insane-looking way to reproduce this.

Ha, that's fair. The place I encountered this was in an app that used D3 scales — rather than generating a new function when the dimensions change, the D3 convention is to call a method of a function that updates the values inside the closure where the function is generated:

https://svelte.technology/repl?version=1.13.1&gist=fcdc653576d0ffb156b4d863cd3e5874

If you shrink the width of the output window you'll see that barwidth isn't being recomputed. If you add the width parameter, it starts working — but it should consider xScale to have 'changed' and not need that extra encouragement.