@eblade is right: UI is not replicated. UI is for letting the player express what they want.
It sounds like you need a server-to-client replication stream of updates to contents-of-slot of the box. This would presumably run whenever the box changes, no matter whether the user has the box open or not.
If the user happens to have the box open, and slots come and go, then the user will see them update.
Then you want a client-to-server request saying “put thing A in slot B.”
The server would then respond with a message that says "putting thing A in slot B succeeded, " or “putting thing A in slot B failed.”
So, the flow for the client is:
- drag-and-drop shows “red” when a slot is already occupied ON THE CLIENT, but allows dropping when a slot is not occupied ON THE CLIENT
- after drop, the item disappears from the cursor, and should be marked “not currently available for use,” but doesn’t YET appear in the slot. Perhaps some simple animation is played on the cursor.
- when the server responds “item put succeeded,” then the not-currently-available item is removed from the player inventory, and some “success” effect (like a sound and particle system) is played
- when the server responds “item put failed,” then some animation/sound/effect is played to deny the action, and the item is again marked “can be used” in local inventory.
The specific animations/effects you use while the item is in indeterminate state, is up to your game design – could be some kind of flying/zooming animation, could be particle systems, could be sounds, could just be some text in a box on the screen.
The flow on the server is:
- Receive “put item A in slot B” from player P
- Verify that player P has item A. If not, ignore request.
- Verify that slot B is available.
- If it is, put item A there, and send the success response.
- If it is not, send the failure response.
- Regular replication will also let all players know what’s actually in the slots of the box.
Note that the “putting” player may get both “success” messages, and “box contents updated” messages, and may get them OUT OF ORDER, so be prepared to appropriately merge those updates (basically, if the object is already in the slot when you try to put it there, remove it from inventory without needing to update the slot further.)