Icon/Position callback.

[ryantheleach]

When using a menu/inventory isn't it more common to want to assign a callback to a position/icon and call that specifically, rather then have a single handler for an inventory?

You could keep the single inventory callback, but use that as a fallback for if an icon/position callback wasn't defined.

This would support dynamic menu's a lot better, because instead of having to rely on decoding an itemstack or position number to work out what was clicked, you could just assign an adapter class for each icon that would then call the method required in your plugin.

[DSH105]

Yeah, I do agree that having the click actions centralised in the inventory handler isn't the most intuitive design. I still, however, would prefer to keep the icons/positions immutable and separate from the central inventory handler. Perhaps it would be more suitable to assign icons to specific action callbacks (.assign(icon, callback))?

I would comment further on this, but at the moment I'm not as familiar with the rest of the InteractAPI (and any possible improvements I had in mind) as I was when it was initially designed.

[ryantheleach]

I've not played with this since I've commented... so maybe? I agree on keeping stuff immutable, it's just good design and allows reuse of the icons. But I do wonder if there is any point in reusing the icons anyway aside from creating new builders from a template, due to it being incredibly unlikely that an icon that looks the same in every way would call a differing callback. So I don't really see why the icon's can't still be immutable and have a reference to the callback?