Fabric API

Fabric API

106M Downloads

The modularization of the Fabric API has gone too far

OroArmor opened this issue ยท 5 comments

commented

The title says it all. We currently have 42 modules in the Fabric API. Often times these modules have somewhat of an overlaping scope. I propose a massive refactor to reduce the number of modules, remove the deprecated modules, and propose higher scrutiny for new modules. Looking through the modules, they often only have a handful of classes, and should be merged into other modules.
My proposed modules:
module: existing modules to include
item : item, itemgroup, tool-attribute, mining-levels, the item section of object-builder (model predicate providers)
block: block-render-layer, block section of object-builder, container
entity: entity-events, villager parts of object-builder
world: biome, dimension, structure, gamerule, (command?), loot-tables, advancements section of object-builder
lifecycle: lifecycle, (command?)
rendering: all rendering apis, particles, textures, models
client: keybinds
screen: screen, screen-handler
registry: registry-sync

Modules that stay:
resource-loader, networking, tag-extensions, crash-reports, and base

This list may not be complete, but i think reducing the number of modules will be an important part of the fabric API moving forward

commented

I have little experience with the rendering apis, but there are 7 modules with the word rendering in them, there has to be a way to combine some of them

the renderer API is fundamentally different from the others.

commented

I think some modules need to be combined. mini modules unless actually justified aren't that efficient with space.

Also less modules -> quicker builds

commented

I agree with most.

But I entirely disagree with the rendering part, renderer-api should stay separate from the other rendering stuff.

commented

I have little experience with the rendering apis, but there are 7 modules with the word rendering in them, there has to be a way to combine some of them

commented

Another criteria for grouping modules imo would be allowing them to break in updates. I hope this can be considered when we try to merge modules, i.e. don't merge frequently changed modules with relatively stable modules. Biomes can stay as it blows up often given mojang's frequent updates.