🦋 Changeset detected

Latest commit:8255bc6

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

preview:https://svelte-dev-git-preview-svelte-15000-svelte.vercel.app/

this is an automated message

Playground

pnpm add https://pkg.pr.new/svelte@15000

Would something like this work as well?

<script>import {createAttachmentKey }from'svelte/attachments';conststuff= {    class:'cool-button',onclick: ()=>console.log('clicked'),    [createAttachmentKey()]: (node)=>console.log(`I am one attachment`)  };constotherStuff= {[createAttachmentKey()]: (node)=>console.log('I am another attachment')}</script><button {...stuff} {...otherStuff}>hello</button>

Where the result on mount would be:

I am one attachmentI am another attachment

Personally I would prefer a createAttachment like createSnippet. Just something to consider for the team

nice! 👍

I wonder if it would be more flexible for composition if the syntax can work with named props.

programmatically:

<script>// reverse logic instead of symbol-ed key, a symbol-ed function wrapperimport {createAttachment }from'svelte/attachments';conststuff= {    class:'cool-button',onclick: ()=>console.log('clicked'),    showAlert:createAttachment((node)=>alert(`I am a${node.nodeName}`)),    logger:createAttachment((node)=>console.log(`I am a${node.nodeName}`)),  };</script><button {...stuff}>hello</button>

directly on components:

<Buttonclass="cool-button"onclick={()=>console.log('clicked')}showAlert={@attach (node)=>alert(`I am a ${node.nodeName}`)}logger={@attach (node)=>console.log(`I am a ${node.nodeName}`)}>  hello</Button>

and spread in which case at runtime the prop values can be checked for a special attach symbol (the prop key names are irrelevant)

<script>let { children,...props }=$props();</script><button {...props}>{@renderchildren?.()}</button>

or explicitly declare props, for further composition (and it would be nice for TypeScript declarations):

<script>importAnotherComponentfrom'./AnotherComponent.svelte';let { children, showAlert, logger }=$props();</script><button {@attachshowAlert} {@attachlogger}>{@renderchildren?.()}</button><AnotherComponentlogger={@attachlogger} />

And with either syntax, one could also just pass in a prop as an "attachable" function without{@attach} syntax if they're going to eventually explicitly attach it to a DOM element without spreading.

