Open geoversed opened 7 months ago
We are considering placing everything in one command. So there will be buttons to remove and items instead of making them seperate commands. This isn't definite though.
Update: This has been made definite and will be implemented in this way.
Most of what we said was going to be made was not implemented, simply because of how complex it had gotten. Keeping track of states on every interaction is not easy, and we weren't willing to let the bot keep up with it. It's now stateless and you can no longer change the positioning of items in your showcase. In the end, we just wanted a functional and efficient showcase management system.
We are considering placing everything in one command. So there will be buttons to remove and items instead of making them seperate commands.
This has been on my mind and decided that I'll need to give this a go and keep trying, no matter how much time it takes. I'm reopening the issue to reflect that, and will start working on it some time from now in a seperate PR branch.
Is your feature request related to a problem? Please describe.
This is an issue that requests for the showcase to be rewritten. The way it is stored as well as the algorithms used will be rewritten again entirely from scratch.
Describe the solution you'd like
We want to make a single command that is used to manage your entire showcase. The fundamentals behind how this logic works needs to be firm.
A single callback This function defines the select options that will be displayed along with the logic that returns the embed for what the showcase will look like on the Discord UI. It will also return a list of tuples. It makes a single query to the database that fetches all the item metadata, item ID sorted by its position. This function is called every single time an interaction is made with the view this command is in to invalidate possibly outdated data. No cache systems are built in for the sake of keeping it simple.
Here's the gist of what this function will do:
[(item_id, item_emoji, item_name), ...]
or a dictionary instead (still considering how this will work)Button logic [Not Complete] This will list all the buttons, what they do and how to behave in certain scenarios. The brackets containing Unicode Character indicates that there will be no label on the button, just an emoji representing what it does.
Add Item..
. Allows the user to set an item under this slot. A modal is sent. If all goes well and the user enters a valid item name, add it to the empty slot and replace the select option label and emoji to the selected item. Change the state of this item to the logic of 'Remove Item'.Remove Item..
. Allows the user to remove an item under the selected slot. Since the select menu should hopefully store the ID of the selected item, we make a single query to remove the item at this point. Update the embed and dropdown to display an empty slot at this position. Change the state of this item to the logic of 'Add Item'.Select menu logic [Not Complete] Based on what's selected and where it's selected the buttons to move up and down will be disabled. By default, the first time you view the showcase, you will always have selected the first item (or nothing if it doesn't exist). Therefore, the item should be disabled immediatley when the class is instantiated.
In any callback, whether it be a button or a select menu, should refresh the showcase by checking it again in the database. It doesn't matter if changes weren't made, we call the database for a double check regardless.
Describe alternatives you've considered
None at this time.