chore: use proxy instead of signal in createRoot #9799
Conversation
|
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
|
This is ready, but we should merge #9801 into this branch first |
* use proxies instead of signals for spread/rest * fix some spread attribute stuff * remove is_signal calls * simplify some more * more * remove some unnecessary unwrapping * another * simplify * simplify * simplify * remove another MaybeSignal * more * remove more unwraps * code-golf, docs --------- Co-authored-by: Rich Harris <[email protected]> Co-authored-by: Simon Holthausen <[email protected]>
| @@ -2616,73 +2621,14 @@ export function spread_props(props) { | |||
| * @returns {Exports & { $destroy: () => void; $set: (props: Partial<Props>) => void; }} | |||
| */ | |||
| export function createRoot(component, options) { | |||
There was a problem hiding this comment.
With this change createRoot is basically == mount. I'm wondering if we should therefore should just get rid of createRoot and move the $set/$destroy interface onto mount (in a follow-up PR)
There was a problem hiding this comment.
Another option is this:
import { createProps, createRoot } from 'svelte';
import App from './App.svelte';
const props = createProps({ count: 1 });
const destroy = createRoot(App, { props });
// later
props.count += 1;
destroy();In the case where you didn't need to update the props after creation, it would just be this:
import { createRoot } from 'svelte';
import App from './App.svelte';
const destroy = createRoot(App, { props: { count: 1 } });
// later
destroy();To me this feels a bit more harmonious than splodging together props with $set and $destroy methods. And it would render accessors unnecessary.
(Obviously we'd still keep that stuff around in compat mode.)
There was a problem hiding this comment.
There's more than accessors, the returned instance can also contain functions etc that are exposed through
<script>
export function x() {..}
</script>so we won't be getting away with just destroy.
I also think that getting an object back you can call $set and $destroy on feels like a better API than creating a props object you interact with separately.
Lastly, if it was only mount, we could introduce a corresponding hydrate, with the difference being that mount never sets the hydration flags, which if done right would hopefully enable Rollup etc to treeshake the whole hydration code away, ensuring smaller builds for (for example) web component people.
There was a problem hiding this comment.
This is what I have been thinking lately. It would be great if createRoot can be ditched somehow in favor of mount so we have a single API.
This is part of a larger effort to simplify props handling internally, by using proxies rather than signals to represent the props object. In time, this will hopefully enable us to get rid of things like
sync_effect.Just one small change in behaviour — the enumeration order of keys in rest props is different. (I cannot imagine this ever mattering)
Before submitting the PR, please make sure you do the following
feat:,fix:,chore:, ordocs:.Tests and linting
pnpm testand lint the project withpnpm lint