• 출처: https://developer.android.com/jetpack/compose/lifecycle?hl=ko

Composable

• 컴포저블 함수에서 사용되는 어노테이션
• Jetpack Compose를 구성하는 함수의 이름
• 선언형 UI의 최소 단위

  Composition

• 컴포저블 함수가 화면에 그려지기 위한 전체의 과정
• 제일 처음 그려지는 1회의 과정

  Recomposition

• 컴포지션의 내용이 수정되어 화면의 내용을 고치는데 그 동작을 말함

Lifecycle

• compose는 각 인스턴스가 각자의 생명주기를 가진다

  호출 사이트를 이용한 구분

  @Composable
  fun LoginScreen(showError: Boolean) {
    if (showError) {
        LoginError()
    }
    LoginInput() // This call site affects where LoginInput is placed in Composition
  }
  

@Composable fun LoginInput() { /* ... */ }

![](https://velog.velcdn.com/images/manjee-official/post/1106822f-7ade-4c56-96be-01fd80e71795/image.png)
- showError이 true로 변경되어 리컴포지션이 발생해도 LoginInput이 새로운 인스턴스로 생성되지않는다
#### 실행 순서를 통한 구분

@Composable fun MoviesScreen(movies: List) { Column { for (movie in movies) { // MovieOverview composables are placed in Composition given its // index position in the for loop MovieOverview(movie) } } }

```

• 순서를 통해 데이터를 추가하는 경우 인스턴스가 순서에 맞게 생성된다
• 중간에 내용이 추가되거나 제일 처음에 추가하는 경우에는 모든 인스턴스가 리컴포지션됨!

  키 값을 이용한 구분

• 식별자를 이용해 구분한다면 리스트에 제일 처음에 데이터가 추가되어도 전체적인 Recomposition을 하지 않는다

이벤트, 상태

이벤트

• UI의 일부에서 이벤트를 발행해 위로 전달
• 뷰 모델에서 처리하는 버튼 클릭, 사용자 세션의 만료를 표현하는 앱의 다른 레이어에서 전달되는 이벤트

  상태 갱신

• 이벤트 핸들러가 상태를 바꿈

  상태 표시

• 스테이트 홀더가 아래로 전달한 상태를 UI가 표시함

단방향 데이터 흐름의 장점

• 테스트 가능성: 상태를 표시하는 UI와 상태를 분리하면, 둘을 분리해 쉽게 테스트할 수 있음
• 상태 캡슐화: 상태가 한곳에서만 갱신될 수 있으면, 일관되지 않는 상태 때문에 발생하는 버그를 줄일 수 있음(SSOT)
• UI 일관성: StateFlow와 LiveData와 같은 관측가능한 상태 홀더를 사용해 UI에 상태 갱신을 즉각 반영할 수 있다.

Compose의 단방향 데이터 흐름

• 컴포저블은 상태와 이벤트에 따라 동작
• 컴포즈는 값 홀더로 State 객체를 정의, 상태 값의 변경을 리컴포지션을 유발함
• remember, rememberSaveable로 상태를 저장한다
• mutableStateOf는 Compose가 관측할 수 있는 타입은 MutableState를 만듬 -> 값이 변경되면 값을 읽는 모든 컴포지션 함수의 리컴포지션을 준비함
• remember는 객체를 컴포지션에 저장하고, remember를 호출한 컴포저블이 컴포지션에서 제거될 떄 객체를 잊어버림
• rememberSavable은 객체를 Bundle에 저장해 configuration이 변경되어도 유지함

부수 효과란?

• 구성 가능한 함수의 범위 밖에서 발생하는 앱 상태에 관한 변경사항
• 컴포저블의 수명 주기 및 속성으로 인해 컴포저블에는 부수 효과가 없는 것이 좋으나 특정 상황에 필요한 경우가 있음

LaunchedEffect

• 컴포저블의 범위에서 정지함수를 실행
• 컴포저블 내에서 안전하게 정지함수를 호출하기 위해 사용

  rememberCoroutineScope

• 컴포지션 인식 범위를 확보하여 컴포저블 외부에서 코루틴 실행
• 컴포저블 외부에 있지만 컴포지션을 종료한 후 자동으로 취소되도록 범위가 지정된 코루틴을 실행하기 위해 사용

  rememberUpdatedState

• 값이 변경되는 경우 다시 시작되지 않아야 하는 효과에서 값 참조
• 주요 매개변수 중 하나가 변경되면 LaunchedEffect가 다시 시작됨. 하지만 경우에 따라 효과에서 값이 변경되면 효과를 다시 시작하지 않을 값을 저장해놓을 수 있음.
• 상태 자체는 기억되어 있지만 값을 새로운 값으로 업데이트 되어 있음

  DisposableEffect

• 정리가 필요한 효과
• 키가 변경되거나 컴포저블이 컴포지션을 종료한 후 정리해야하는 경우 사용

  SideEffect

• Compose 상태를 비 Compose 코드에 게시

  produceState

• 비 Compose 상태를 Compose 상태로 변환

  derivedStateOf

• 하나 이상의 상태 객체를 다른 상태로 변환
• 해당 함수를 사용하면 계산에서 사용되는 상태 중 하나가 변경 될 때만 계산이 실행됨
• 불 필요한 리 컴포지션 호출을 방지할 수 있다.

  snapshotFlow

• Compose의 상태를 Flow로 전환 (State 객체를 콜드 Flow로 변환)
• 이전에 방출한 값과 다를 경우에 방출한다.

출처 - https://developer.android.com/jetpack/compose/side-effects?hl=ko#snapshotFlow

• 앱의 UI를 설명하는 컴포저블의 트리 구조 (UI가 어떤 형태로 이루어졌는지 기술)

  초기 컴포지션

• 처음 Composable를 호출했을 때 만들어짐

  리컴포지션

• 초기 컴포지션 이후 UI의 상태가 바뀔 때 마다 다시 그려지는 과정
• 상태가 변경되면 리컴포지션이 트리거됨

  리컴포지션 스킵

• 두 인스턴스 equals 결과가 같을 경우
• 공개 프로퍼티가 변경되면 컴포지션에 알려야함
• 모든 공개 프로퍼티는 안정적이어야함
• @Stable이 표기되지 않아도 Compose 컴파일러가 안정적이다라고 간주하는 공통 타입들 (모든 프리미티브 타입, 문자열, 모든 함수 타입 (람다) -> 안정적이라고 추론할 수 없는 경우 @Stable 표기
• MutableState는 안정적 (State의 value 프로퍼티 값 변경을 알려주기 때문

  컴포즈 렌더링 단계

  

일관되게 사용하기

• 이름을 일관되게 작성한다, 내가 사용한 이름이 다른 외부에서도 사용했던 이름이라면 사용자 들은 해당 기능을 사용하기 전에 학습해야할 양을 줄일 수 있다

  약어 사용을 피한다

• 약어가 일반 단어보다 일반적인 경우가 아니라면 사용하지 않는 것이 좋고 사용하는 경우에는 대문자로 올바르게 표시한다

  // good case
  pageCount
  buildRectangles
  IOStream
  HttpRequest
  

// bad case numPages // "Num" is an abbreviation of "number (of)". buildRects InputOutputStream HypertextTransferProtocolRequest

### 이것이 무엇인지 가장 잘 보여줄 수 있는 명사를 마지막에 표시한다

// good case pageCount // A count (of pages). ConversionSink // A sink for doing conversions. ChunkedConversionSink // A ConversionSink that's chunked. CssFontFaceRule // A rule for font faces in CSS.

// bad case numPages // Not a collection of pages. CanvasRenderingContext2D // Not a "2D". RuleFontFaceCss // Not a CSS.

### 코드가 문장처럼 읽히도록 하라
```dart
// good case
// "If errors is empty..."
if (errors.isEmpty) ...

// "Hey, subscription, cancel!"
subscription.cancel();

// "Get the monsters where the monster has claws."
monsters.where((monster) => monster.hasClaws);

// bad case
// Telling errors to empty itself, or asking if it is?
if (errors.empty) ...

// Toggle what? To what?
subscription.toggle();

// Filter the monsters with claws *out* or include *only* those?
monsters.filter((monster) => monster.hasClaws);

명사구를 사용한다

• 비동기 코드는 future와 같은 추상화를 사용하더라도 읽고 디버깅하기 쉽지않다 -> async/await를 사용하면 문법의 가독성 향상과 비동기 코드에서 Dart의 모든 흐릅 제어문을 사용할 수 있다

  Future<int> countActivePlayers(String teamName) async {
  try {
    var team = await downloadTeam(teamName);
    if (team == null) return 0;
  
    var players = await team.roster;
    return players.where((player) => player.isActive).length;
  } catch (e) {
    log.error(e);
    return 0;
  }
  }

  필요가 없다면 async를 사용하지 않는다

• 메소드의 동작을 변경하지 않고 async를 생략할 수 있다면 사용하지 않는게 좋음

  Future<int> fastestBranch(Future<int> left, Future<int> right) {
  return Future.any([left, right]);
  }

  async가 유용한 경우

• await를 사용할 때

• 에러를 비동기적으로 반환할 때, async와 throw를 함께 사용하는 것이 return Future.error(...)보다 간결함

• 값을 반환하고 있지만 명시적으로 Future 사용을 원할 때, async는 Future.value(...) 보다 간결함

- 지역 변수에 var과 final을 사용할 때 일관된 규칙을 따른다

- 계산이 가능한 값들을 저장하는 것을 피한다

멤버

- 필드에 불필요한 getter와 setter를 생성하지 않는다

- 읽기 전용인 프로퍼티를 생성할 때, final 키워드 사용을 지향한다

• 변수를 읽을 수만 있고 외부 코드로 수정할 수 없는 변수를 생성하는 쉬운 방법임

내부에서 할당하고 외부에서 접근할 수 있는 필드를 구성해야한다면 이 "private 필드, public getter" 패턴이 필요할 수 있지만 꼭 필요한 경우가 아니면 사용하지 않는 것이 좋다

// good case
class Box {
  final contents = [];
}

// bad case
class Box {
  Object? _contents;
  Object? get contents => _contents;
}

- 간단한 멤버를 선언할 때 => 사용을 고려한다

• =>를 함수 표현식으로 사용하는 것 외에도, Dart에서는 멤버를 정의하는데 사용할 수 있다
• 해당 스타일은 계산을 수행하고 결과를 반환하는 단순한 멤버에게 적합함

  double get area => (right - left) * (bottom - top);
  

String capitalize(String name) => '${name[0].toUpperCase()}${name.substring(1)}';

- 선언이 두 줄 이상이거나 중첨된 표현식일 경우 코드 블럭과 명령문을 사용하는 것이 좋다
```dart
// good case
Treasure? openChest(Chest chest, Point where) {
  if (_opened.containsKey(chest)) return null;

  var treasure = Treasure(where);
  treasure.addAll(chest.contents);
  _opened[chest] = treasure;
  return treasure;
}

// bad case
Treasure? openChest(Chest chest, Point where) => _opened.containsKey(chest)
    ? null
    : _opened[chest] = (Treasure(where)..addAll(chest.contents));

- Named 생성자를 리디렉션하고 충돌을 피하는 경우를 제외하곤 this를 사용하지 않는다

- 가능하다면 필드의 선언과 함께 초기화한다

• 함수 안에 함수가 선언되는 것을 흔한 일이며 흔히 이런 함수들은 콜백으로 사용되고 이름이 없음 -> 함수 표현식을 이런 경우에 적합
• 함수에 이름을 부여하고 싶다면 변수에 람다를 바인딩 하지 말고 함수 선언문을 사용

  // good case
  void main() {
  void localFunction() {
    ...
  }
  }
  

// bad case void main() { var localFunction = () { ... }; }

### 람다 대신 Tear-off를 사용
- 함수, 메서드 또는 named 생성자를 참조할 때 괄호를 생략하면, Dart는 동일한 매개 변수 쌍을 사용하고 호출 시 기본 함수를 호출하는 tear-off 클로저를 사용한다
- 클로저가 받아들이는 매개변수와 동일한 매개변수를 사용하는 named 함수를 호출하는 클로저를 원한다면, 람다로 래핑하지 않는다
```dart
// good case
var charCodes = [68, 97, 114, 116];
var buffer = StringBuffer();

// 함수:
charCodes.forEach(print);

// 메서드:
charCodes.forEach(buffer.write);

// Named 생성자:
var strings = charCodes.map(String.fromCharCode);

// Unnamed 생성자:
var buffers = charCodes.map(StringBuffer.new);

// bad case
var charCodes = [68, 97, 114, 116];
var buffer = StringBuffer();

// 함수:
charCodes.forEach((code) {
  print(code);
});

// 메서드:
charCodes.forEach((code) {
  buffer.write(code);
});

// Named 생성자:
var strings = charCodes.map((code) => String.fromCharCode(code));

// Unnamed 생성자:
var buffers = charCodes.map((code) => StringBuffer(code));

Named 매개변수와 해당 매개변수의 디폴트 값을 분리시키고 싶다면 =을 사용

• dart3 이전에는 : 와 = 를 모두 사용할 수 있었지만 3에서는 =을 사용한다

  void insert(Object item, {int at = 0}) { ... }

• Dart는 세 개의 핵심 컬렉션 타입을 가지고 있음(List, Map, Set). Dart는 컬랙션 생성을 위한 더 좋은 내장 문법을 가지고 있음

  // good case
  var points = <Point>[];
  var addresses = <String, Address>{};
  var counts = <int>{};
  

// bad case var addresses = Map<String, Address>(); var counts = Set();

-> 해당 예제는 named 생성자에 적용하지 않음, List.from(), Map.fromIterable() 등 비슷한 생성자들은 저마다 사용법이 존재함 (List 클래스 또한 unnamed 생성자가 존재하지만, null safe Dart에서는 사용이 금지됨)
- 컬렉션 리터럴은 다른 컬렉션의 요소들을 추가할 때 전개 연산자에 접근이 가능하고 요소를 빌드하는 동안 [if 그리고 for]를 사용하여 흐름 제어를 수행할 수 있다
```dart
// good case
var arguments = [
  ...options,
  command,
  ...?modeFlags,
  for (var path in filePaths)
    if (path.endsWith('.dart')) path.replaceAll('.dart', '.js')
];

// bad case
var arguments = <String>[];
arguments.addAll(options);
arguments.add(command);
if (modeFlags != null) arguments.addAll(modeFlags);
arguments.addAll(filePaths
    .where((path) => path.endsWith('.dart'))
    .map((path) => path.replaceAll('.dart', '.js')));

컬렉션이 비어있는지 확인할 때 .length를 사용하지 않는다

• Iterable을 사용한 컬렉션의 구현은 자신의 길이를 알고 있거나 상수 시간 안에 제공하도록 되어있지 않음. 단지 컬렉션에 포함된 것이 있는지 확인하기 위해 .length를 호출하는건 매우 느릴 수 있다
• 더 빠르고 가독성 높은 .isEmpty와 .isNotEmpty를 사용하는 것이 좋다

  // good case
  if (lunchBox.isEmpty) return 'so hungry...';
  if (words.isNotEmpty) return words.join(' ');
  

// bad case if (lunchBox.length == 0) return 'so hungry...'; if (!words.isEmpty) return words.join(' ');

### Iterable.forEach()를 함수 리터럴과 함께 사용하는 것을 피한다
- Dart에서는 시퀀스를 반복할 때 for-in 루프를 사용하는 것이 관용적인 방법임
```dart
// good case
for (final person in people) {
  ...
}

// bad case
people.forEach((person) {
  ...
});

결과 값의 타입을 바꾸려는 것이 아니면, List.from()을 사용하지 않는다

• 주어진 Iterable를 사용해서 동일한 요소를 가지는 새로운 List를 만드는 확실한 방법은 아래 두가지가 대표적

  var copy1 = iterable.toList(); var copy2 = List.from(iterable);

• 위 둘의 명백한 차이는 첫 번째가 더 간결하고 원래 객체의 타입 인자를 보전한다는 것

  // Creates a List<int>:
  var iterable = [1, 2, 3];
  

// good casse // Prints "List": print(iterable.toList().runtimeType);

// bad case // Prints "List": print(List.from(iterable).runtimeType);

- 타입을 바꾸고 싶다면 List.from()을 호출하는 것이 좋음
```dart
// good case
var numbers = [1, 2.3, 4]; // List<num>.
numbers.removeAt(1); // Now it only contains integers.
var ints = List<int>.from(numbers);

타입에 대해 신경스찌 않거나, 단지 iterable를 복사하고 원래 타입을 보존하는 것이 목적이라면, toList()를 사용한다

컬렉션을 타입으로 필터하고 싶다면, whereType()을 사용한다

• 두 개의 간접 계층과 중복된 런타임 검사를 동반하여 두 개의 wrapper가 생성되도록함
• 간결하면 불필요한 wrapper의 계층이 없이 원하는 타입의 Iterable을 생성할 수 있음

  var objects = [1, 'a', 2, 'b', 3];
  var ints = objects.whereType<int>();

코드의 주변에서 cast()와 같은 역할을 하는 연산이 있다면, cast()를 사용하지 마십시오.

• Iterable 또는 stream을 다룰 때, 종종 cast를 수행, 특정 타입 인자를 사용하여 객체를 생성할 때, cast()를 무작정 호출하기 보다 이미 존재하는 변형이 해당 타입으로의 cast를 수행하는지 먼저 확인한다
• toList()를 호출하면, 해당 호출을 원하는 객체의 타입 T를 지정하여 List.from()으로 대체함

  // good case
  var stuff = <dynamic>[1, 2];
  var ints = List<int>.from(stuff);
  

// bad case var stuff = [1, 2]; var ints = stuff.toList().cast();

- map()을 호출하면 원하는 타입을 명시적으로 타입 인자로 넘겨주어 해당 타입의 iterable을 생성, 타입 추론이 map()으로 넘겨준 함수를 기반으로 옳은 타입을 선택하지만, 종종 명시해야할 필요가 있음
```dart
// good case
var stuff = <dynamic>[1, 2];
var reciprocals = stuff.map<double>((n) => 1 / n);

// bad case
var stuff = <dynamic>[1, 2];
var reciprocals = stuff.map((n) => 1 / n).cast<double>();

cast() 사용을 피한다

• 때때로 객체의 타입을 고정시킬만한 명령어가 없을 수 있지만 그런 경우라도 가능하다면 cast()를 사용하여 컬렌션 타입을 변경하는 것은 피해야 한다

올바른 타입으로 생성한다 -> 컬렉션이 처음 생성되는 코드를 수정하여 올바른 타입을 가지게 한다 요소에 접근할 때 캐스팅을 시도한다 -> 해당 컬렉션에 반복을 수행한다면, 반복 내부에서 각 요소를 캐스팅한다 List.from()을 사용하여 캐스팅하도록 한다 -> 컬렉션의 모든 요소에 접근을 끝냈고 원본 객체가 더 이상 필요하지 않다면, List.from()을 사용하여 타입을 변환한다

• 타입 생성 예제

  // good case
  List<int> singletonList(int value) {
  var list = <int>[];
  list.add(value);
  return list;
  }
  

// bad case List singletonList(int value) { var list = []; // List. list.add(value); return list.cast(); }

- 요소에 접근할 때 캐스팅하는 방법
```dart
// good case
void printEvens(List<Object> objects) {
  // List에 int만 존재한다는 것을 알고 있습니다.
  for (final n in objects) {
    if ((n as int).isEven) print(n);
  }
}

// bad case
void printEvens(List<Object> objects) {
  // List에 int만 존재한다는 것을 알고 있습니다.
  for (final n in objects.cast<int>()) {
    if (n.isEven) print(n);
  }
}

• List.from()을 사용한 캐스팅

  // good case
  int median(List<Object> objects) {
  // List에 int만 존재한다는 것을 알고 있습니다.
  var ints = List<int>.from(objects);
  ints.sort();
  return ints[ints.length ~/ 2];
  }
  

// bad case int median(List