Iglistkit: [RFC] Deprecate IGListStackedSectionController

Created on 12 Feb 2018  路  8Comments  路  Source: Instagram/IGListKit

We don't use really IGListStackedSectionController in Instagram, and I've never used it personally. It was more of a science experiment that has turned into more maintenance than I believe is worth.

I've seen others using it, but I'd rather encourage a fork or link to another library that decides to keep support of this controller.

Any major objections?

breaking API change proposal

Most helpful comment

Sorry to be a pain but... objection! I'm using it for profile pages and a few miscellaneous views, where each section shares the same model, but does different things with it. For example, I have a profile page for a music artist that gets a "Profile" model from the server. I use a IGListStackedSectionController to handle the following sections from that profile model:

  • A header image
  • a name and logo
  • a bio
  • music genres
  • upcoming events
  • sample music

This works well at the moment. I guess I could turn it into one massive ListBindingSectionController... If you were to kill IGListStackedSectionController what would be the best alternative way for me to handle this kind of situation?

All 8 comments

+1 馃敧

Sorry to be a pain but... objection! I'm using it for profile pages and a few miscellaneous views, where each section shares the same model, but does different things with it. For example, I have a profile page for a music artist that gets a "Profile" model from the server. I use a IGListStackedSectionController to handle the following sections from that profile model:

  • A header image
  • a name and logo
  • a bio
  • music genres
  • upcoming events
  • sample music

This works well at the moment. I guess I could turn it into one massive ListBindingSectionController... If you were to kill IGListStackedSectionController what would be the best alternative way for me to handle this kind of situation?

Hi, I'm using IGListStackedSectionController for the same use case as @yusuftor and I would love if you could tell me a better way that will help me achieve the same functionality.

You could have one section controller to each section of the profile, so you would end up with 5 or 6 sections controllers instead of only one.

Thats the way I'm doing it and I believe @rnystrom mentioned in an issue that Instagram profile is built this way as well.

@brurend how would that work? If I have for example 5 section controllers, then this means that the ListDiffable array that is returned from the objects(for listAdapter: ListAdapter) of the ListAdapterDataSource should have 5 items. My model consists of one User model that has all the data I need for this view controller. I think that I could create 5 new models that each one of them includes only the data of the User model that it's needed for each section controller and then identify each model in the listAdapter(_ listAdapter: ListAdapter, sectionControllerFor object: Any) and return the correct section controller. Personally, I think that this is too much work for something like this, but if it's the only alternative, I'll go with this approach. Please let me know if I'm missing something obvious.

Take a look at #1035 , the first reply says one way of dealing with a profile like view.

My profile is a little bit simpler than Instagram, so I only needed 3 sectionControllers. The first one being the header with the user info, I used IGListBindingSectionController for this one. The second one I have some buttons and the third one for each grid item under those.

I guess it depends a little in how your layout works, but at worst case scenario if you use a single cell with everything, you would be able to use IGListBindingSectionController without a problem instead of IGListStackedSectionController.

There are a lot of cases in our codebase using ListStackedSectionController, do you have suggestions for the migration?

One way of migrating ListStackedSectionController is using ListBindingSectionController.

The main purpose of the stack SC is to allow multiple SCs to share one master model, while the binding SC is to decompose one master model into multiple sub-models. Usually, each child SC of a stack SC only takes a subset of data from the master model. With this in mind, the migration is obvious: write grab-bag models for child SCs and decompose the mater model into grab-bags with a binding SC.

Was this page helpful?
0 / 5 - 0 ratings