iframe update granularity causes unintended reloads

[cliffspradlin]

According to Surplus documentation, all attributes of an element are updated as part of a single generated S computation.

That's probably usually ok, and I understand from #23 (comment) the general reason for this behavior is to guarantee precedence of attributes.

However, with an iframe it seems like every time the 'src' attribute is touched (at least in Chrome), the iframe is reloaded. So even if you set a different attribute of the iframe, the iframe is always reloaded.

Demo: https://jsfiddle.net/u825n1vw/18/

It seems like a minimum viable workaround would be to have special code emitted when updating an iframe src attribute, such as:

if (iframe.src !== signal()) {
  iframe.src = signal();
}

I wonder what other side effects exist that this 'single computation' granularity would trigger. I think I'd rather give up the precedence guarantee for finer granularity.

[adamhaile]

Shoot, I thought I replied to this but apparently not. Sorry for that.

Yeah, almost all DOM properties are idempotent -- setting them to their current value is a no-op -- but iframe.src is an exception.

If you need a workaround now, you can move the .src assignment to its own fn, which means it has its own computation and won't be retriggered by other properties changing: <iframe fn={el => el.src = "..."} />. Not pretty but it will work.

Precedence is really only a concern when we're using a spread assignment in an element, because only in that case do we not know until runtime what properties we're actually setting. If we don't have a spread, we know all our properties and can sort out precedence at compile time. That then allows us to move static properties, like the iframe.src assignment, out of the computation entirely. I had this optimization working in an earlier version of the compiler, but it's currently broken due to some refactoring. I hope to bring it back soon.

That wouldn't totally solve the issue with iframe.src, b/c if you had a dynamic src and some other dynamic property, they'd both be in the computation and both get set when either triggers. If there are more properties that have unfortunate re-set behavior, I may consider adding smarts like you outlined in your code snippet to the compiler.

Best
-- Adam