Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

catalog.roblox.com endpoint support #111

Draft
wants to merge 6 commits into
base: main
Choose a base branch
from

Conversation

tomodachi94
Copy link

@tomodachi94 tomodachi94 commented Dec 23, 2023

This adds support for the catalog.roblox.com endpoint. Related changes include:

  • Bumping Python to 3.8 (discussion in RoAPI Discord)
  • The introduction of two new classes for catalog items, CatalogItem and LimitedCatalogItem.
    • Limited items contain special attributes not present in a normal CatalogItem, so I figured a separate class would aid in maintainability.
  • Modifying partials.partialuser and partials.partialgroup to include two new classes that handle user/group data from this endpoint.
  • A new exception class, exceptions.CatalogItemNotFound.
  • Two new functions in client.Client, get_catalog_items and get_base_catalog_items.
    • Do we want singular variants of these functions for consistency? Something like get_catalog_item and get_base_catalog_item.
  • (I think that's it?)

Things left to do

  • Finish documentation for CatalogItem and LimitedCatalogItem
  • Double-check that I imported everything in all the right spots
  • Identify other potential values for catalog.CatalogItemTypes
  • The following endpoints:
    • categories
    • subcategories
    • asset-to-category
    • get-topics
    • more?


self._client: Client = client
self.id: int = catalog_item_id
self.item_type: int = catalog_item_type
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where is this coming from?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was in the process of converting the itemType stuff to a class, I committed this on accident before the rest was ready

roblox/bases/basecatalogitem.py Outdated Show resolved Hide resolved
from ..client import Client


class BaseCatalogItem(BaseItem):
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

catalog items are either bundles or assets. This approach of one unified class makes it impossible to invoke methods that BaseAsset or a hypothetical BaseBundle would support even when applicable. Maybe forego this class entirely, introduce a BaseBundle (which we need anyway), and make "catalog items" just a BaseAsset | BaseBundle union? Or, instead of a union, both could derive from a new BaseCatalogItem class with a @property that indicates what "type" of catalog item it is (asset or bundle) determined by isinstance(self, BaseAsset): "asset" etc. not sure.


Attributes:
id: The item ID.
item_type: The item's type, either 1 or 2.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Make an enum for this: Asset or Bundle.

roblox/catalog.py Outdated Show resolved Hide resolved
roblox/client.py Outdated Show resolved Hide resolved
catalog_item_data = catalog_item_response.json()
catalog_list: Literal[CatalogItem] = []
for catalog_item in catalog_item_data:
if data["collectibleItemId"]: # This is the only consistent indicator of an item's limited status
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are still "classic Limiteds" that are not collectibles, which makes this inaccurate. Either way, I think just ditch the two classes and go with one CatalogItem class for both. Makes more sense to me even if the Python type system might not be able to imply that multiple properties must exist if one does. If we end up keeping this, call it a CollectibleCatalogItem instead for accuracy.


return catalog_list

def get_base_catalog_items(self, catalog_item_array: List[TypedDict[catalog_id: int, catalog_item_type: Literal[1, 2]]]) -> List[CatalogItem]:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ditch the typeddict with the first comment's solutions, ditch the 1,2 for the enum

catalog_list: Literal[CatalogItem] = []

for catalog_item in catalog_item_array:
catalog_list.append(BaseCatalogItem(client=self, data=catalog_item))
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

for code quality and appearance, use a list comprehension here: return [BaseCatalogItem(client=self, data=catalog_item) for catalog_item in catalog_item_array]

@@ -79,3 +79,25 @@ def __init__(self, client: Client, data: dict):
super().__init__(client=client, data=data)

self.previous_usernames: List[str] = data["previousUsernames"]


class CatalogCreatorPartialUser(PartialUser):
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think a new class is warranted here. I think, unless it has extra fields, all PartialUser-shaped objects should just be PartialUsers. Maybe PartialUser could optionally take fields directly , like PartialUser(client=..., id=..., name=..., has_verified_badge=...) so we don't have to make more classes.

I fixed most of the things that won't require huge fixes. I still have a lot of work to do on this PR, but this is a start.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants