① 배운 것
Flutter: 언제 setState를 사용해야 할까?
Flutter에서 State는 위젯의 UI를 구성하는 데 필요한 정보를 담고 있습니다.
버튼의 텍스트, 체크박스의 선택 여부, 리스트의 항목 등 UI에 표시되는 모든 요소는 State를 통해 관리됩니다.
State가 변경되면 Flutter는 해당 State를 사용하는 위젯을 다시 빌드하여 변경된 UI를 화면에 표시합니다.
이때 State를 업데이트하고 위젯을 다시 빌드하도록 지시하는 함수가 바로 setState입니다.
State 정의
Flutter에서 State는 다음과 같은 특징을 갖습니다.
UI를 나타내는 정보: 위젯의 모양, 내용, 상태 등 UI에 표시되는 모든 요소를 나타냅니다.
변경 가능성: 앱의 동작에 따라 State는 동적으로 변경될 수 있습니다.
위젯 재빌드: State가 변경되면 Flutter는 해당 State를 사용하는 위젯을 다시 빌드하여 변경된 UI를 화면에 표시합니다.
setState 없이 변수를 변경해도 되는 경우
모든 변수가 State인 것은 아닙니다. UI에 직접적인 영향을 주지 않는 변수들은 State로 관리할 필요가 없으며, setState 없이 자유롭게 변경할 수 있습니다.
예시:
class _MyScreenState extends State<MyScreen> {
int _counter = 0; // UI에 표시되는 카운터 (State)
bool _isLoading = false; // 네트워크 요청 상태 (UI에 직접 영향 X)
void _incrementCounter() {
setState(() {
_counter++; // State 변경 -> setState 호출
});
}
void _fetchData() async {
_isLoading = true; // setState 없이 변경 가능
// ... 네트워크 요청 ...
_isLoading = false; // setState 없이 변경 가능
}
// ... (생략)
}위 예시에서 _counter 변수는 UI에 표시되는 카운터 값을 나타내는 State이므로, 변경 시 setState를 호출해야 합니다.
하지만 _isLoading 변수는 네트워크 요청 상태를 나타내는 변수일 뿐, UI에 직접적으로 영향을 주지 않습니다. 따라서 setState 없이 변경해도 문제가 없습니다.
정리
UI에 직접 영향을 주는 변수는 State로 관리하고, 변경 시 setState를 호출해야 합니다.
UI에 영향을 주지 않는 변수는 State로 관리할 필요 없이 자유롭게 변경할 수 있습니다.
이 원칙을 기억하면 불필요한 setState 호출을 줄이고 앱의 성능을 향상시킬 수 있습니다
- 중복되는 텍스트필드나 pinput, switch 등을 common widget으로 뺐는데, 이때는 기존 코드 뉘앙스와 비슷하게 (그리고 라이브러리 같은 것을 봐도 common widget에서 provider를 쓰는 경우는 없었던 것 같다.)텍스트필드나 pinput내에서 ref를 쓰지 않아도 되게, 외부에서 setstate를 호출해서 텍스트필드나 pinput자체를 새로 그리도록 했다.
외부에서 setState를 호출할때마다 모든 외부 코드가 새로 그려지는것이 찝찝해서 텍스트필드나 pinput만 stateBuilder를 이용해 setState되도록 수정할까 고민했는데 다른 외부코드에는 대부분 const가 붙어있어서 괜찮았다. - 어떤 프로바이더안에서 secureStorage의 value변화가 있을때마다 watch 하려했는데, 이 코드로는 secureStorage 자체가 변화한게 없어서 제대로 인식을 못했다. 결국 이 프로바이더 자체가 의미 없어서 삭제함.
final appLockOnOffStateProvider = FutureProvider<bool> ((ref) async {
final password = await ref.watch(secureStorageProvider).read(key:password);
return password != null;
}); ② 회고 (restropective)
오늘 새 회사에서 첫 개발한 기능에 대해 간단한 큐시가 진행되었는데 버그가 꽤 나와서 우울?하다 완벽히 해내고싶었는데 그렇지 못해서 그런거같다. 하지만 버그 없이 처음부터 100%완벽하게 하는 사람은 없다. 그러면 큐에이팀이 존재할 필요도없음. 그러므로 너무 우울해하지말자~~ 그래도 해피케이스에서는 버그가 나오지 않았다는걸 뿌듯?하게 생각하자.
큐시에서 나온 버그를 수정할때마다 드는 생각인데 그 테이프로 물 막는 짤처럼 내 코드도 버그 수정할때마다 테이프가 덕지덕지 붙는기분이다. 다른 사람 코드도 이런식인지 아니면 내 코드가 설계가 애초에 잘못된건지 ...ㅠㅠ
③ 개선을 위한 방법
다른 사람 코드를 많이 봐보자
