# Features & Recipes

Compiling a list of which features and recipes should be in the Tauri documentation website 2.0 based on the definitions in [#1334](https://github.com/tauri-apps/tauri-docs/issues/1344):

> ...Features included in Tauri Core
> ...One for each plugin
> ...Any other "recipes"

Lorenzo's Stab at Categorizing with a full belly from dinner

| If the content describes… | …and serves the user's… | …then it must belong to… |
| ------------------------- | ----------------------- | ------------------------- |
| practical steps | study | [a guide](#guide) |
| practical steps | work | [a recipe](#recipe) |
| theoretical knowledge | work | [a reference](#reference) |
| theoretical knowledge | study | [a blog post](#blog-post) |

## Order to write guides

Was thinking about getting us to the actual app and would like to use that as a chance to revise the code and write the guides around it:

- Updater
- Reallllly want to have this in place before we distribute any builds
- This might be a good opportunity to write about mocks or something if needed for the "Run it" button?
- GitHub Action
- To build cross-platform and dog-feed this action
- Would also like to add some things in CI to monitor compile times and binary sizes (and other valuable metrics) from one build to the next
- Deep link (new plugin)

Continue as you were...

- **Guide**: Learning-oriented
- **Android Project:** Information about the structure of the Android mobile project and how you can modify it for your needs.
- **iOS Project:** Information about the structure of the iOS mobile project and how you can develop some custom native functionalities for it.
- **Scopes:** There's a `persisted-scope` plugin, plus since we're removing the allowlist in 2.0 we need to talk a bit somewhere about how you manage scopes in the new system.
- *Lorenzo*: How to cover the plugin is still an open question, but scope and allowlists in general are a good guide topic.
- **Commands:** General information in how Tauri commands work, how you make one, security related questions about it, things like that, already written some on it.
- *Lorenzo*: Depending on how in-depth we go into security and process model, we might also want to split this out into a concept blog post
- **Recipe**: Task-oriented
- **Splashscreen:** Mostly because we have it already in the existing docs I didn't feel like we should get rid of it, there has been questions about how you make it after all. Plus we need to address somewhere how you can accomplish it on mobile devices.
- Lorenzo: From what I understand this isn't a feature in itself but a combination of features to achieve it, right?
- **Reference**: Information-oriented
- **Blog Post**: Understanding-oriented
- **Admin access:** Lots of users struggle with this, just generally understanding how OS permissions work and how you can request running things as admin. From a security point of view we also need to bring it up somewhere I feel about best practises with developing privileged functions, e.g. developing a custom CLI so that in order to perform a privileged action you re-run your own app with admin privileges, but this time just executing a specific action, so you don't need to elevate your entire app to admin. Things like that.

**Plugin Fun**

I'm not sure how to organize plugins tbh.

- **Localhost:** We have a `localhost` plugin, plus we need to talk a bit about security issues with using a localhost server somewhere, a recipe for localhost seems like a good place to do that.
- *Lorenzo*: Cover the plugin like we do the others, but create some "concept" blog posts to cross-link to maybe?
- **Logging (and Tracing?):** Any good app requires logging, we should show people how to use the `log` crate for it. Plus we have the `log` plugin so gotta have a recipe for that.
- *Lorenzo*: Might also be a candidate to write a recipe around
- **Multiwindow:** We have the `window` plugin, and people need to be shown a bit about how you can handle multiple windows in a Tauri app nicely.
- **SQL:** There's an `sql` plugin. Could be smashed together with `Store` and `Stronghold` to form a `Persisting Data` recipe instead.
- *Lorenzo*: Excellent usage of recipes. For the core plugin functionality still have the "not sure how to organize it" feeling.
- **Websocket:** We have a `websocket` plugin, plus we can talk a bit about cross platform limitations as well as security concerns.
- *Lorenzo*: Security concerns maybe in a blog post? Depends on how in-depth we want to go.

The amazing Simon's OG list

- **~~Asset protocol:~~** Was gonna talk about the asset protocol but I think this can slot nicely into `Filesystem`
- **Authentication:** We have an "authenticator" plugin for using hardware keys, we have people needing social sign ins, we have people needing to implement their own login systems so I'd wanna put somewhere in big bold letters where we recommend they store things like their authentication tokens, really all information regarding how you enable logging in with your app and how you store tokens securely
- *Lorenzo*: This is one I really want to dive into but I need to spend a bit of time myself fully wrapping my head around it
- **Errors:** People need to know how to create custom errors and how serde can be implemented for them. They're non-optional to know about if you're doing async programming, so they have to be informed about somewhere, might as well be in a recipe that shows you in practise how to make one.
- **Events:** The event system needs to be talked about, both how global events work as well as window specific events, and how you can set up handlers in both the backend and the frontend for them.
- **Filesystem:** We need to talk about how you're supposed to create files just in general, how you create a file with `std`, how you get the file to the frontend using the asset protocol, how the path resolver works, things like that.
- **~~Process:~~** We have a `process` plugin but it's super basic in terms of what it does, I'm sure we can slot that in somewhere else somehow. It just manages the current process, so the apps own process so you can e.g. exit the app. Both crucial and unimportant at the same time.
- *Lorenzo*: Maybe this is something we can touch on in a "core concepts" type of guide. tl;dr of the important stuff
- **Shell / Sidecars:** There's a `shell` plugin and people really need to know about sidecars since so many people are using Python and Node.js.
- *Lorenzo*: I've never learned sidecar in-depth. Is this maybe a recipe that builds on top of base functionality?
- **States:** Can't stress enough how important these are to talk about, such a nice feature with so little official information on how to use them. I'd like to expand some of their functionality with persisting them and emitting events when changes happen, but that's a discussion for another place. Already written some about it.
- *Lorenzo*: Noted, will make sure we surface this one up high in that fun "curration" process
- **Store:** We have a `store` plugin. See `SQL`.
- *Lorenzo*: need to read through this plugin to understand the cross-over
- **Stronghold:** We have a `stronghold` plugin. See `SQL`.
- *Lorenzo*: need to read through this plugin to understand the cross-over
- **System Tray:** We have system trays and people do seem to love them, gotta tell them how to make them somewhere.
- *Lorenzo*: I need to dig into this a little bit more
- **Window Menu/Titlebar:** You can make native menu's as well as custom ones in a custom titlebar. Gotta put that somewhere.
- *Lorenzo*: I need to dig into this a little bit more

## Original cool stuff from Simon

- **Admin access:** Lots of users struggle with this, just generally understanding how OS permissions work and how you can request running things as admin. From a security point of view we also need to bring it up somewhere I feel about best practises with developing privileged functions, e.g. developing a custom CLI so that in order to perform a privileged action you re-run your own app with admin privileges, but this time just executing a specific action, so you don't need to elevate your entire app to admin. Things like that.
- **Android Project:** Information about the structure of the Android mobile project and how you can modify it for your needs.
- **~~Asset protocol:~~** Was gonna talk about the asset protocol but I think this can slot nicely into `Filesystem`
- **Authentication:** We have an "authenticator" plugin for using hardware keys, we have people needing social sign ins, we have people needing to implement their own login systems so I'd wanna put somewhere in big bold letters where we recommend they store things like their authentication tokens, really all information regarding how you enable logging in with your app and how you store tokens securely
- **Autostart:** We have an "autostart" plugin for starting your app on OS boot.
- **Clipboard:** We have a "clipboard" plugin for handling the OS clipboard.
- **Commands:** General information in how Tauri commands work, how you make one, security related questions about it, things like that, already written some on it.
- **Dialogs:** We have a "dialog" plugin.
- **Errors:** People need to know how to create custom errors and how serde can be implemented for them. They're non-optional to know about if you're doing async programming, so they have to be informed about somewhere, might as well be in a recipe that shows you in practise how to make one.
- **Events:** The event system needs to be talked about, both how global events work as well as window specific events, and how you can set up handlers in both the backend and the frontend for them.
- **Filesystem:** We need to talk about how you're supposed to create files just in general, how you create a file with `std`, how you get the file to the frontend using the asset protocol, how the path resolver works, things like that.
- **iOS Project:** Information about the structure of the iOS mobile project and how you can develop some custom native functionalities for it.
- **Localhost:** We have a `localhost` plugin, plus we need to talk a bit about security issues with using a localhost server somewhere, a recipe for localhost seems like a good place to do that.
- **Logging (and Tracing?):** Any good app requires logging, we should show people how to use the `log` crate for it. Plus we have the `log` plugin so gotta have a recipe for that.
- **Multiwindow:** We have the `window` plugin, and people need to be shown a bit about how you can handle multiple windows in a Tauri app nicely.
- **Notifications:** Already written some on this. We have a `notification` plugin.
- **~~Process:~~** We have a `process` plugin but it's super basic in terms of what it does, I'm sure we can slot that in somewhere else somehow. It just manages the current process, so the apps own process so you can e.g. exit the app. Both crucial and unimportant at the same time.
- **SQL:** There's an `sql` plugin. Could be smashed together with `Store` and `Stronghold` to form a `Persisting Data` recipe instead.
- **Scopes:** There's a `persisted-scope` plugin, plus since we're removing the allowlist in 2.0 we need to talk a bit somewhere about how you manage scopes in the new system.
- **Shell / Sidecars:** There's a `shell` plugin and people really need to know about sidecars since so many people are using Python and Node.js.
- **Shortcuts:** We have a `global-shortcut` plugin.
- **Splashscreen:** Mostly because we have it already in the existing docs I didn't feel like we should get rid of it, there has been questions about how you make it after all. Plus we need to address somewhere how you can accomplish it on mobile devices.
- **States:** Can't stress enough how important these are to talk about, such a nice feature with so little official information on how to use them. I'd like to expand some of their functionality with persisting them and emitting events when changes happen, but that's a discussion for another place. Already written some about it.
- **Store:** We have a `store` plugin. See `SQL`.
- **Stronghold:** We have a `stronghold` plugin. See `SQL`.
- **System Tray:** We have system trays and people do seem to love them, gotta tell them how to make them somewhere.
- **Updater:** We have an `updater` plugin, that info has to be somewhere.
- **Websocket:** We have a `websocket` plugin, plus we can talk a bit about cross platform limitations as well as security concerns.
- **Window Menu/Titlebar:** You can make native menu's as well as custom ones in a custom titlebar. Gotta put that somewhere.