Project Organization & Submodules

[SD10]

Project Organization & Submodules

Recently, we have been discussing the current organization of the project on Slack.

Basis for the Discussion:

• IBAnimatable is a large codebase and will continue to grow as we add more features.

• We want to limit the amount of unused imported code and decrease the size of the dependency.
  e.g) Using IBAnimatable solely for Transitions yet still having to import all ActivityIndicators

Proposed Solution:

• One possible approach would be to split the project using CocoaPods subspecs.

  For example:

  IBAnimatable would import the entire framework.

  IBAnimatable/Core would import core protocols/components required by other subspecs.

  IBAnimatable/Transitions imports transitions and IBAnimatable/Core

  IBAnimatable/ActivityIndicators imports activity indicators and IBAnimatable/Core

I won't continue listing possible subspecs because they're a rough draft and likely to change.

• I do think the inheritance hierarchy for UIKit could be a good guideline for this:

  e.g) IBAnimatable/UIControls or IBAnimatable/Controllers

Pros:

1. Decreases the size of the dependency for IBAnimatable users and reduces unused imported code.

2. A more modular project is easier to debug, test, maintain, and optimize performance.

3. Working with more modular components would let us take each individual component further without bloating the code base and opens up the possibility for IBAnimatable plugins.

4. It could make supporting other platforms such as tvOS even easier.

Cons:

1. The change in imports could be an API breaking change for many users of IBAnimatable.

• This could be limited by still having IBAnimatable import all subspecs.

2. It would most likely require decoupling some of the framework's components which could also lead to API breaking changes.

[tbaranes]

I agree with the needs here, a few questions:

• How will it works for Carthage, Submodules... ? If one subspecs is a dedicated framework, then it will be straightforward
• How will we name them? If you named it UIControls, does that mean I will have to do import UIControls? It's not quite clear what it represents, but if you named it AnimatableUIControls, it's starting to be long to write.
• When using one module, will I have to important IBAnimatable and UIControls? I think it can quickly become complex to use.
• Should we have one repository by dedicated "subproject" or keep them all in the same? It's quite the same as IBAnimatableMaterial

Beside a few unclear points, I'm totally ok for introducing API breaking change since it will really improve the usage. We will have a big work on installation / migration documentation.

Also, it would be great to list all the modules we need to create to make this real.

[SD10]

Let me address the 4 points you brought up:

1. I have very limited knowledge of Carthage so that's why I didn't mention this. I would love to hear anyone's suggestions on this subject.

2. I think UIControls is a clear name choice. It would never be possible to import something like UIControls directly, it would have the prefix IBAnimatable/UIControls. This import would then import all the other IBAnimatable dependencies that it needs to function.

eg) Firebase currently uses a structure like this:

  - `import Firebase` <- imports all of Firebase

  - `import Firebase/Database` <- imports only Database tools

  - `import Firebase/Auth` <- imports only Auth tools

** If for some reason Auth depended on Database it would be imported by default.
(I think most of point 3 was covered in this)

4. I would prefer we don't split the project into subprojects but rather use this subspec/submodule approach. The reason I'm against creating multiple projects is I think that it can diminish support from the community and make components harder to find. I would like to keep everything in a centralized place.

[tbaranes]

I globally agree with you, I think we can go ahead and make adjustments with the PRs review!

About Carthage: it will simply compiles every shared frameworks schemes found in a xcworkspace / xcodeproj to generate a dedicated framework. Once that done, the user can choose which frameworks to add in its projects. Since designable is broken using Carthage (#354), I don't think we have that much users, but we still need to support it as well as submodules.

[tbaranes]

Second though: I'm wondering if we shouldn't do a feature release before starting this. Otherwise, let's keep make a temporary branch feature/modules where we can merge all the PRs and then releasing it in master when everything is ready to go.

[SD10]

I agree that would probably be the best approach 👍