인프런 커뮤니티 질문&답변
작성한 질문수
StateNotifierProvider를 리버팟 제네레이터로 생성하기
해결된 질문
작성
·
224
·
수정됨
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()는 무시되고요...
샘플 코드를 알려 주실 수 있나요?
답변 1
0
안녕하세요!
아래 예제 맞으실까요?
https://riverpod.dev/docs/migration/from_state_notifier#migrating-asynchronous-statenotifiers
감사합니다!
sync 값 또는 async 값에 반응하도록 해야합니다 (watch를 사용해서요)
할 수 없을 것 같지는 않지만 아마 매우 복잡할겁니다. 차라리 안하는게 나을 정도로.
아래 예제를 보면 async 값에 반응하게 하는 방법이 있습니다. (sync 값은 당연히 순서대로 로직을 작성하면 되구요)
이 문제 때문만이 아니라도 generator는 한계점이 많아서 저는 사용하지 않고 있습니다.
감사합니다!
모든 코드는 한계점이 있습니다. 변수부터 클래스 선언까지 내가 직접한다면 한계점이 없겠지만 이미 작성된 코드는 그 자체로 한계점을 지닙니다. 예를들어서 riverpod은 하나의 변수만 상태관리 합니다. Provider처럼 여러 값을 하나의 클래스에서 상태관리 할 수 없으니 한계점이라 할 수 있겠죠. 하지만 그 한계점이 내가 구현하려는 기능의 목적에 문제가 되지 않는다면 상관이 없는겁니다. riverpod generator는 riverpod을 한번 더 감싸는 wrapper죠,. 그러면 당연히 riverpod을 그대로 사용하는 것 보다 한계점이 있습니다. 대신 그 한계점들이 내가 사용하는 목적에 문제가 되지 않는다면 장점이 더 많겠죠. 무언가 한 기능을 더 쉽고 잘 할 수 있도록 코드를 작성한다는건 그 정확한 목적을 갖고 작성하기 때문에 포기하는 다른 부분들이 있다는 의미입니다. "riverpod generator는 왜 직접 riverpod 프로바이더를 작성할때처럼 유연하게 상태 변화를 못시키지?"라는 질문은 큰 의미가 없습니다. riverpod generator는 보일러 플레이트를 줄이려는 목적으로 생성되었고 그 역할을 매우 잘해줍니다. 대신 직접 작성해야하는 보일러 플레이트를 generator가 직접 생성 해주는만큼 그 자체가 가져오는 한계점이 있을 수 밖에 없습니다. 나중에 riverpod 팀에서 개선을 해줄수도 있는 부분이겠지만 하나를 포용한다면 항상 또 다른 하나를 버려야합니다.
제가 중요한 점을 놓치고 있었다는 생각이 드네요.... 이렇게 설명해 주신 덕분에 좋은 관점을 얻어갑니다.
어떤 기능을 목적으로 제공되는 코드/라이브러리/프레임워크는 그 목적을 벗어나는 구간에선 제한이 있을 수밖에 없기 때문에 개발자가 상황에 맞게 선택하면 되는 거군요! 답변 정말 감사합니다.
안녕하세요, 리버팟 제네레이터를 사용하면
PaginationLoading()을 사용하지 못하는 건가요? 첨부해주신 예제를 봐도 로딩이 어떻게 처리되는지 잘 모르겠습니다