Export useMenuContext

[LoganDark]

These are facts:

• Context menus exist
• Hover menus exist (though whether or not they are a good practice is debatable)
• Other types of menus exist that aren't dropdowns or aren't triggered by a left click on a button

If you try to fight me on this, I will just close the PR and continue using my fork. This is required functionality. There is absolutely no reason that it should be completely impossible to open a menu by doing anything other than pressing a button. There are valid use cases that you haven't thought of, and this library is currently making them impossible.

I should not have to copy and paste code from Headless UI into my codebase, I should not have to make forks thinking that these issues will never be solved, and I should not have to make strongly-worded PRs. This is an incredibly bad image for the project and the organization.

Making PRs should be a friendly and fun process but my experience with contributing to your repositories has been nothing but bad. In general, the hostility that tailwindlabs has towards outside contribution is extremely offputting. If I had known this would be so hard for me and everyone else, I would have used another UI library. But right now, I need this functionality, and if you don't accept it I will have to use my fork forever, just like with heroicons.

Please at least take a step in the right direction and merge this PR so that others can benefit from this fix.

Fixes #130
Fixes #146
Fixes #894

[vercel]

@LoganDark is attempting to deploy a commit to the Tailwind Labs Team on Vercel.

A member of the Team first needs to authorize it.

[adamwathan]

Hey — I don't know where these accusations of being "hostile" come from, I've looked through every past interaction we've ever had and never seen any examples of hostility from my side.

I understand that you are frustrated this library doesn't do everything you need it to do, and that in other cases you have been frustrated because it can take a long time to get a response on an issue or have a pull request reviewed and merged. This isn't hostility — it's just the reality of having a small group of people working on many different things. We have limited time and resources, so like anyone else we have to prioritize, and in most cases managing community contributions on GitHub ends up lower on that priority list than the things we need to push forward to continue making our projects sustainable and allow everyone to make a living.

In cases like this, it can take a lot of decision-making energy to decide what to do about this change. We have to decide if we are prepared to commit to this being a public API that we can no longer change without it requiring a major version bump, we have to decide if we want to improve the API before doing that, we have to think through if there are any negative consequences to exposing the API, and then we have to write the documentation for the new API.

We also have to decide if we are willing to maintain this API going forward, because even though it was first submitted by you, we are the ones who are on the hook to deal with it after it's merged.

You are more than welcome (and encouraged) to maintain your own fork if there are changes you want to make to the library. That is the whole point of releasing MIT-licensed open source — it's a gift to the world that people can do whatever they want with. If it doesn't do exactly what you need but it's a useful starting point, then fork it and use it as a starting point. Surely that's better than having to do it completely from scratch right?

We all work really hard to make these projects as good as we can, react quickly to major problems, and be helpful in the community. At the end of the day though there is only so much time, and not everything can be addressed with an equal level of urgency. I'm not going to apologize for that, or allow the people on the team to be made to feel stressed out or like they are failing because of someone with a condescending and entitled attitude on GitHub though, so if you can't accept that and participate in an understanding and constructive way, I don't want you here.

I agree it would be great to make improvements to support context menus. That wasn't a goal of this component when it was designed, but hopefully it's something we can explore in the future. For now I'm going to close this as exposing the menu context is not how we would like to solve this problem and we're not prepared to treat that as a public stable API.

[LoganDark]

I have a product to ship and I don't have much time either to deal with deficiencies like these, so I apologize if my comments do feel overly "condescending and entitled". The original draft of this pull request included something along the lines of "I'd be fine with an alternative solution but only if it serves my use case", which felt a bit too harsh to include (even if the rest of the PR is already quite strong).

If one day Headless UI gains official support for context menus, I will move over to that.