feat: added notifications guide

[simonhyll]

Still need to work a bit on it but I'd like some feedback on structure and general direction.

[netlify]

✅ Deploy Preview for tauri-docs-starlight ready!

Name	Link
🔨 Latest commit	76e1a52
🔍 Latest deploy log	https://app.netlify.com/sites/tauri-docs-starlight/deploys/64ecbc1c29802e00070c3563
😎 Deploy Preview	https://deploy-preview-1379--tauri-docs-starlight.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.

[lorenzolewis]

Good start and a lot of points already that should be very good discussion points to set us up for a good foundation.

[lorenzolewis]

Also, just want to gentle put down a hard no on nested Tabs from a UX perspective 🧡 But more than happy to talk through alternatives if you hit a scenario where you think they'd be useful and see what we can come up with together.

So feel free to commit away with them for this but I wouldn't spend too much time on polishing them up

[lorenzolewis]

Here's a component we can start re-using and would be good in a guide like this #1380

[lorenzolewis]

Really loving the way it's shaping up. Aside from the individual comments I also thought of this at a higher level:

I found it straightforward the way @lucasfernog framed frontend/backend in the migration guide: https://beta.tauri.app/2/guide/upgrade-migrate/from-tauri-1/#migrate-to-app-plugin

Putting myself in the shoes of a user I think I'd be able to understand if the "JavaScript" or "Rust" section is relevant to me, rather than first thinking of "what is a frontend" vs. "what is a backend" and going from there. Plus the line above that directly says:

Use in JavaScript or Rust project

That makes it very clear to me that I could use either option and guides me through the right logic path for my scenario (also relevant UX feedback on tabs I put in a detailed review comment here).

Welcome any thoughts and feedback on this if you feel differently 🤗

[lorenzolewis]

Hope you don't mind, but I put a few general updates on this one to adjust the flow and structure.

I noticed the JS notification API with this one blew up like crazy since v1 which I don't think is the right direction for us. I think we should only have the basics like this guide covers so I'll take that one back to the team

[lorenzolewis]

I fully realise this goes against my own UX principals so feel free to rake me across the coals if you don't think it works here @simonhyll 😅

[simonhyll]

I should screenshot this and post on the Astro server 😂

It certainly makes more sense to do it like that if you structure things without the separated Frontend and Backend sections. As I see it it's not actually nested tabs, it's just the ability to switch which package manager you wanna use

Speaking of choosing your package manager, what if when the user switches tabs we save that to LocalStorage so all CommandTabs default to the last one they picked?

[lorenzolewis]

I should screenshot this and post on the Astro server 😂

Please do, I'm sure Chris would get a kick out of it 😆

Speaking of choosing your package manager, what if when the user switches tabs we save that to LocalStorage so all CommandTabs default to the last one they picked?

I believe that's what they've discussed in withastro/starlight#462. If you get bored and want to dive into Starlight land I'm sure HiDeoo would love to have a contribution based on his issue.

[lorenzolewis]

@simonhyll what do you think about this sort of structure? I think this could go a really long way to give link-able places for support

[simonhyll]

I would put Security Considerations further down, feels like the sort of more in-depth topic you read about later on in a post

Not sure what Actions, Attachments or Channels are for? Is it to explain notification concepts or are they general sections that all recipes could have? Options I assume is just a simplified version of what you'd find in the actual API. As long as they aren't too wordy and are copy-paste friendly I'm probably fine with them.

I'm still not overly fond of the terminology of Javascript vs Rust since we should really also have the Rust version avilable using something like Jonas' tauri-sys crate so that the Rust frameworks also get included, because with just JS and Rust (backend) we're kinda leaving them hanging, and I don't see a nice way of adding them without ending up with really annoying names. I'd prefer it if we write about Frontend and Backend as core concepts of Tauri and if people skipped that part then it's not really our problem they refused to read what is almost literally called "the only stuff that's non-optional for you to skip reading". I could also accept Javascript, Rust and Backend I guess because then all frontend languages get included plus one for the backend, but even that isn't completely future proof since we have plans for language bindings at some point.

In the end I defer to your wisdom on the docs in general, so feel free to overrule me on basically anything 😅

[simonhyll]

Note that I read your comments from the bottom to the top and just saw your comment earlier explaining what you meant with Actions, Attachments etc. I'm tired, brain no work 😅

[lorenzolewis]

Open to whatever you feel would be best for security considerations. I figured if there was anything in-depth that would link out either externally or to a concept and maybe not include it in the guide (unless it really is only very specific to that guide/feature).

Actions, Attachment, Channels, and Options are part of the plugins APIs, so really just more copy-pasteable examples:

• Actions: https://deploy-preview-1379--tauri-docs-starlight.netlify.app/2/reference/js/notification/#action
• Attachments: https://deploy-preview-1379--tauri-docs-starlight.netlify.app/2/reference/js/notification/#attachment
• Channels: https://deploy-preview-1379--tauri-docs-starlight.netlify.app/2/reference/js/notification/#channel
• Options: https://deploy-preview-1379--tauri-docs-starlight.netlify.app/2/reference/js/notification/#options

RE: Frontend/backend/rust/js how about we put some data-driven decisions in practice and make a poll we can post to Twitter, Discord, and Mastodon and see what comes out?

I'm still not overly fond of the terminology of Javascript vs Rust since we should really also have the Rust version avilable using something like Jonas' tauri-sys crate so that the Rust frameworks also get included, because with just JS and Rust (backend) we're kinda leaving them hanging, and I don't see a nice way of adding them without ending up with really annoying names.

Literally have never heard of that until today (looks cool!): https://github.com/JonasKruckenberg/tauri-sys. I do wonder if this is really a more advanced-level usage that's outside of the target audience (i.e. beginners) for docs?

---

A piece that maybe just fell in place for me: do you not like "Rust" because you can have both a Rust frontend (yew, sycamore, etc.) and a Rust backend (application logic, what you're truly referring to as backend) in the same app? Because if that's the case then it just clicked for me and your points are a lot more clear to me now.

[lorenzolewis]

Note that I read your comments from the bottom to the top and just saw your comment earlier explaining what you meant with Actions, Attachments etc. I'm tired, brain no work 😅

I mean we've only had like a million comments on this one poor PR the past few days 😅

[simonhyll]

Yea exactly, we want to support our buddies over at the Rust based frontend frameworks, so saying "rust" just for the backend isnt as inclusive

And tauri-sys I would say is the more beginner friendly option than the alternative if you develop using e.g. Yew Leptos or Sycamore. You dont even want to know what the alternative looks like, Jonas really did make aomething awesome and at some point we might wanna make it the actual official approach and "take over" his project. It's kind alike the official JS API but for Rust

[lorenzolewis]

Could you give some examples of how it's different to use the Rust API in Rust frontend code vs. Rust backend code? Might be better to do it outside of the context of notifications where it's a more practical example, but I think that context is what I'm missing.

Keep in mind that for now we're only covering how to do things with the first-party APIs (I don't think you were thinking of putting tauri-sys code in here, and let's talk about it if so, but just wanted to make sure).

---

I do wonder if "covering all the ways to consume the API" is a similar rabbit hole we got into with "cover all the different JS frontend frameworks"? And if we're wanting to say "here's how you do it in x, then here's a common guide on using Tauri within the context of that". But I doubt we want to NEED to document all of these combinations in every single feature/guide 🤔

[simonhyll]

Even if we dont do tauri-sys specifically skipping Rust entirely will leave our beloved rustaceans behind. Using tauri-sys isnt quite the same thing as the framework rabbit hole imo, but if we skip it we should at least offer a "vanilla Rust" example same as we do with vanilla JS

[lorenzolewis]

I agree, but we need the dev team to either do that upstream if it doesn't already, or they need to provide the docs and examples to help us write the guides for it. Right now I didn't find any examples for the Rust side of things to be able to fill it out.

[lorenzolewis]

This is in a shape where I'm happy to merge it as-is. I know we still have a convo around frontend/backend vs. javascript/rust but this is only a label on a tab here that we can very easily change once we have something with more context to make a better decision on this.