Question related to "Immutable Views" about asyncdisplaykit HOT 6 CLOSED

@RuiAAPeres, thanks for the question! The technology you're referring to from the video is called Components. It can be thought of as a declarative, immutable version of the core concepts behind AsyncDisplayKit, but ASDK predates Components by about two years and they are implemented separately. There is no active work to open source Components, but that doesn't mean it won't happen. The team is currently focused on getting it shipped in the main FBiOS app.

The core difference between the two frameworks has to do with imperative vs declarative design. Components is more similar to React; it is declarative and essentially forces single-directional data flow, often with immutable intermediates that are re-created instead of modified as changes require. AsyncDisplayKit is more similar to UIKit; it is imperative and just like UIView, user input can often change state without completely replacing it with a new immutable object.

As with anything, there are pros and cons of each approach. We've found in practice that declarative code tends to be shorter and more concise, but there is a learning curve because it has a very different "feel" than any experienced iOS engineer will be familiar with. More importantly, part of the point of the declarative model is to limit API surface area and the number of ways in which bugs can be introduced (race conditions, etc)—but sacrificing some of this flexibility does have impacts, particularly on how interactive interfaces and animations are implemented. It's possible to implement animations with Components, but it's often more complex to achieve a polished effect than with an imperative design (and in many other cases, it is not technically feasible).

So, they're useful for different situations. Neither one is perfect for the majority of apps. At the highest level, if your app has a lot of repeated structures and layout rules (think the main feed of Facebook for iOS, which is what Components was directly designed for), with little interactivity and animation, then Components is a huge boon for reducing code complexity and sources of bugs. If you have a highly interactive app with parts of the UI that animate into different states to become new parts of the UI, physics, gestures, etc...it will be between difficult and impossible to use the Components strategy exclusively, so a hybrid approach combining both may be possible.

Let me know if you have any other questions on this.

from asyncdisplaykit.

thanks for the answer @appleguy. I actually got another question: how does Components looks like? As in, is it a class that just encapsulate a piece of a UIView? At first I thought it could potentially encapsulate a CALAyer but then again you need the interactivity (clicking the like button for example). Could you give a brief description about what a Component is and what's its interaction with UIKit? In the end that "Story", that belongs to a "Feed", need to be showed in a VC's root view, correct?

from asyncdisplaykit.

@RuiAAPeres it will be up to the Components team to decide when to release more information than is in the presentation, but Components was partially inspired by the view /or/ layer-backing capability of ASDisplayNode. It is one of the main optimizations that justifies the "abstraction cost" over using basic UIViews. Currently both systems use layer backing only where touch handling is not needed, but it is very possible in both frameworks to later implement a simple touch forwarding system that can actually eliminate that specific requirement. UIViews will remain important in some capacity because they are the main way to support accessibility and a few other features.

Let me know if you have any other thoughts, and then we'll close this task :)

from asyncdisplaykit.

@appleguy I wanted to know a bit more, specially how a .h/interface would look like, plus how is it layered on (hierarchy speaking: (Something -> View -> Layer, etc)). But I understand you guys want to keep this "private" for the time being. Hopefully, we can see more articles related to how you work on Facebook and how has your experience being doing all this stuff. I think you guys are in a unique position to help the community and I am really thankful for all the things you have released. Speaking of articles, where would be the right place to keep an eye on? facebook.com/engineering?

from asyncdisplaykit.

@RuiAAPeres, you can follow the Facebook Engineering blog at code.facebook.com. Also, you might be interested in Ari's comment on potentially open-sourcing Components in the next few months! =]

from asyncdisplaykit.

Thanks @secretiverhyme for the heads up. 👍

from asyncdisplaykit.