Library Rewrite

[Luc1412]

Library Rewrite

This PR encompasses the Version 3.0 bump of the Fortnite API Python wrapper. This major transition gives the library a complete facelift, focusing on asynchronous functionality while still supporting the synchronous library you've come to know.

To see how progress is coming along, it's best to check out the Library Rewrite Project and the rewrite's unit tests for the library, as these are the most up-to-date at the moment.

(Edited May 4th, 2024): Progress is coming along fantastic. As we prepare to close out this project, documentation has been the main focus for our users. A complete migration guide has been built from the ground up to ensure a clean transition from Version 2 of the library to the new Version 3. Here's a sneak peek:

All that remains to be completed is working through every aspect of the documentation with a fine-tooth-comb for any improvements in clarity and consistency. The core API should not change much anymore.

(Edited May 7th, 2024): Documentation is posted and can be found here: https://fortnite-api.readthedocs.io/en/rewrite/

(Edited Aug 4th, 2024): Welp, last time I spoke on May 4th I lied. Life happens, what can I say. The project has been completed... at least the code base... actually this time. All that remains is:

• [x] Opt in data fields, pending API update for the Python implementation
• [x] One unresolved discussion regarding helper functions in the POI class.
• [x] Going through all the codebase with a fine-tooth comb for a last review
• [x] Going through all the documentation and migration guide for any needed small changes.

I will update this check list as they get completed. Cheers 🍺

Features and Additions

• Complete overhaul of every object, method, and property in the library. Now, fetching information from the API is done through methods on a FortniteAPIClient and SyncFortniteAPISyncClient class. This is to make the library easier to use and maintain, while still being welcoming for new programmers.
• Complete overhaul of documentation. This includes a major shift to readthedocs powered by Sphinx for easier documentation.
• Speed improvements for large endpoints, such as fetching all available game cosmetics at once.
• Strictly type hinted with high code standards.

[Luc1412]

I think it makes sense to use timezone-aware datetimes throughout the library. This is also a breaking change, that needs to be mentioned in the migration guide.

[Luc1412]

Am currently not sure about the design of creating classes. It's pretty cumbersome to re-create classes, since you always have to pass the HTTP.

Not sure how much it's used, but I work a lot with caching, where I convert the data to json to drop it into redis e.g. fortnite_api.Shop(data=json.loads(before_shop_data), http=self.bot.fortnite_api.http)

However not sure if there is a better design.

[trevorflahardy]

Am currently not sure about the design of creating classes. It's pretty cumbersome to re-create classes, since you always have to pass the HTTP.

This is something that I've brought a lot of thought to. Ideally speaking client.http remains internal, so a helper function on the client may be best to recreate all objects that require a http parameter. Maybe,

obj = client.reconstruct(ObjectType, data)

or some decorator that wraps each reconstructable object,

@reconstructable
class Foo(...):
    ...

foo = Foo.reconstruct(client, data)

This can be typed well with Protocols also, so it still meets the library's type standards. What do you think?

[Luc1412]

This is something that I've brought a lot of thought to. Ideally speaking client.http remains internal, so a helper function on the client may be best to recreate all objects that require a http parameter.

Maybe we rename raw_data to to_dict (or as_dict) and add from_dict (alternatively keep raw_data and add from_data). That from_xmethod got client param and the dict.