Earlier quoted context omitted.
Any way to get early access for a huge React fan?
Early access? It's already public! https://github.com/facebook/componentkit
ComponentKit by Facebook: A React-Inspired View Framework for iOS
51–56 of 56 posts
Re: ComponentKit by Facebook: A React-Inspired View Framework for iOS
#52This looks really cool. However, there were a couple odd things about the talk. If you're going to spend so much time talking about managing mutation of data in a multithreaded environment, you should at least mention GCD and explain why it doesn't figure in the list of possible solutions to the problem. But the talk proceeded as if GCD did not exist, listing a few straw man bad solutions, but not the obvious go-to s…
Actually ComponentKit is built on GCD! https://github.com/facebook/componentkit/blob/master/Compone... GCD is fantastic—one of my absolute favorites. We're trying to solve a problem one level above that: exposing an API that doesn't require every view developer to know the details of managing GCD queues and updating a UICollectionView. As for Autolayout, it's very powerful but isn't performant enough for layouts as c…
Did you try Auto Layout with a flattened view hierarchy? Deeply nested view hierarchies are not really the best way to go if there are performance issues. You can get huge speedups by flattening things. I have a feeling this could even work within the ComponentKit way of doing things.
Re: ComponentKit by Facebook: A React-Inspired View Framework for iOS
#53> (Don't confuse ComponentKit with React Native, a framework for building apps in Javascript.) As long as they can't describe it without citing React, this is going to confuse people. At the very least, the logline should mention Obj-C/Swift/Cocoa to differentiate the projects.
Re: ComponentKit by Facebook: A React-Inspired View Framework for iOS
#54This looks really cool. However, there were a couple odd things about the talk. If you're going to spend so much time talking about managing mutation of data in a multithreaded environment, you should at least mention GCD and explain why it doesn't figure in the list of possible solutions to the problem. But the talk proceeded as if GCD did not exist, listing a few straw man bad solutions, but not the obvious go-to s…
For the mem-models portion we also use GCD all over the place. However when we had mutable models (and used Core Data) we had data races, something GCD can't really help you. Moving to immutable models actually makes our system work really well with GCD because you can pass immutable objects around threads without much concern really.
For autolayout, we did some explorations and ultimately decided (especially for low-end devices) that having our layout calculations occur on the main-thread was too cpu-intensive for some of our more complex-layouts (which are quite common in feed).
Before mem-models we explored what the best cutting-edge practices were in using Core Data but ultimately we were using it as a cache and not as an ORM - wrong tool for the job.
Before components we looked at vanilla UIKit, re-approaching an MVC-style architecture given the lessons we had learned, and using Autolayout instead.
I hope this provides a little more insight.
Re: ComponentKit by Facebook: A React-Inspired View Framework for iOS
#55Earlier quoted context omitted.
Early access? It's already public! https://github.com/facebook/componentkit
It was a question about React Native.
Re: ComponentKit by Facebook: A React-Inspired View Framework for iOS
#56This looks really cool. However, there were a couple odd things about the talk. If you're going to spend so much time talking about managing mutation of data in a multithreaded environment, you should at least mention GCD and explain why it doesn't figure in the list of possible solutions to the problem. But the talk proceeded as if GCD did not exist, listing a few straw man bad solutions, but not the obvious go-to s…
We actually use GCD a lot. In components we use a background queue for allocating and measuring/laying-out component trees and then we punt them over to the main queue for "mounting" (attaching them to UIViews that we create or recycle and configure). For the mem-models portion we also use GCD all over the place. However when we had mutable models (and used Core Data) we had data races, something GCD can't really hel…
Thank you so much for bestowing that insight. But I think you should read the docs on dispatch_barrier_sync() and dispatch_barrier_async() before claiming GCD couldn't have helped with the problems you were seeing in your code base.