Disallow any mutation on ComponentLayout.ContainerBuilder after build() was called

[emilsjolander]

InternalNode#build() (https://github.com/facebook/litho/blob/master/litho-core/src/main/java/com/facebook/litho/InternalNode.java#L1467) just does return this, which implies that we can mutate a ComponentLayout.ContainerBuilder's result after calling build() on it. Add an internal flag and throw an exception if there is an attempt to mutate it after building the layout.

Point of contact: @muraziz

[droidkid]

Hey, was wondering why InternalNode implements both ComponentLayout and ComponentLayout.Builder. Is there any specific reason for this?

Would it make more sense to have one of those classes implemented as a inner/nested class of InternalNode?

If ComponentLayout was a implemented as a inner class, InternalNode.build() could return a new instance of the inner class. The returned object would be immutable. Or similarly, if ComponentLayout.Builder was implemented as a inner class, you get your classic Builder pattern.

Your thoughts? Thanks!

[emilsjolander]

As long as we pool and recycle the builder as well as the bested object I think that would be fine. "Locking" the object when it is built is probably much easier to implement though and serves the same purpose as the InternalNode is not a public class.

[droidkid]

Having a new inner class might be troublesome as ComponentLayout is casted to InternalNode ComponentContext,LayoutState and I'm guessing in a few more places.

Once InternalNode.build() is called, only mutate methods part of ComponentLayout.Builder interface methods should throw an exception right?

For example, in ComponentContext.createLayout, appendComponent() is called on an InternalNode (which had build() called on it). Since appendComponent is not part of ComponentLayout.Builder(), we allow it and don't throw exception.

[pavlospt]

Can be closed since the referencing issue was also closed!