[ASCollectionView] Decoration view support

[alan2080]

I'm using ASCollectionView, it perfect but I want to set BackgroundColor for section. Not like UICollectionView, using layoutAttributesForDecorationViewOfKind:, I cannot set backgroundColor.
I use AsyncDisplayKit 1.9.80.

Thanks team.

[hannahmbanana]

@alan2080: Although we support supplementary nodes, it looks like we don't support decoration nodes.

@Adlai-Holler: Do you know if there are reasons why decoration views would not be able to work?

[alan2080]

Thanks @hannahmbanana . I will find other ways. :(

[Adlai-Holler]

It should be possible to use decoration views with ASCollectionView the same way they're used with UICollectionView: by registering a nib or a class with the collection view and having your layout override -layoutAttributesForElementsInRect: and return some layout attributes for those decoration views.

@alan2080 Could you upload that sample project so we can test it out? cc @hannahmbanana

[appleguy]

@Adlai-Holler - are you sure we don't intercept any calls that are required to provide the decoration view? If not, we probably should; unfortunately the "data space" doesn't match between the calls that UICollectionView would provide and what ASCollectionView does, so it would not always be safe to interpret the requested indexPath if it comes directly from UICV.

On Jul 5, 2016, at 11:22 AM, Adlai Holler notifications@github.com wrote:

It should be possible to use decoration views with ASCollectionView the same way they're used with UICollectionView: by registering a nib or a class with the collection view and having your layout override -layoutAttributesForElementsInRect: and return some layout attributes for those decoration views.

@alan2080 https://github.com/alan2080 Could you upload that sample project so we can test it out? cc @hannahmbanana https://github.com/hannahmbanana
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub #1829 (comment), or mute the thread https://github.com/notifications/unsubscribe/AAigA50gWeLnJ-hCc0OtjsUdiKxpPorzks5qSqDYgaJpZM4JA2Cs.

[Adlai-Holler]

@appleguy Hmm we don't intercept any decoration view calls but we do assert that the layout never returns attributes for them.

I don't believe this is necessary – decoration views are very intentionally walled off from the data source i.e. the presence or absence of decoration views is only determined by the layout based on what items the collection view reports exist. There's no point at which the user's layout object (the only object that involved with decoration views) would need to interpret an index path from the collection view against the data source in an unsafe way. It would be safe if the layout simply registers nibs/classes for decoration views and returns layout attributes for them in layoutAttributesForElementsInRect:.

There's not a method like collectionView:viewForDecorationElementOfKind:atIndexPath:. Nobody, not even the layout, is intended to bind decoration views to the data source.

[appleguy]

OK, very cool! If they’re that separate, it seems like a rare case that we can let them through :)

On Jul 6, 2016, at 8:19 AM, Adlai Holler notifications@github.com wrote:

@appleguy https://github.com/appleguy Hmm we don't intercept any decoration view calls but we do assert that the layout never returns attributes for them.

I don't believe this is necessary – decoration views are very intentionally walled off from the data source i.e. the presence or absence of decoration views is only determined by the layout based on what items the collection view reports exist. There's no point at which the user's layout object (the only object that involved with decoration views) would need to interpret an index path from the collection view against the data source in an unsafe way. It would be safe if the layout simply registers nibs/classes for decoration views and returns layout attributes for them in layoutAttributesForElementsInRect:.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub #1829 (comment), or mute the thread https://github.com/notifications/unsubscribe/AAigA-X2equImXQXZH4dgQ2dBczw4Iccks5qS8dogaJpZM4JA2Cs.

[itjunkii83]

@alan2080 where ever able to get this implemented? If so what workaround did you use?

[Adlai-Holler]

@alan2080 @itjunkii83, @craighowarth has disabled our assertion against layout attributes for decoration views, and so decoration views are now usable with ASCollectionNode in the same way that they're used with UICollectionView – register a class or nib for each decoration view kind.

For example, if you wanted to show an AHSparkleNode for decoration views of kind AHDecorationKindSparkle, you might create a class like:

@interface AHSparkleDecorationView : UICollectionReusableView
@property (nonatomic, strong) AHSparkleNode *sparkleNode;
@end

@implementation AHSparkleDecorationView

- (instancetype)init
{
  if (self = [super init]) {
    _sparkleNode = [[AHSparkleNode alloc] init];
    // Configure the sparkle node always to fill our bounds.
    _sparkleNode.frame = self.bounds;
    _sparkleNode.autoresizingMask = UIViewAutoresizingFlexibleWidth | UIViewAutoresizingFlexibleHeight;
    [self addSubnode:_sparkleNode];
  }
  return self;
}

@end

And then in your view controller, do something like:

- (void)viewDidLoad
{
  [super viewDidLoad];
  [self.collectionViewLayout registerClass:[AHSparkleDecorationView class] forDecorationViewOfKind:AHDecorationKindSparkle];
}

Please reopen this issue or DM me on Slack if this doesn't work perfectly for you. Cheers!

[itjunkii83]

Sweet!!!! I'll be testing it out this week and will post if I have any issues.

[edelibasi]

@itjunkii83 Hey man did you get it to work? I'm having a similar issue.