When viewing discussion threads about Fabric (think: /r/ftb), one of the primary concerns I see from Forge developers is related to the lack of events. I think it would be a good idea to start a list of wanted/needed events for people looking to contribute. It would also be a good idea to document which module an event should go into-- we have "interaction," and "lifecycle," but no clear description as to what belongs where (or if new modules should be created for events that fit into other categories). It might also be worth creating a brief overview of how you can determine whether an event should be cancellable or have a special return type.

If we can get some discussion or insight to start here, I can attempt to translate things into a wiki page (unless someone else would prefer to take the wheel on it).

In a lot of cases, mods using events could achieve what they want so much more cleanly with a minute and specific Mixin injection point. The only useful events are ones such as tick events, or any others in hotspots of code that can have callbacks pre-optimized.

Kitten-- while I do entirely agree with your point (and have since before posting this), part of my objective would be to provide a cleaner path for Forge modders to port things to Fabric. There are people who will simply never come over because we don't have as large of an event system as Forge.

If we have the opportunity (and the resources to do so), we might as well just make it easier for people to contribute events, regardless of how much we push or encourage their usage.

IMHO this would be better as a separate, maybe third-party event library, since Fabric itself does not need events (because mixins can be used), and that may help migrating from Forge.

Separating core utilities from the main API into third-party libraries is one of the reasons why we have people still sticking with Forge when a 1.14 loader exists. The unfortunate reality is that as long as we avoid adding a number of standard bundled events, people will avoid Fabric, period. Why would a Forge user switch over and re-create all their events (which their mod relies on) in mixins now, when they could just wait a month or two and use Forge events (which, if we're being honest, are just more convenient than mixins)? At least, these are the vibes I'm getting from Forge-goers on the Fabric threads-- not my personal opinion.

edit: and part of my point is: if we already have some event modules, why not just add more now? We can delete or transfer them to a different library later if needed.

I think a good thing to do would be to see what events people have created in their own mods, this gives us a real use-case to look at.

Also if you have some useful events consider opening an PR.

Fabric doesn't need events for all the reasons offered above, but having a careful selection of events that tend to be used frequently can reduce the volume of support questions and encourage consistent practice.

Given that PRs for events are fair game and each event PR will be considered on its own merits, is this conversation still useful?

Events necessary can be discussed. I agree this seems pointless.

I first wrote it when I was trying to figure out how PRing events to the API worked (and wanted any sort of documentation on it), but I ended up just figuring it out myself. I might write a small wiki article on events later today.

I still want clarification or discussion on additional event modules (because I can't stuff everything inside interactions), but that conversation can start when it's needed.

I don't think attracting Forge modders is a great motivation for changes or additions to Fabric. Couldn't that just result in lots of modders who just want Fabric to be like Forge but on more recent versions?

Programmers are encouraged to write however is idiomatic for the language they are writing in, usually because the idiomatic method is faster and/or cleaner. I would argue that this applies to APIs as well, so if mixins are often cleaner than events, as Kit says, we should encourage their usage. Anyone using Fabric is probably going to need mixins at some point, why not encourage learning them early?

I think events would be best reserved for cases where the mixin is difficult to write, an event is cleaner, or where an event makes optimisation possible.

Well, we just lost the advantage of being on more recent versions. If we want people to even think about porting Forge mods to Fabric (considering forge is now on 1.14), events are basically a requirement. That's more of a side note at this point-- it's not like Fabric's success hinges on whether or not we attract Forge modders, but it's just something to consider.

You are right, though: we don't want to bend over just because Forge modders exist. But the counter-question is "why not?" Events are 2 classes at most. We already have an event module, so it would make sense to fill things out if people are willing to contribute. I'm not suggesting we move manpower over to events, just that we document the process out for new people looking to contribute.

I don't think we'll have to worry about the lack of an incentive to learn mixins anytime soon. Even if we added 25 new events right now, 99% of the requirements for mixins would still exist.

Not an important factor at all, but events also add a small QOL change to development. If I want to test something super quickly (say, add an NBT tag to an item when it's dropped), I'd rather hook onto an event (which is what, 3 lines of code?) as opposed to creating a mixin class, finding a target, adding it to the mixin json file, etc.

edit: and it's also not like we need to come to a conclusion on how we look at events right this moment. I just PRed 2 events-- if they get accepted, awesome! If we decide events are a no-no in 3 weeks, it's 2 classes to delete or migrate. No big deal. The more important part to me now is documenting how events work so people can create their own (regardless of whether or not it's for API usage).