Config/container renderers

[0xar-ds]

should be merged after #72

Asked on ResourcefulConfigs' Discord whether they'd like me to PR a few elements to alter how primitives are rendered via @ConfigOption, and they decided that these cases should be kept as renderers on a per-project basis.

Featured Renderers

• Item—a string-backed element, that is to be validated and limited to the identifier of an item found within the elements' registry. The element presents two widgets, a string box for users to directly edit the value, and a button to open a selector which can be filtered by tags. View Gallery
• SlotNumber—a integer-backed element, that is to be validated and limited to the index of an slot found within the provided registered/specified container. The element presents two widgets, a input box for users to directly edit the value, and a button to open a selector which shows a Minecraft-like inventory that can be populated via providers. View Gallery

They'd both be registered as per of 1a57875

Container Renderer

Consumed as:

    @ConfigEntry(...)
    @Comment(...)
    @ContainerSlot(rows = 4, cols = 9)
    // @ContainerSlot(rows = 4, cols = 9, provider = "bazaar:buy_order_amount") with a container provider/the container that is rendered populated
    @ConfigOption.Renderer("bazaarutils:slot")
    public int slotNumber;

The overlay that pops once clicking the edit button calls the declared SlotProvider for each cell/slot it is to build, in that of to allow to represent the container that is relevant to this entry/field:

        SlotProviders.register("bazaar:buy_order_amount", slotIndex -> {
            if (slotIndex < 0 || slotIndex > 35) return ItemStack.EMPTY;

            return switch (slotIndex) {
                case 10 -> SlotProviders.named(Items.PAPER, 64, Text.literal("Buy a stack!"));
                case 12 -> SlotProviders.named(Items.CHEST, 2, Text.literal("Buy a big stack!"));
                case 14 -> SlotProviders.named(Items.CHEST, 16, Text.literal("Buy a thousand!"));
                case 16 -> SlotProviders.named(Items.OAK_SIGN, Text.literal("Custom Amount"));
                case 31 -> SlotProviders.named(Items.ARROW, Text.literal("Go Back"));
                default -> SlotProviders.hiddenTooltip(Items.GRAY_STAINED_GLASS_PANE, 1);
            };
        });

We could also source the features registered to that view and indicate of whether the slot is occupied or not, but the overlay renderer currently does not indicate/nor supports a slot being "locked" by no state.
Implemented as of 4ecf2ef

We should also consider refactors needed on ContainerQuery/SlotLookup/BazaarScreens such that those providers could be built off a single definition we'd have per relevant screen. (Registry-like API maybe?)

Item Renderer

Consumed as:

    @ConfigEntry(...)
    @Comment(...)
    @ConfigOption.Renderer("bazaarutils:item")
    public String itemId = "minecraft:barrier";

The overlay that pops once clicking the edit button contains by default the whole set of items on Minecraft's Registry.

It can be filtered via a tag key that should be annotated on the field that consumes the renderer.

```java
    @ConfigEntry(...)
    @Comment(...)
    @ItemTag("logs") // filter to the items matched by the "logs" tag
    @ConfigOption.Renderer("bazaarutils:item")
    public String itemId = "minecraft:oak_log";

The item registry is currently not augmented by the Hypixel Skyblock items list, but we should look onto that.

Decisions we need to take on what features will consume those renderers

If we're going to allow to modify each item of the mods' features and present on each overlay their relevant data, our data objects (on this case, SmallContainerButton) will have to become a shallow interface (convexed down to current ItemButton interface), for we cannot simply extend it and declare a container provider method because ResourcefulConfig does not walk inheritance to build ConfigObjects— we loss the shared properties.

Some features currently style the item buttons they inject depending on feature state. Notably the item to Bookmark a page, and the Input Helpers that are relevant to a pricing position: do we offer a configuration per each possible state? or do we shift through a item group of ours depending on whether the user has selected a specific item that pertains to the scoped tags? (for example: if the user selects a barrier or smth like that, we just render that item no matter what. but if they choose a glass pane or a glass block, we represent state graphically by shifting through selected subset of that category)

[0xar-ds]

@mkram17 do lmk if you want this pr to also factor in/bring in changes to the features that would consume it, or you want that to be a separate branch/pr

[mkram17]

@mkram17 do lmk if you want this pr to also factor in/bring in changes to the features that would consume it, or you want that to be a separate branch/pr

I would prefer that to be a separate pr if possible

[0xar-ds]

@mkram17 do lmk if you want this pr to also factor in/bring in changes to the features that would consume it, or you want that to be a separate branch/pr

I would prefer that to be a separate pr if possible

It's on my fork, https://github.com/0xar-ds/Bazaar-Utils/commits/feat/consume-container-renderers/, just that I don't have the time right now as to write the pr. Also, the List support should be landing on a release of ResourcefulConfig this same weekend. I'll try and get to merge that consumption/usage here first.

[mkram17]

If we're going to allow to modify each item of the mods' features and present on each overlay their relevant data

I don't think we need to do this honestly. Maybe some features would benefit from this, but in general adding too much customization makes things much more confusing to the average user, and only a small portion of power users would actually use that customization.

Perhaps there are solutions for this though -- expandable settings to hide it somewhat, or an advanced mode for the entire mod. Lmk if you have thoughts on this

[0xar-ds]

but in general adding too much customization makes things much more confusing to the average user, and only a small portion of power users would actually use that customization.

In my opinion complex enums such as PricingPosition are of a bigger clutter to common people? The element themselves are already very contextualized to that of "registering" or "editing" a functionality, so its a mere field to be ignored if not to be of interest. But enumerations of behavior is something that to my opinion is worthy of abstracting to a different constructor (the list/the object would be directly instantiated of that strategy)/users to simply have the speech of "build a feature that follows this order", rather than "configure this feature between a functionality and the other"

2026-03-08.13-42-41.mp4

[mkram17]

2026-03-08.13-42-41.mp4
That looks good. Probably best to leave all the decisions about how to display the ui until right before release anyway.