Separate components into small pods/libs

[rnystrom]

I created the @GitHawkApp org (empty atm) to start storing stuff. Inspired by @BasThomas from #483 (comment) to move small libs into their own pods.

Pros:

• Other ppl can pull them in
• We can version our own stuff

Cons:

• Lots of overhead
• Could slow us down significantly

Existing lib candidates

I think once we have things that are in stable shape, we could put them in their own libs. Some starters that I can think of:

• Tab bar delegate for single and double tapping on items
• Split view VC delegate for expanding/collapsing, showing details, pushing onto nav, etc
• Rating prompt for native and IGListKit inline prompt, as well as managing spacing in between
• Attributed string for sizing and rendering along w/ its view (gesture handling)
• Markdown parsing along w/ MMMarkdown changes
  • This is pretty hairy tho: models, views, IGListKit stuff....
• Spinner cell in IGListKit. This is super super common, nice to generalize
• "Feed" setup
  • Along w/ base list VC
• Smart cell deselection based off of raiz labs

[BasThomas]

FWIW, I think the Split view VC thing might still need some work. Would be nice if it could help us with not forgetting navigation bars and stuff (like in the current TF)

_{Sent with GitHawk}

[rnystrom]

Ya good point, it should be helping w/ that more for sure.

[Sherlouk]

So unwelcomed opinion over here: I'm personally not a fan of completely separating components that are not on their own really re-usable, testable, configurable and convenient especially where most people will want something slightly different.

I feel valid candidates are proper forks of SlackTextViewController, etc where we already have made changes.

Our own version of toaster is also great because on it's own it provides something, is re-usable and is testable on it's own.

An alternative here which I've been practicing at work and has had relatively great success is internal sub-projects. Can treat them likes groups for the most part to have certain more self-contained modules, but they're independently testable, and has the added benefit of not being re-compiled unless they're changed.

I'm personally not a fan of this pick'n'mix approach to pods where everything as small as a single class can come is an extra dependency. Adds a large wall of complexity when trying to do sweeping changes.

[rnystrom]

@Sherlouk yup, that's generally my approach too. A lot of these are pretty tiny, so not really worth the investment unless they are packaged w/ tests and whatnot. Just exploring some ideas!

[BasThomas]

Yep, feel the same @Sherlouk. Should definitely not go overboard with this.

_{Sent with GitHawk}

[BasThomas]

Think this can be closed at this point ^^