feat(toast): Add toast component

[jstnjs]

PR Checklist

Please check if your PR fulfills the following requirements:

• [ ] The commit message follows our guidelines: https://github.com/goetzrobin/spartan/blob/main/CONTRIBUTING.md#-commit-message-guidelines
• [ ] Tests for the changes have been added (for bug fixes / features)
• [ ] Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

• [ ] Bugfix
• [ ] Feature
• [ ] Code style update (formatting, local variables)
• [ ] Refactoring (no functional changes, no api changes)
• [ ] Build related changes
• [ ] CI related changes
• [ ] Documentation content changes
• [ ] Other... Please describe:

Which package are you modifying?

• [ ] accordion
• [ ] alert
• [ ] alert-dialog
• [ ] aspect-ratio
• [ ] avatar
• [ ] badge
• [ ] button
• [ ] calendar
• [ ] card
• [ ] checkbox
• [ ] collapsible
• [ ] combobox
• [ ] command
• [ ] context-menu
• [ ] data-table
• [ ] date-picker
• [ ] dialog
• [ ] dropdown-menu
• [ ] hover-card
• [ ] input
• [ ] label
• [ ] menubar
• [ ] navigation-menu
• [ ] popover
• [ ] progress
• [ ] radio-group
• [ ] scroll-area
• [ ] select
• [ ] separator
• [ ] sheet
• [ ] skeleton
• [ ] slider
• [ ] switch
• [ ] table
• [ ] tabs
• [ ] textarea
• [x] toast
• [ ] toggle
• [ ] tooltip
• [ ] typography

What is the current behavior?

Closes #

What is the new behavior?

Does this PR introduce a breaking change?

• [ ] Yes
• [ ] No

Other information

[jstnjs]

Hey @goetzrobin,

There is still lots to refactor, but I'm wondering about the styling. So brain shouldn't have any styles at all or just some basic styles? Right now there is a lot of basic styles in the brn-toaster.component, is that allowed or what should I do with it? Also should it be moved to tw classes as well? Or is this fine?

I'm thinking about a hlm directive on top of the toaster that adds the [data-styled]=true styling. I think the other styling could be staying in brain. What do you think?

[goetzrobin]

@jstnjs this is interesting. The idea was that brn components are unstyled by default. They never have a dependency in tailwind. I definitely would like to keep that no dependency on tailwind, but I'm not sure that unstyled by default makes sense in this context. Do you know what Sonner does?

[jstnjs]

@goetzrobin Hmm. The sonner has styling by default. There is a prop called unstyled where, if turned on, the toast itself does not have styling. You can add classes in the toastOptions object. But all other stying such as mentioned below, still exists.

Which is what we could seperate between brain and helm, but what about the default transitions, positions (top-left, bottom-right, etc), showing close or action buttons etc? I'm not sure if it makes sense to have it not be included in brain.

[jstnjs]

@goetzrobin Alright for the positions we could use overlayModule and for the default animations we could provide angular animations maybe? Is that allowed? Maybe this could work. For the action buttons we could use props and no styling, idk why I thought that would be a problem.

[goetzrobin]

@jstnjs just wanted to give you a heads up that we migrated to 17.1 to allow for signal input support! Also moved to the project to pnpm and avoid dependency issues with yarn!

[goetzrobin]

@goetzrobin Alright for the positions we could use overlayModule and for the default animations we could provide angular animations maybe? Is that allowed? Maybe this could work. For the action buttons we could use props and no styling, idk why I thought that would be a problem.

do you mean the Angular CDK Overlay? That's what I have been using and would recommend very much! It's supported by the Angular team, takes care of accessibility out of the box and is already a dependency in the project!