distinction between automatic closing and user action

[dominikcz]

HI, I have a case where I have to make a distinction between situations when user clicks a toast in order to close it and another one, when toast autocloses. That's why I propose additional (optional) parameter to onpop callback.

onpop: (id, ev) => {}

When it autocloses ev is undefined. In other cases it is original event (mouse click, touch or key press).

[zerodevx]

Hey, continuing from #105, I understand the need to differentiate between dismiss by timeout, or user-action. It probably makes more sense to return a details object as the second param.

IMHO, the onpop() callback should be removed in the next major - the gold standard should be toast.push() returning a promise that resolves to details, like so:

const { id, val } = await toast.push('hello world!')

I'm been waiting (for a year now 😅) for Svelte's v5 stable release - mainly because this project will greatly benefit from v5's fine-grained reactivity. But I guess it's necessary to cut a maintenance release right about now.

I'll probably merge this in first and refactor it to return a details object.

[dominikcz]

hi, I can change that to detail object in my pull request it that helps :)

[zerodevx]

Great. Can you also run npm format before committing? 🙏

[dominikcz]

I've made changes and run npm run format but as it made over 25 files changed I applies changes only to those two that I was intentionally changing. Hope that's OK

[zerodevx]

That's ok - thanks so much for your contribution!

[dominikcz]

Thank you. On the side note: maybe it's also a good time to update dependencies to newer versions?

[zerodevx]

maybe it's also a good time to update dependencies to newer versions?

Yes I'm on it! 😄

[zerodevx]

Hey @dominikcz, hope you don't mind that I made some changes, mainly because I wanted to avoid polluting the SvelteToastOptions object. In v0.9.6, use the onpop() callback like so:

toast.push('Hello world', {
  onpop: (id, details) => {
    // `details.event` contains the mouse or keyboard event
    // and is `undefined` if the toast closes by timeout
  }
})

[dominikcz]

Hi, I don't mind at all, undefined was in my first proposal after all. It is important to be able to distinguish if it was auto-close or not, the way it is done does not matter that much. I introduced details object to make it future-proof, as you can extend it by adding new properties without affecting existing use cases (instead of just passing event object directly as in original PR). Therefore autoClose property was just an example.