How to Use and Basic API Structure

One of the first questions I usually get when people look at my mods' APIs is "What is this? It's all interfaces!" And they're right. Fireplace Lib uses the Dependency Injection design pattern through Annotated DI (included in Fireplace Lib). If you're going to be working with it a lot, I recommend reading the info from the Annotated DI wiki. Now on to how the API works. To start off with, the API is structured in a specific way. Within dev.the_fireplace.lib.api, there are packages for different areas of the API. Inside each of those, we may have one or more of the following packages:

• injectables
• interfaces
• entrypoints (fabric/quilt)
• events
• exceptions

Generally, I try to name my classes, functions, and parameters in a way that it's easy to understand without requiring a comment block above each of them, so browsing through the injectables and entrypoints should give a pretty good idea what to expect. If anything is unclear, don't hesitate to reach out and I'll see what I can do to clarify it.

Injectables

Injectables are the heart of the mod. These are interfaces for functionality that you can use to interact with Fireplace Lib. In short, each of these is implemented within the mod, but all you should interact with is the interface - don't worry about what goes on under the hood. They are stable, and may only break with a major version change (As of right now, the next breaking change would be Fireplace Lib 8.0.0 - which I currently have no plans to make). If you're just looking for a quick way to use one of these and aren't planning a lot of interactions with my mods, the simple solution is to use SomeInjectableInterface thisInterface = DIContainer.get().getInstance(SomeInjectableInterface.class); to get an instance of that interface then use it for your needs. If you're making an add-on for one of my mods or just looking to use Fireplace Lib as the library for one of your mods, I encourage reading the more in depth explanation of how to use Dependency Injection and Annotated DI. Injectables should not be implemented outside of the mod whose API they belong to. That is to say, do not write class MyModsClass implements SomeInjectableFromAnotherMod.

Interfaces

These are generally used for passing data into or out of injectables. If used for passing data in, you may need to implement it somewhere, or retrieve an instance from somewhere else in the API. Usually though, they are used as return values from functions in injectables, in which case they are also a layer of abstraction between your mod and the underlying implementation, which also improves stability. Generally you won't need to implement these, unless you don't see any obvious way to get one as the return value from the injectable (I try to avoid making other mods implement my interfaces). If you're not sure, feel free to ask.

Entrypoints

Anyone familiar with Fabric modding should be familiar with entrypoints. However, if you're not familiar or just need a refresher on them, see this wiki page. This package is where my mods' entrypoints can be found.

Exceptions

This one is fairly uncommon, but there are a few cases where they are needed. This is the one package that won't just be interfaces, because the exceptions extend Exception. Essentially, the only time you'll see this is if an API function throws an exception that needs to be caught.