Closed JoviDeCroock closed 1 month ago
Latest commit: 023c1405aefda63940be965c7fa149ca25a91f6d
The changes in this PR will be included in the next version bump.
Not sure what this means? Click here to learn what changesets are.
Click here if you're a maintainer who wants to add another changeset to this PR
Name | Link |
---|---|
Latest commit | 023c1405aefda63940be965c7fa149ca25a91f6d |
Latest deploy log | https://app.netlify.com/sites/preact-signals-demo/deploys/66fe4374f9034d0008c86b35 |
Deploy Preview | https://deploy-preview-595--preact-signals-demo.netlify.app |
Preview on mobile | Toggle QR Code...Use your smartphone camera to open QR code link. |
To edit notification comments on pull requests, go to your Netlify site configuration.
Size Change: +268 B (+0.32%)
Total Size: 83.3 kB
Filename | Size | Change | |
---|---|---|---|
docs/dist/basic-********.js |
243 B | -1 B (-0.41%) | |
docs/dist/demos-********.js |
3.45 kB | +2 B (+0.06%) | |
packages/preact/dist/signals.js |
1.39 kB | +128 B (+10.11%) | â ī¸ |
packages/preact/dist/signals.mjs |
1.36 kB | +139 B (+11.39%) | â ī¸ |
We could also apply the same notification delay to the prop updater and the text updater to limit their DOM mutation frequency to screen refresh.
@developit I'll follow up the changes to props/text separately
At first I thought this would solve https://github.com/preactjs/signals/issues/315 but that's still not the case I think as we are currently only deferring explicit effects, however in this case it's the distinction between re-rendering a VNode and an eagerly recalculating computed.
I guess in an ideal scenario we don't want to allow for synchronous updates within a Preact application, doing so will force us into scenario's where our DOM-tree is newer than our VNode tree
315 is a perfect example of that going wrong đ however this PR will be a performance improvement nonetheless as we are not blocking anymore.
I would consider finding a solution to #315 important for mixed usage between DOM-optimised updates and conditional VDOM.