<AnotherComponent {logger}myAction={(node)=> {/* do something*/ }/>

<!-- AnotherComponent.svelte --><script>let { logger, myAction }=$props();</script><input {@attachlogger} {@attachmyAction}>

Could svelte have a set of constant symbols (assuming we're using theSymbol API)? Could also allow for updating the transition directives.

Something like:

<script>import {ATTACHMENT_SYMBOL,TRANSITION_IN_SYMBOL }from"svelte/symbols";import {fade }from"svelte/transition";conststuff= {    [ATTACHMENT_SYMBOL]: (node)=>console.log("hello world"),    [TRANSITION_IN_SYMBOL]: (node)=>fade(node, { duration:100 }),  };</script><button {...stuff}>hello</button>

The purpose of having a function that returns symbols - rather than using a single symbol - is that it lets you have multiple attachments on a single element/component without them clobbering one another.

The current rub with transitions is their css and/or tick methods that apply to style but if transitions were just attachments that modified the style attribute of node then they would just be attachments too...

The current rub with transitions is their css and/or tick methods that apply to style but if transitions were just attachments that modified the style attribute of node then they would just be attachments too...

Actions can already do this already, the advantage of transitions is to do this outside the main thread
In svelte 3/4 creating css transitions and in svelte 5 using the WAAPI

One of the advantages of the special syntax of actions was the fact that it generated shakable tree code

Attachments do not seem to have this advantage since every element needs to look for properties with the special symbol for special behavior

If I understand correctly, it is not possible to extract an attachment from the props and consequently it is also not possible to prevent an attachment from being passed to an element with spread props, using an attachment on a component is basically a redirect all

The current rub with transitions is their css and/or tick methods that apply to style but if transitions were just attachments that modified the style attribute of node then they would just be attachments too...

Actions can already do this already, the advantage of transitions is to do this outside the main thread
In svelte 3/4 creating css transitions and in svelte 5 using the WAAPI

True, I'm curious about the waapi usage

The purpose of having a function that returns symbols - rather than using a single symbol - is that it lets you have multiple attachments on a single element/component without them clobbering one another.

I'd be curious about the intention of this, cause intuitively I would assume using the function would override any previous definitions the same way standard merging of objects would. Allowing multiple of what at face value feels like the same key feels like it'll trip people up.
I think if you wanted to have multiple attachments through props, using a sequence function would be a lot clearer and guarantee what order attachments occur in.

<script>import {ATTACHMENT_SYMBOL }from"svelte/symbols";import {sequence }from"svelte/attachments";constattachmentA= (node)=>console.log("first attachment");constattachmentA= (node)=>console.log("second attachment");conststuff= {    [ATTACHMENT_SYMBOL]:sequence(attachmentA, attachmentB),  };</script><button {...stuff}>hello</button>

@huntabyte

Would something like this work as well?

try it and see :)

I wonder if it would be more flexible for composition if the syntax can work with named props.

You're just describing normal props! The{@attach ...} keyword is only useful when it's anonymous.

<MyComponent {@attachanonymousAttachment}named={namedAttachment} />

<script>let { named,...props }=$props();</script><div {@attachnamed} {...props} />

One of the advantages of the special syntax of actions was the fact that it generated shakable tree code

I don't follow? The only treeshaking that happens, happens in SSR mode — i.e.<div use:foo> doesn't result infoo being called on the server. That remains true for attachments. The additional runtime code required to support attachments is negligible.

If I understand correctly, it is not possible to extract an attachment from the props

It's deliberate that if you use{...stuff} that attachments will be included in that. If you really want to remove them it's perfectly possible, it's just an object with symbols. Create a derived that filters the symbols out if you need to, though I'm not sure why you'd want that.

Allowing multiple of what at face value feels like the same key feels like it'll trip people up.

Most of the time you're not interacting with the 'key', that's an advanced use case. You're just attaching stuff:

<div {attachfoo()} {@attachbar()} {@attachetc()}>...</div>

One possibility for making that more concise is to allow a sequence...

<div {attachfoo(),bar(),etc()}>...</div>

...but I don't know if that's a good idea.

Love the proposal and how it simplified actions, specially the handler having a single parameter, which will not only encourage but force writing more composable attachments via HOFs.
i.e:

exportconstdebounce=(cb:()=>void)=>(ms:number)=>(element:HTMLElement)=>{// implementation intentionally left blank}

<scriptlang="ts">const debounced_alert=debounce(()=>alert("You type too slow"));</script><textarea {@attachdebounced_alert(2000)}></textarea>

Personally I would prefer a block syntax rather than the PR one.

<!--Applies both attachments to input and textarea-->{#attachmentdebounce(()=>alert("You type too slow"))(2000),debounce(()=>alert("Server is still waiting for input"))(3000)}    <inputtype="text"/>    <textarea></textarea>{/attachment}

My reasons to prefer a block are:

1. It is an already known syntax
2. Easily discoverable via intellisense when you type{# (to write any other block) and the autocomplete brings upattachment as one of the options. I don't think anybody that does not know about attachments is going to discover the PR syntax via intellisense.
3. Blocks are easier to read when the block content is a big tree since you can see the opening and closing. This is useful when the element that has the attachment is not an input/button but a clickoutside or a keydown on a whole page section.
4. Syntax is cleaner even if you inline the attachment configuration options as otherwise they would be on the same line as 20 tailwind classes, anid,name,data- andaria- attributes.
5. The{@something} syntax already exists and, until now, it could only be usedinside an element/block, be it declaring a block-scoped constant with{@const}, rawdogging html with{@html}, or rendering with{@render}.
   Even debugging with{@debug} cannot be used in the opening tag like{@attachment}. This breaks sytax consistency and did not happen with the olduse: syntax as the oldsomething: syntax was always used on the opening tag of an element.

I like this, my only concern is the similarity in syntax between this and logic tags. It may make new developers think that something like this is valid Svelte:

<div {@const ...}>

Or may make them try to do something like this:

<element>{@attach...}</element>

I love it!

Great iteration on actions, I love it!

Came here to ask how I could determine if an object property was an attachment, but looking at the source, it looks likeisAttachmentKey is a helper to do just that!

Two things in particular are needed: a way to add per-element lifecycle functions, and an API for delaying the destruction of an effect until some work is complete (which outro transitions uniquely have the power to do today). This PR adds the first; the second is a consideration for our future selves.

I think it would be really intuitive if attachments could return an async cleanup function with the element/component being removed once the cleanup function (and all nested cleanup functions) settle/resolve!

Is it worth having a migrator for this? Will actions be deprecated?

I don't think actions will be deprecated in the immediate future, but, likeclass:, it'll probably be deprecated at some point. Also, since there is a difference in how actions' and attachments' arguments work, it seems unlikely that a migrator tool could automate the process.

Yes thats a good point, I wonder if there is a benefit to the built-in use:enhance action moving to a built-in attachment

That would enable forwarding it through form wrapper components.

Does this PR allow attaching transitions with attachments?

No. That would require an API for preventing effects from being destroyed; that hasn't been designed yet and will come later. After that, we can design a new transition API that builds on top of it and provides more flexibility than the current one.

Hi,@Rich-Harris . If I understand correctly, currentlyattachment is running inside an effect.

I think this is very important to mention in theDOC , because it's diff fromevent handler andaction (action untrack)

current it only says

Since the tooltip(content) expression runs inside aneffect, the attachment will be destroyed and recreated whenever content changes.

I think it's unclear about what happens if state change inside attachment (return value oftooltip(content))

Another part isInline-attachments example, if attachment already inside an effect, why create another$effect

I am not sure attachment function run inside an effect is by design.

Best regards

I think it's unclear about what happens if state change inside attachment (return value of tooltip(content))

That is exactly what happens in the example (the content state is read inside of the attachment effect, and that is what makes it recreate itself

The nested effect makes sure that it doesn’t recreate itself, but update parts of it (another example I saw was something like tippy.setContent inside of an effect, to not recreate the tooltip)

nested effect part I understand now, thanks. didn't find the doc about it before.

All I am saying is that maybe the doc counld be more clear about attachment is running inside an effect (not only factory part), currently only this

Attachments are functions that run when an element is mounted to the DOM. Optionally, they can return a function that is called when the element is later removed from the DOM.

I can do something likethis, it still works.

sometime state is shared from outside, we need be aware of that, so we canuntrack or createnested effect to avoid unwanted rerun