(fn)
| 75 | * @param {() => void} fn |
| 76 | */ |
| 77 | const resolve = (fn) => { |
| 78 | if (destroyed) return; |
| 79 | |
| 80 | resolved = true; |
| 81 | // We don't want to restore the previous batch here; {#await} blocks don't follow the async logic |
| 82 | // we have elsewhere, instead pending/resolve/fail states are each their own batch so to speak. |
| 83 | restore(false); |
| 84 | // ...but it might still be set here. That means a `save(...)` has restored it — but that batch will |
| 85 | // likely already have been committed by the time it resolves, and this resolve should be processed |
| 86 | // in a separate batch. We're not using batch.deactivate()/activate() above because get_input() |
| 87 | // could write to sources, which would then incorrectly create a new batch or could mess with |
| 88 | // async_derived expecting a current_batch to exist. |
| 89 | if (current_batch === batch) { |
| 90 | batch.deactivate(); |
| 91 | } |
| 92 | // Make sure we have a batch, since the branch manager expects one to exist |
| 93 | Batch.ensure(); |
| 94 | |
| 95 | try { |
| 96 | fn(); |
| 97 | } finally { |
| 98 | unset_context(false); |
| 99 | |
| 100 | // without this, the DOM does not update until two ticks after the promise |
| 101 | // resolves, which is unexpected behaviour (and somewhat irksome to test) |
| 102 | if (!is_flushing_sync) flushSync(); |
| 103 | } |
| 104 | }; |
| 105 | |
| 106 | input.then( |
| 107 | (v) => { |
no test coverage detected