-
질문 & 답변
카테고리
-
세부 분야
모바일 앱 개발
-
해결 여부
해결됨
StateNotifierProvider를 리버팟 제네레이터로 생성하기
24.03.19 10:07 작성 24.03.19 10:09 수정 조회수 104
0
class PaginationStateProvider<T extends IModelWithId, U extends IBasePaginationRepository<T>>
extends StateNotifier<CursorPaginationBase> {
final U repository;
PaginationStateProvider({
required this.repository,
}) : super(CursorPaginationLoading()) {
paginate();
}
Future<void> paginate() async {
// 생략
}
}위의 코드를 riverpod_generator 이용하는 코드로 바꾸고 싶은데 아무리 고민해봐도 모르겠습니다.
@riverpod
class PaginationState extends _$PaginationState {
@override
CursorPaginationBase build() {
return CursorPaginationLoading();
}
Future<void> paginate() async {}
}이렇게 작성하면 로딩만 적용되니까 paginate()는 무시되고요...
샘플 코드를 알려 주실 수 있나요?
답변을 작성해보세요.
0
코드팩토리
지식공유자2024.03.19
안녕하세요!
아래 예제 맞으실까요?
https://riverpod.dev/docs/migration/from_state_notifier#migrating-asynchronous-statenotifiers
감사합니다!
lancer10
질문자2024.03.19
안녕하세요, 리버팟 제네레이터를 사용하면 PaginationLoading()을 사용하지 못하는 건가요? 첨부해주신 예제를 봐도 로딩이 어떻게 처리되는지 잘 모르겠습니다
코드팩토리
지식공유자2024.03.20
sync 값 또는 async 값에 반응하도록 해야합니다 (watch를 사용해서요)
할 수 없을 것 같지는 않지만 아마 매우 복잡할겁니다. 차라리 안하는게 나을 정도로.
아래 예제를 보면 async 값에 반응하게 하는 방법이 있습니다. (sync 값은 당연히 순서대로 로직을 작성하면 되구요)
이 문제 때문만이 아니라도 generator는 한계점이 많아서 저는 사용하지 않고 있습니다.
감사합니다!
lancer10
질문자2024.03.20
한계점이 있다는 걸 모르고 있었네요.... 다형성 활용하려면 generator는 사용하지 않는 편이 나은 거겠죠? 답변 정말 감사합니다.
코드팩토리
지식공유자2024.03.20
모든 코드는 한계점이 있습니다. 변수부터 클래스 선언까지 내가 직접한다면 한계점이 없겠지만 이미 작성된 코드는 그 자체로 한계점을 지닙니다. 예를들어서 riverpod은 하나의 변수만 상태관리 합니다. Provider처럼 여러 값을 하나의 클래스에서 상태관리 할 수 없으니 한계점이라 할 수 있겠죠. 하지만 그 한계점이 내가 구현하려는 기능의 목적에 문제가 되지 않는다면 상관이 없는겁니다. riverpod generator는 riverpod을 한번 더 감싸는 wrapper죠,. 그러면 당연히 riverpod을 그대로 사용하는 것 보다 한계점이 있습니다. 대신 그 한계점들이 내가 사용하는 목적에 문제가 되지 않는다면 장점이 더 많겠죠. 무언가 한 기능을 더 쉽고 잘 할 수 있도록 코드를 작성한다는건 그 정확한 목적을 갖고 작성하기 때문에 포기하는 다른 부분들이 있다는 의미입니다. "riverpod generator는 왜 직접 riverpod 프로바이더를 작성할때처럼 유연하게 상태 변화를 못시키지?"라는 질문은 큰 의미가 없습니다. riverpod generator는 보일러 플레이트를 줄이려는 목적으로 생성되었고 그 역할을 매우 잘해줍니다. 대신 직접 작성해야하는 보일러 플레이트를 generator가 직접 생성 해주는만큼 그 자체가 가져오는 한계점이 있을 수 밖에 없습니다. 나중에 riverpod 팀에서 개선을 해줄수도 있는 부분이겠지만 하나를 포용한다면 항상 또 다른 하나를 버려야합니다.
lancer10
질문자2024.03.21
제가 중요한 점을 놓치고 있었다는 생각이 드네요.... 이렇게 설명해 주신 덕분에 좋은 관점을 얻어갑니다.
어떤 기능을 목적으로 제공되는 코드/라이브러리/프레임워크는 그 목적을 벗어나는 구간에선 제한이 있을 수밖에 없기 때문에 개발자가 상황에 맞게 선택하면 되는 거군요! 답변 정말 감사합니다.
답변 1