Cardinal Components API

Cardinal Components API

21M Downloads

Any reason on why giving up V2 API?

yuesha-yc opened this issue ยท 3 comments

commented

Currently I am looking at V3 API and it seems to be much more harder to learn than the V2 API. I am not degrading your effort, I am just curious what drives you to move?

Talking about the static data, I also feel kind of weird on why V3 API require static data while V2 don't. What's the advantage of it?

Thank you for your nice work, of course.

commented

I understand where you are coming from. I have myself my own reservations about the V3 API, as it is indeed a bit more convoluted than previous iterations. However, I believe it is still the right move. The new implementation has 2 considerable upsides:

  1. It is much faster. ASM generation makes using the library as fast as using mixins, fast enough to use in hotspots like rendering. This speed also allows implementing new features like component ticking, which may have previously caused a considerable performance impact. The memory gains also mean common component providers like ItemStacks are less likely to waste visible amount of RAM in large quantities.
  2. The API is really consolidated. Before, for player components, you had to register your component somewhere, register an event in some other place, register a RespawnCopyStrategy elsewhere... And as the number of functionality grew, this too would have become more and more visible. Now you put everything in one class, structure is clear, discoverability is improved too.

The static aspect also fixes some potentially insidious bugs where providers would not get some components if they were instantiated too early (eg. ItemStacks in recipes and creative tabs).

We could of course never remove the V2 API and leave it for those who find it simpler and don't care about performance. However I don't believe this to be a good idea going forward, as it will only increase the maintainance burden. Several people have already expressed an interest in contributing to CCA, but the codebase is a bit messy and difficult to understand because of the need to support 2 concurrent systems. Some of the benefits of the V3 API also cannot be fully exploited until V2 has disappeared.

In the end, I believe it would be more productive to spend time and effort to improve the documentation and teach people how to use the newer, slightly more advanced API, than spend that time on maintaining an old system with marginal gains. To that end, we also need you to tell us what you think is wrong with the current state of things, and how we could help you.

(By the way, if you have repositories that you want to port to the new API, I'll be personally happy to shoot you a PR)

commented

(By the way, if you have repositories that you want to port to the new API, I'll be personally happy to shoot you a PR)

I did it myself yesterday. I would say your reasoning is quite solid and I look forward to see CCA grows better with more people contributing to it and having a less messy codebase. Thank you anyway.

You can keep this issue open if anyone else wants to see this. Or you can just close it ๐Ÿ‘

commented

I think it might as well stay open for a while, as quite a few people may have the same question when they update their mod to 1.17.