https://learn.staticvar.dev/courses/jetpack-compose-internals/01-what-system-did-compose-build/Recent content in What system did Compose actually build? on Staticvar LearnHugo -- gohugo.ioen-ushttps://learn.staticvar.dev/courses/jetpack-compose-internals/01-what-system-did-compose-build/01-the-compiler-runtime-node-pipeline/Mon, 01 Jan 0001 00:00:00 +0000https://learn.staticvar.dev/courses/jetpack-compose-internals/01-what-system-did-compose-build/01-the-compiler-runtime-node-pipeline/Status: The five boundaries are Durable . Method names and compiler output are Version-specific at the pinned revisions above. This lesson describes a source snapshot, not every released Compose artifact. Release mapping: No released artifact is asserted here. Check the Compose Runtime release notes before mapping these private details to a Maven version. Outcome You should be able to point to the owner of each step: Kotlin source → compiler protocol → composition memory → applied changes → UI nodes That map is more useful than saying that Compose “builds a view.https://learn.staticvar.dev/courses/jetpack-compose-internals/01-what-system-did-compose-build/02-reading-compose-source-as-evidence/Mon, 01 Jan 0001 00:00:00 +0000https://learn.staticvar.dev/courses/jetpack-compose-internals/01-what-system-did-compose-build/02-reading-compose-source-as-evidence/Status: The reading method is Durable . Conclusions about the pinned files are Version-specific . A test proves its inputs, source set, target, and assertions. It does not prove every private detail forever. Outcome When you investigate one Compose mechanism, you should be able to say: where the protocol is declared; which compiler code produces it; which runtime code consumes it; which test observes it; and what history says about its scope.https://learn.staticvar.dev/courses/jetpack-compose-internals/01-what-system-did-compose-build/03-composition-storage-is-runtime-memory/Mon, 01 Jan 0001 00:00:00 +0000https://learn.staticvar.dev/courses/jetpack-compose-internals/01-what-system-did-compose-build/03-composition-storage-is-runtime-memory/Status: The storage/tree distinction is Durable . The selected buffer and class names are Version-specific at the pinned revision. The link-buffer path is Experimental at this revision. Outcome You should be able to answer this question precisely: If composition storage is not the UI tree, what job does it do? It keeps the runtime’s memory of composition structure and values so later work can compare, restart, skip, and update the right places.https://learn.staticvar.dev/courses/jetpack-compose-internals/01-what-system-did-compose-build/04-composition-calculates-applies/Mon, 01 Jan 0001 00:00:00 +0000https://learn.staticvar.dev/courses/jetpack-compose-internals/01-what-system-did-compose-build/04-composition-calculates-applies/Status: The calculation/application split is Durable . Method names and callback ordering are Version-specific at the pinned revision. Outcome You should be able to explain why a successful composition calculation does not mean that the target tree has already changed. Two phases, two questions Composition asks: What operations should happen for this execution? Application asks: How should those operations mutate the target tree? The pinned ControlledComposition makes this boundary explicit.https://learn.staticvar.dev/courses/jetpack-compose-internals/01-what-system-did-compose-build/05-from-node-operation-to-layoutnode/Mon, 01 Jan 0001 00:00:00 +0000https://learn.staticvar.dev/courses/jetpack-compose-internals/01-what-system-did-compose-build/05-from-node-operation-to-layoutnode/Status: The distinction between group calls and node calls is Durable . ComposeUiNode and LayoutNode details are Version-specific at the pinned revision. Outcome You should be able to trace one target-node insertion and explain why a wrapper composable can run without inserting anything. Group work is not node work The Composer protocol has both group operations and node operations. A group records logical composition structure. A node operation asks the applier-owned tree to create, retain, or update a target object.https://learn.staticvar.dev/courses/jetpack-compose-internals/01-what-system-did-compose-build/06-follow-a-state-change/Mon, 01 Jan 0001 00:00:00 +0000https://learn.staticvar.dev/courses/jetpack-compose-internals/01-what-system-did-compose-build/06-follow-a-state-change/Status: The separation between observed state, recomposition calculation, and application is Durable . The controlled API sequence below is Version-specific at the pinned revision. Outcome You should be able to predict which event changes during a state update: the state object is written; an observed scope is made eligible for recomposition; composition calculates pending operations; or the applier mutates the target tree. These are related events. They are not one event called “recomposition.