search

alloy / ReactNativeExperiments

1 stars 0 forks source link

Making UICollectionView based ‘masonry grid’ component size itself. #2

Open alloy opened 8 years ago

alloy commented 8 years ago

https://github.com/alloy/ReactNativeExperiments/commit/c1e83a336a7ac7c895f0e541e01a47dd235ce23d

What I do is create the collection view + layout (+ view controller) from the shadow view so that I can ask it for its -collectionViewContentSize when the shadow view is asked to determine the view’s size and then later assign it to the component view for hosting.

It works fine, but it feels weird, so just want to check if that’s the best way to do this or if there’s a way I overlooked to access the real component views from the shadow view at the time of layout.

nicklockwood commented 8 years ago

Most of the shadow view methods get called on a background queue, so I wouldn't have thought that it would be safe to instantiate and call methods on a view from within the ShadowView.

For views that need to set their own size, there is a method setFrame:forView: on UIManager that can be called from the main thread and will effectively trigger a layout pass so that the shadow view frame gets synced up with the view frame.

We use it in situations like the RCTRootView being resized when the phone is rotated.

alloy commented 8 years ago

Aha, thanks for the pointer! I’m using that now to change the height whenever the collection view’s contentSize.height changes.

However, the one problem I have with using this is that setting a new frame overrides any styling set from JS, which is not what I want. I only want the content size height to be used if no explicit height or flex styling has been providing. To be able to do this, I had to make some changes to my shadow view’s setFrame: method.

It might be nice if there were a built-in way for RCTUIManager to implement this logic, either by adding a new ‘suggested size’ method or by changing the existing setFrame: implementation of RCTShadowView to check for NaN like I’m doing.

If you agree, and possibly have implementation suggestions, I can make a PR for that.

nicklockwood commented 8 years ago

It's definitely worth putting up a PR on the RN github. Checking for NaN seems like a good approach since it's minimally disruptive to the API.

alloy commented 8 years ago

https://github.com/facebook/react-native/pull/6114