Maybe we can expose this as a function that takes a menu id and menu data as an alternative to returning menuEntityData. The MENU_KIND and MENU_POST_TYPE aren't expected to change.

I also discovered recently that there's a useEntityProp hook, that works similarly to useState, so that wrapping that in some way might also be an option.

I guess to elaborate more, I'd consider menuEntityData as configuration that can be kept internal to useMenuEntity.

Instead of returning it the hook could return a partially applied version of editEntityRecord so that implementers don't have to worry about passing the MENU_KIND and MENU_POST_TYPE arguments.

Just to also mention that there are other ways of achieving this too.

• We might consider moving some of this to the edit-navigation store—an action in the navigation store can dispatch actions on another store. Selectors can also select from other stores. We could expose an editMenuName action and a getEditedMenuName selector for convenience.

• Or there's the useEntityProp hook that I mentioned (https://github.com/WordPress/gutenberg/blob/trunk/packages/core-data/src/entity-provider.js#L74-L117), that provides an easier way to edit individual properties. We could also consider partially applied versions (e.g useMenuEntityProp, or maybe even useMenuEntityName/useMenuEntityLocation) of this hook for convenience.

I have created a separate issue for this #30442

I like the idea of useMenuEntityProp. Happy to create PR and update existing code.

Excellent @Mamaduka if you find the time to squeeze that it would be lovely 🙏

Done #31132 ✅