feat(example): rework menu examples#15684
Conversation
Package Changes Through 56dcc2aThere are 14 changes which include tauri with minor, tauri-cli with minor, @tauri-apps/cli with minor, tauri-bundler with minor, tauri-utils with minor, tauri-build with minor, tauri-macos-sign with minor, tauri-runtime-wry with minor, tauri-runtime with minor, tauri-codegen with minor, tauri-macros with minor, tauri-plugin with minor, tauri-driver with minor, @tauri-apps/api with minor Planned Package VersionsThe following package releases are the planned based on the context of changes in this pull request.
Add another change file through the GitHub UI by following this link. Read about change files or the docs at github.com/jbolda/covector |
|
Svelte seems to insert comments to the DOM as anchors that simply can't work well with SortableJS... Edit: did a workaround in d6b562d to always re-create the menus after sorting (referencing sveltejs/svelte#11826 in case someone else stumbles onto this as well) (I still want to stick with SortableJS since it is the best working drag and drop library I have tried so far) |
|
I'm still seeing constant memory increases when I spam re-creating the menus, even with the changes from #15679 applied 🤔 From some testing, the handles should be properly freed as well as the resources in the resource table 🤔 The code I used to test const sleep = (ms: number) =>
new Promise((resolve) => setTimeout(resolve, ms))
const items = [await MenuItem.new({ text: 'test' })]
for (let index = 0; index < 10_000; index++) {
const menu = await Submenu.new({
text: 'app',
items
})
await menu.close()
await sleep(10)
}
for (const item of items) {
await item.close()
}the rust equivalent doesn't reproduce the leak let item = MenuItemBuilder::new("test").build(&app)?;
for _ in 0..1_000_000 {
SubmenuBuilder::new(&app, "submenu").item(&item).build()?;
} |
|
Anyways, we can do that later, the rework itself is ready and should not leak when we fix the underlying issues. |
|
@FabianLars I am so not used to tailwind, am I supposed to add in CSS variables like we normally do or just spam |
|
idk either 😂 |



Depends on #15675
The primary reason for building this is to understand where our docs are lacking and which part of the APIs are not ergonomic enough.
I feel like the ownerships of menus are quite confusing, especially from the JavaScript side. The menus are reference counted that means if you have:
when you close
Menu,Item 1andItem 2are also released, but if you somehow got a reference to one of them left, either it's shared to another menu, or you forget the one you get from aMenu.get, you have a leak.This is something we should definitely improve the docs on
preview of the change:
video.mp4