Flutter: 위젯 후크

에 만든 2018년 12월 12일 · 100코멘트 · 출처: flutter/flutter

React 팀은 최근 후크를 발표했습니다: https://medium.com/@dan_abramov/making -sense-of-react-hooks-fdbde8803889. Flutter가 React와 얼마나 유사하기 때문에 이것이 Flutter에도 맞는지 확인하는 것은 흥미로울 것입니다.

정의:

후크는 StatefulWidget State 와 매우 유사하지만 한 가지 주요 차이점이 있습니다. 위젯에서 원하는 만큼 후크를 가질 수 있습니다.
후크는 State (또는 수정된 버전)에 있는 모든 수명 주기에 액세스할 수 있습니다.

후크는 주어진 위젯에서 사용할 수 있습니다. 하나의 특정 위젯 유형에만 사용할 수 있는 State 와는 대조적입니다.

Hooks는 충돌을 생성할 수 없기 때문에 슈퍼 믹스인과 다릅니다. 후크는 _완전히_ 독립적이며 위젯과 관련이 없습니다.
즉, Hook을 사용하여 값을 저장하고 충돌에 대한 두려움 없이 공개적으로 노출할 수 있습니다. 또한 믹스인과 달리 동일한 Hook을 여러 번 재사용할 수 있음을 의미합니다.

원칙:

후크는 기본적으로 배열의 Element 내에 저장됩니다. 위젯의 build 메서드 내에서만 액세스할 수 있습니다. 그리고 후크는 무조건 접근해야 합니다. 예:

하다:

Widget build(BuildContext context) {
  Hook.use(MyHook());
}

하지마:

Widget build(BuildContext context) {
  if (condition) {
    Hook.use(MyHook());
  }
}

이 제한은 매우 제한적으로 보일 수 있지만 후크가 인덱스에 의해 저장되기 때문입니다. 그들의 유형도 이름도 아닙니다.
이렇게 하면 충돌 없이 원하는 만큼 동일한 후크를 재사용할 수 있습니다.

사용 사례

Hooks의 가장 유용한 부분은 수명 주기 로직을 재사용 가능한 구성 요소로 추출할 수 있다는 것입니다.

Flutter 위젯의 일반적인 문제 중 하나는 AnimationController 와 같은 일회용 개체입니다.
일반적으로 initState 및 dispose 재정의가 모두 필요합니다. 그러나 동시에 유지 관리상의 이유로 믹스인으로 추출할 수 없습니다.

이것은 일반적인 코드 스니퍼로 이어집니다: stanim

class Example extends StatefulWidget {
  <strong i="7">@override</strong>
  ExampleState createState() => ExampleState();
}

class ExampleState extends State<Example>
    with SingleTickerProviderStateMixin {
  AnimationController _controller;

  <strong i="8">@override</strong>
  void initState() {
    super.initState();
    _controller = AnimationController(vsync: this, duration: const Duration(seconds: 1));
  }

  <strong i="9">@override</strong>
  void dispose() {
    super.dispose();
    _controller.dispose();
  }

  <strong i="10">@override</strong>
  Widget build(BuildContext context) {
    return Container(

    );
  }
}

Hooks는 라이프 사이클 로직을 추출하여 이 문제를 해결합니다. 이것은 잠재적으로 _훨씬_ 작은 코드로 이어집니다.

class Example extends StatelessWidget {
  <strong i="15">@override</strong>
  Widget build(BuildContext context) {
    AnimationController controller = useAnimationController(duration: const Duration(seconds: 1));
    return Container(

    );
  }
}

이러한 후크의 순진한 구현은 다음 기능일 수 있습니다.

AnimationController useAnimationController({Duration duration}) {
  // use another hook to obtain a TickerProvider
  final tickerProvider = useTickerProvider();

  // create an AnimationController once
  final animationController = useMemoized<AnimationController>(
    () => AnimationController(vsync: tickerProvider, duration: duration)
  );
  // register `dispose` method to be closed on widget removal
  useEffect(() => animationController.dispose, [animationController]), 

   // synchronize the arguments
  useValueChanged(duration, (_, __) {
    animationController.duration = duration;
  });

  return animationController;
}

useAnimationController 는 "후크" 중 하나입니다.

이러한 후크의 순진한 구현은 다음과 같습니다.

그 코드는 State 클래스에 익숙한 누군가와 유사해야 합니다. 그러나 여기에는 몇 가지 흥미로운 점이 있습니다.

후크는 생성에서 폐기까지 AnimationController 를 완전히 처리합니다. 그러나 또한 업데이트합니다.
재사용 가능한 패키지로 쉽게 추출할 수 있습니다.
또한 initState AnimationController 를 생성하는 것과 달리 핫 리로드 시 duration 업데이트를 처리합니다.
후크는 다른 후크를 사용하여 더 복잡한 논리를 빌드할 수 있습니다.

단점

후크에는 비용이 따릅니다. 값에 대한 액세스에는 InheritedElement 와 유사한 오버헤드가 있습니다. 또한 클로저 또는 "위젯"과 같은 수명이 짧은 객체의 새로운 세트를 생성해야 합니다.

실제 차이를 보기 위해 아직 벤치마크를 실행하지 않았지만

또 다른 문제는 핫 리로드에 관한 것입니다.

괜찮으면 목록 끝에 후크를 추가합니다. 그러나 후크는 순서에 따라 작동하므로 기존 후크 중간에 후크를 추가하면 부분 상태 재설정이 발생합니다. 예시:

A, B 에서 A, C, B 로 이동하면 B 의 상태가 재설정됩니다( dispose 및 initHook 를 다시 호출).

결론

Hooks는 더 큰 코드 재사용을 허용하여 위젯 세계를 _많이_ 단순화합니다. 특히 폐기, 메모 작성 및 가치 관찰과 같은 매우 일반적인 시나리오에서.

StatefulWidget을 완전히 대체하는 데 사용할 수 있습니다.

그러나 마음의 전환이 필요하고 리팩토링 시 부분 상태 재설정이 번거로울 수 있습니다.

사용자 정의 요소를 생성하여 Flutter 외부에서 후크를 추출하는 것이 가능합니다. 현재로서는 소스를 수정할 필요가 없습니다.

그러나 후크의 특수성으로 인해 맞춤형 린터를 사용하면 _많은_ 이점이 있습니다. 현재 제공할 수 없는 외부 패키지.

보너스

~진행 중인 구현은 여기에서 사용할 수 있습니다: https://github.com/rrousselGit/flutter_hooks (최신 기능은 prod-ready 분기에 있습니다).~

~곧 알파 버전으로 출시될 예정입니다. 그러나 현재 구현은 어느 정도 작동합니다.~

https://pub.dartlang.org/packages/flutter_hooks# -readme-tab-에서 사용 가능

framework new feature

출처

rrousselGit

👍91 ❤22 🎉10 🚀7 👎6

가장 유용한 댓글

Flutter 팀의 누군가가 Hooks에 대해 1:1 채팅을 하고 싶다면, 저는 우리가 React에서 Hooks를 채택한 이유에 대한 역사적, 기술적 맥락을 설명하게 되어 기쁩니다. 이 의견도 흥미로울 수 있습니다. https://github.com/reactjs/rfcs/pull/68#issuecomment -439314884.

gaearon 에 2019년 01월 22일

👍72 ❤29 👎1

모든 100 댓글

@Hixie @eseidelGoogle

다음은 내가 염두에 둔 몇 가지 세부 사항과 함께 https://twitter.com/ericmander/status/1070024779015479302 에 대한 후속 조치입니다. Flutter 팀이 해당 주제에 대해 추가 투자를 원하는 경우를 대비하여

rrousselGit 에 2018년 12월 12일

안녕하세요 @rrousselGit 요 전에 귀하의 flutter_hooks 패키지를 보고 있었습니다. Flutter에서 구현하기 위해 어떤 옵션이 있는지 잘 모르겠지만 HookContext를 통해 후크 메서드를 전달하는 반면 React에서는 후크를 별도로 생성할 수 있으며 일종의 "상태 믹스인"으로 사용할 수 있습니다. 주요 차이점은 flutter_hooks 는 모든 후크 메서드를 패키지에 빌드해야 하는 것처럼 보이지만 React는 후크 메서드를 완전히 분리할 수 있다는 것입니다.

이것은 React 사양을 일치시키는 데 중요할 것 같습니다. 이것이 어떻게 달성될 수 있는지에 대한 생각이 있습니까?

lukepighetti 에 2018년 12월 12일

편집 :

HookContext 가 제거되었으며 모든 후크는 이제 정적 메서드입니다. 따라서 다음은 이제 구식입니다.

내 패키지는 자동 완성을 위해 그렇게 하지만 필수는 아닙니다.

대신에

context.useSomeHook()

우리는 가질 수 있습니다

useSomeHook(context)

이것은 검색 가능성 외에는 아무것도 변경하지 않습니다.

주요 기능은

T HookContext.use<T>(Hook);

거기에서 자신의 후크를 만들 수 있습니다. 이 방법만 있으면 React가 하는 모든 것을 할 수 있습니다.

rrousselGit 에 2018년 12월 12일

👍5

그러나 후크의 특수성으로 인해 맞춤형 린터를 사용하면 많은 이점을 얻을 수 있습니다. 현재 제공할 수 없는 외부 패키지.

나는 당신이 upvote를 추천합니다 (그리고 당신의 사용 사례를 추가하십시오)
https://github.com/dart-lang/linter/issues/697. 패키지가 고유한 맞춤 린트를 제공할 수 있다면 좋을 것입니다.

또 다른 문제는 핫 리로드에 관한 것입니다.

이것은 나를 걱정시킨다. 핫 리로드 경험을 저하시키면 슬플 것입니다.

https://pub.dartlang.org/packages/flutter_hooks 에서 사용 가능

이것을 Flutter 프레임워크에 굽는 것의 장점이 외부 패키지를 갖는 것보다 무엇인지 자세히 설명해 주시겠습니까?

goderbauer 에 2019년 01월 17일

핫 리로드에 대해 통합했는데 사용하기가 부드럽습니다.

유일한 진짜 문제는 #26503이며, 수정하려면 도구를 변경해야 합니다. 그리고 나는 그것을 할 대역폭이 없습니다.

후크를 Flutter에 통합하여 가져올 수 있는 여러 가지 작은 개선 사항이 있습니다.

StatefulElement에 의존하지 않음으로써 일부 성능 향상
Analyzer_plugin을 사용하여 현재 불가능하거나 매우 제한적인 리팩토링/분석

그러나 가장 큰 이유는 다음과 같습니다. Hook은 React에서 대규모 작업의 일부인 비동기 렌더링입니다.

Flutter가 Async Rendering 경로를 사용하고 싶다면(그리고 그래야 하는 경우) 두 가지가 필요합니다.

여러 프레임워크 변경
후크와 비슷한 것

명백한 커뮤니티 측면도 있습니다. 내가 실제로 광고하지 않은 상태에서 한 달에 270개의 별과 https://github.com/trending/dart?since=monthly 에 한 자리가 있는 - 후크는 확실히 커뮤니티의 관심을 높이는 것입니다.

후크의 목표는 위젯의 구문을 변경하여 사람들이 라이프사이클 특정 로직을 pub에 공유할 수 있도록 하는 것입니다.

후크가 공식적으로 지원되면 커뮤니티의 노력이 기하급수적으로 증가합니다.

rrousselGit 에 2019년 01월 17일

🎉9 ❤7

호기심: 핫 리로드에서 어떻게 작동하게 했는지 설명해주실 수 있나요?

goderbauer 에 2019년 01월 17일

reassemble 에 액세스할 수 있도록 ComponentElement 대신 StatefulElement를 확장했습니다.
이렇게 하면 다음 build 호출이 후크 목록을 변경하는 동시에 정상적인 재구축을 방지할 수 있습니다.

기본적으로 지정된 인덱스에서 previousHook.runtimeType != newHook.runtimeType 이면 이 후크와 다음 모든 항목이 삭제됩니다.

"다음 모두" 부분은 후크가 다른 후크를 사용할 수 있기 때문입니다. 따라서 하나만 제거하는 것만으로는 충분하지 않습니다.
한 달 동안 꾸준히 사용하다 보면 거의 문제가 되지 않습니다.

실제로는 그 반대입니다. 핫 리로드 경험이 향상되는 것 같습니다. 모든 것이 build 메서드 내에 있으므로 핫 리로드는 항상 변경 사항을 적용합니다( initState 와 반대). 일반적인 예는 AnimationController 입니다.

final animationController = useAnimationController(duration: const Duration(second: 1));

이 후크는 지속 시간의 부드러운 핫 리로드를 허용합니다. 이것은 일반적으로 핫 리스타트가 필요한 것입니다.

rrousselGit 에 2019년 01월 17일

🎉13

일부 상용구를 제거하기 위해 메인 앱의 일부를 번역하기 시작했습니다. 나는 Hooks를 기능이 아니라 완전한 패턴으로 봅니다. 구현을 기다리고 있는 많은 주제로 생산성은 물론 유지 관리에도 큰 이점이 있습니다. 저는 애니메이션으로 시작하여 컨트롤러를 제거했으며 Firebase용 Hooks 또는 기타 일반적인 경우를 보고 싶습니다.

Solido 에 2019년 01월 17일

❤9

실제로는 그 반대입니다. 핫 리로드 경험이 향상되는 것 같습니다. 모든 것이 빌드 메소드 내에 있기 때문에 핫 리로드는 항상 변경 사항을 적용합니다(initState와 반대).

👍 나도 처음 세바스찬의 제안을 본 지 몇 주 만에 깨달았다.

gaearon 에 2019년 01월 18일

👍18

"다음 모두" 부분은 후크가 다른 후크를 사용할 수 있기 때문입니다. 따라서 하나만 제거하는 것만으로는 충분하지 않습니다.

또한 JS에서는 휴리스틱이 도움이 될 수 있다고 생각했습니다. 핫 리로딩으로 인해 render (Flutter의 build )가 발생하면(예: 일치하지 않는 유형으로 인해) 모든 Hooks 상태를 재설정하고 다시 시도합니다. 다시 실패하면 우리는 실패합니다.

타이핑이 강해서 이런 문제는 없는 것 같은데요? 잘 모르겠어. 문자열 상태 Hook으로 편집을 시작한 다음 코드를 숫자로 가정하도록 변경하면 어떻게 됩니까?

gaearon 에 2019년 01월 18일

문자열 상태 Hook으로 편집을 시작한 다음 코드를 숫자로 가정하도록 변경하면 어떻게 됩니까?

다음에서 출발한다는 뜻입니다.

final counter = useState(0)

에게:

final name = useState('foo');

그렇다면 입력 시스템은 유형이 변경되었음을 올바르게 감지합니다. useState 의 유형이 실제로 useState<int> 대 useState<String> 이기 때문입니다.

JS는 여기서 더 힘든 시간을 보낼 것입니다.

rrousselGit 에 2019년 01월 18일

👍5

나는 이것이 당신을 구하는 것을 정말로 이해하지 못합니다. 이해하기 쉬운 선언 하나, initState에서 이해하기 쉬운 줄 하나, dispose에서 이해하기 쉬운 줄 하나가 빌드 메서드에서 덜 효율적이고 완전히 불투명한 줄로 대체됩니다(여기서 성능은 비판적인). 좋은 거래가 아닌 것 같습니다. 이점에 대해 자세히 설명해 주시겠습니까?

Hixie 에 2019년 01월 20일

👎18 👍4 ❤1

(즉, https://pub.dartlang.org/packages/flutter_hooks는 이미 여기에 모든 것을 구현한 것처럼 보이므로 플랫폼에 아무것도 추가할 필요가 없다고 생각합니다.)

Hixie 에 2019년 01월 20일

👍1

Hooks는 React가 수년간 직면한 문제에 대한 하나의 솔루션입니다. 그리고 Flutter가 React에서 많은 영감을 얻으면서 이러한 문제도 가져왔습니다.

저는 마케팅에 소질이 있으므로 이에 대한 React Team의 이야기를 시청하는 것이 좋습니다. 그들의 소개는 https://youtu.be/dpw9EHDh2bM에서 시작됩니다.

Dan Abramov의 전후 비교(위의 몇 가지 설명에 대한 답변)가 이어집니다.

요점은 그들이 그 대화에 있는 모든 것이 Flutter에도 적용된다는 것입니다(mixins가 유해하다는 블로그를 포함하여 https://reactjs.org/blog/2016/07/13/mixins-considered-harmful.html).

즉, 후크는 다음과 같은 눈에 띄는 문장으로 요약될 수 있습니다.

후크를 사용하면 애플리케이션의 더 많은 비율을 '공개'할 수 있습니다.

위젯에서 후크를 완전히 추출하여 다른 사용자가 사용할 수 있도록 게시할 수 있기 때문입니다. 우리의 논리가 State 수명 주기와 연결되어 있기 때문에 현재로서는 StatefulWidget 에서는 불가능한 일입니다.

후크의 또 다른 효과는 코드가 그룹화되는 방식을 변경한다는 것입니다. 현재 다음이 있습니다.

initState() {
  a = A(widget.foo);
  b = B(widget.bar);
}

didUpdateWidget(SomeWidget old) {
  if (old.foo != widget.foo) {
    a.foo = widget.foo;
  }
  if (old.bar != widget.bar) {
    b.bar = widget.bar;
  }
}

dispose() {
  a.dispose();
  b.dispose();
}

모든 것이 여러 라이프 사이클에 걸쳐 혼합 및 분할됩니다. 변수를 삭제/업데이트하는 것을 잊었는지 확인하기가 매우 어려워집니다.

후크를 사용하면 다음과 같이 됩니다.

final a = useMemoized(() => A(foo));
useValueChanged(foo, () => a.foo = foo});
useEffect(() => a.dispose, [a]);

final b = useMemoized(() => B(bar));
useValueChanged(bar, () => b.bar = bar});
useEffect(() => b.dispose, [b]);

이제 모든 것이 재편성되었습니다. 변수를 삭제/업데이트하는 것을 잊어버렸는지 여부는 훨씬 더 분명해지며 해당 논리를 내부적으로 모든 작업을 수행하는 정적 함수로 쉽게 추출할 수 있습니다.

후크는 DRY에 따릅니다. 변수를 생성/업데이트/폐기하는 논리를 한 번 작성합니다. 그리고 우리는 그것을 복사하여 붙여넣는 대신 모든 곳에서 재사용합니다.

시각적 예(React에서):

전반적으로 Flutter 저장소 외부에서 후크를 구현할 수 있다는 것이 놀랍습니다. 그대로 있어서는 안 된다고 생각합니다.

Flutter가 Widget 기본 클래스만 제공하고 StatefulWidget 를 외부 종속성으로 만든 것과 같습니다. 이치에 맞지 않습니다.

Flutter는 프레임워크입니다. 우리는 기본만 제공하고 싶지 않습니다.

이는 또한 다음을 원할 것임을 의미합니다.

이점을 얻을 수 있는 모든 프레임워크 측면에 대한 후크를 제공합니다.
위젯 검사기와 상호 작용(현재 UI는 이러한 사용 사례에 최적화되어 있지 않음)
리팩토링/린터
테스트 유틸리티 제공

여기에는 엄청난 양의 작업이 필요하고 Flutter에서 여러 PR이 필요할 수 있습니다.
한 사람이 여가 시간에 유지 관리하는 작은 패키지의 범위와는 거리가 멉니다.

rrousselGit 에 2019년 01월 20일

👍30 ❤2 👎1

후크는 DRY이며 코드의 깨끗한 공동 배치를 촉진하는 비즈니스 로직/상태 믹스인입니다. 대안은 코드베이스에서 단편화된 반복입니다.

종이에서는 더 불투명하지만 패턴은 반복 가능하고 이해할 수 있으므로 하루가 지나면 투명해집니다. 다른 프로그래밍 패턴과 같습니다. 시작할 때는 불투명하고 사용할 때는 투명하지만 Hooks를 사용하면 전환이 거의 즉각적입니다.

lukepighetti 에 2019년 01월 20일

❤17 👍6 👎1

반응에서 많은 개발자는 후크가 원래 클래스 구성 요소에 의존하지 않아도 되는 많은 경우를 만든다고 생각합니다. 따라서 가까운 장래에 기능적 구성 요소가 무대의 중심에 오를 것입니다.

내 순진한 질문은 플러터에서 기능적 위젯을 지원하는 것도 의미가 있는지 여부입니다. 현재 기능하는 위젯은 자체 Element에 연결하지 않고 자체 BuildContext가 없기 때문에 권장되지 않는다는 것을 이해합니다. 클래스 위젯이 하는 것처럼 객체 아래에 동일한 것을 생성할 수 있는 새로운 기능적 메커니즘을 도입하는 것이 도움이 될까요?

ivenxu 에 2019년 01월 21일

@ivenxu 이것은 다른 패키지에서도 내가 만든 것입니다. https://github.com/rrousselGit/functional_widget

함수(키 및 모든 것 포함)에서 클래스를 생성하고 HookWidget 를 생성하는 후크와 호환되는 코드 생성기입니다.

둘의 합은 다음과 같습니다.

<strong i="11">@hwidget</strong>
Widget foo(BuildContext context, {Duration duration}) {
  final controller = useAninationController(duration: duration);
  useEffect(controller.forward, [controller]);

  final value = useAnination(controller);
  return Text(value.toString());
}

점진적으로 0에서 1로 가는 멋진 텍스트를 만듭니다.
6줄의 코드로...
일반적인 위젯에서는 30줄 이상이 필요합니다.

그리고 자동 생성된 debugFillProperties 및 operator== 재정의를 계산하지 않습니다.

rrousselGit 에 2019년 01월 21일

🎉6 🚀3 👎2

@rrousselGit 기능적 위젯에 대한 귀하의 작업에 대해 알고 있었고, 좋은 내용과 감사합니다! 그러나 나는 flutter의 기본 지원에 대해 이야기하고 있습니다.

그건 그렇고, 첨부된 디버그는 코드 생성에 어떻게 가나요? foo()에서 중단점을 설정하고 지역 변수를 검사할 수 있습니까? 콜스택은 어떻게 생겼나요?

때로는 컴포넌트/위젯에 대한 기능적 패러다임이 클래스에 비해 훨씬 더 간결합니다. 그래서 네이티브 지원 기능 위젯이 어떤 차이를 만들지 여부에 대한 아이디어를 찾고 있습니다.

ivenxu 에 2019년 01월 21일

후크를 사용하면 다음과 같이 됩니다.

저는 여기의 "before" 사진이 "after" 사진보다 훨씬 더 명확하고 이해하기 쉽다고 생각합니다. 물론 주관적인 생각이긴 하지만요.

Flutter가 Widget 기본 클래스만 제공하고 StatefulWidget을 외부 종속성으로 만든 경우와 같습니다. 이치에 맞지 않습니다.

그렇게 하는 것은 실제로 Flutter의 계층화 철학과 매우 일치합니다. StatefulWidget을 프레임워크의 위젯 레이어의 핵심 일급 부분으로 사용하는 주된 이유는 프레임워크의 다른 기능이 여기에 의존하기 때문입니다(예: GlobalKey ). 그래서 우리는 그렇게 할 수 없습니다. 그러나 가능한 한 핵심에 있지 않도록 기능을 추출하고 싶습니다.

사용하고 싶은 분들을 위해 패키지로 해두는 것도 의미가 있을 것 같아요. 핵심 프레임워크에서 더 나은 구현, 더 효율적인 구현 등을 위해 우리가 할 수 있는 일이 있다면 반드시 그렇게 해야 합니다.

Hixie 에 2019년 01월 22일

👍12

나는 이것이 훌륭한 프로젝트라고 생각하고 관심을 가지고 패키지를 따르고 있습니다.

즉, 이것이 프레임워크에 있어야 하는 이유에 대해 완전히 명확하지 않습니다. 이것은 어떤 사람들은 좋아할 것이고 다른 사람들은 사용하지 않는 것을 선호할 매우 유용한 패턴처럼 보입니다.

@rrousselGit 나는 당신이 이것을 별도의 패키지로 계속 개발하고 그것을 더 성공적으로 만드는 데 도움이 될 핵심 프레임워크에 대한 문제/PR을 여는 데 많은 성공을 거둘 것이라고 생각합니다. 현재 이 작업을 수행하지 않는 프레임워크에서 노출해야 하는 것이 있으면 해결해 보겠습니다. 프레임워크에 이 작업을 차단하는 버그가 있으면 작동하도록 합시다!

그리고 FWIW, 나는 이것이 flutter_svg와 유사한 경험을 가지고 있다고 말합니다. 이는 프레임워크에 약간의 기여를 했고 많은 사람들에게 패키지로 유용할 수 있었습니다.

dnfield 에 2019년 01월 22일

👍8

방금 깨달았습니다.
후크가 Flutter에서 구현된다면 좋은 후보는 ComponentElement입니다.

즉, 새 위젯 유형을 사용하는 대신 StatelessWidget과 StatefulWidget을 후크와 호환 가능하게 만듭니다.

이 접근 방식을 사용하면 두 구문이 공존할 수 있습니다. 두 구문 모두 장단점이 있다는 점을 고려하면 유용할 수 있습니다.

지금은 Flutter 외부에 있는 후크에 문제가 없습니다.

내 유일한 관심사는 비공식적이어서 전체 후크 사용량이 줄어들 것이라는 것입니다. 따라서 펍에서 사용 가능한 후크 수를 줄이십시오.

후크의 가장 큰 장점은 커뮤니티 영향(pub에 게시 가능한 사용자 정의 후크)이라는 점을 고려하면 유용성이 떨어집니다.

rrousselGit 에 2019년 01월 22일

👍27 👎1

gaearon 에 2019년 01월 22일

👍72 ❤29 👎1

@Hixie 또는 @dnfield 여러분 중 @gaearon에게 연락한 적이 있습니까?

React도 많이 사용하는 Flutter 사용자로서 후크는 React의 진정한 게임 체인저라고 말할 수 있습니다. 저는 독점적으로 후크를 사용하여 모든 새 코드를 작성하고 있으며 작업하면서 기존 클래스를 후크로 이식하고 있습니다. 구성 요소의 특정 부분과 관련된 모든 코드를 같은 위치에 두는 것의 이점은 놀랍습니다!

그 패러다임이 Flutter에 맞는지 평가하는 노력이 있었다면 정말 좋았을 것 같아요❤️

LinusU 에 2019년 06월 10일

👍16 👎1

내가 그 댓글을 놓쳤어! 나는 그들에게 손을 내밀었다.

나는 Hooks가 Flutter에 어떻게 적용되는지 정말로 이해하지 못한다는 것을 인정해야 합니다. 실험하고 싶다면 이미 Hooks 패키지가 몇 개 있습니다(일부는 위의 이 버그에서 언급됨). 근본적으로, 나는 그 개념이 어떤 문제를 해결하는지 정말로 이해하지 못합니다.

내 관점에 대한 자세한 내용은 내 이전 의견을 참조하십시오. https://github.com/flutter/flutter/issues/25280#issuecomment -455846788, https://github.com/flutter/flutter/issues/25280#issuecomment - 455847134, https://github.com/flutter/flutter/issues/25280#issuecomment -456272076.

Hixie 에 2019년 06월 11일

👍6

근본적으로, 나는 그 개념이 어떤 문제를 해결하는지 정말로 이해하지 못합니다.

후크는 상태 믹스인과 비슷하지만 믹스인의 고유한 문제가 없습니다. 변수 충돌이 없고 두 번 이상 사용할 수 있습니다.

Hooks는 Flutter가 현재 상태 저장 위젯에 대해 가지고 있는 가장 큰 문제 중 하나를 해결할 수 있습니다. 바로 이러한 모든 컨트롤러를 처리하는 것입니다.

각 컨트롤러에는 동일한 방식으로 _항상_ 구현되는 initState, didUpdateWidget 및 dispose가 모두 필요합니다.

하나 이상이 필요할 수 있기 때문에 기본 클래스/믹스인으로 추출할 수 없습니다.
따라서 대신에 로직을 모든 곳에 복사하여 붙여넣어야 합니다.
하지만 그것도 별로 좋지 않습니다. dispose 재정의와 같이 단계를 잊어버리기 쉽습니다.

후크의 실제 문제는 구현하는 데 많은 작업이 필요하다는 것입니다.

핵심 프레임워크는 간단합니다. 그러나 고유한 동작으로 인해 린터 및 리팩토링 도구와의 긴밀한 통합이 필요합니다.

그리고 최적의 구현을 위해 튜플/구조 분해와 같은 일부 언어 기능이 필요할 수 있습니다.

rrousselGit 에 2019년 06월 11일

👍15 👎1

나는 이것이 내가 위에서 말한 의견을 실제로 해결한다고 생각하지 않습니다 (https://github.com/flutter/flutter/issues/25280#issuecomment-455846788 및 https://github.com/flutter/flutter/issues/25280# 특히 issuecomment-456272076).

Hixie 에 2019년 06월 11일

흠, @gaearon 이 아마 저보다 더 잘 설명할 것입니다. 하지만 제 관점에서는 다음과 같습니다.

가독성 인수는 위젯의 크기에 따라 다릅니다. 더 큰 위젯에서 후크는 모든 관련 비트가 수명 주기에 걸쳐 분산되는 대신 함께 있기 때문에 실제로 _더_ 더_ 읽기 쉬운 경향이 있습니다.
버그가 적습니다. 그들의 선언적 API는 상태를 업데이트/정리하는 것을 잊는 것을 더 어렵게 만듭니다.
"왜 핵심이어야 합니까?"에 대해 Dan Abramov가 사용한 비유를 좋아합니다.
후크는 전자가 원자에 대해 위젯에 대한 것입니다.
더 큰 것을 만드는 데 사용되는 기본 요소인 경우 제외하는 것은 이치에 맞지 않습니다.
후크를 구현하는 것만이 아닙니다. 전체 프레임워크가 혜택을 받을 수 있습니다.
애니메이션, 양식 등을 개선하는 데 사용할 수 있습니다.

rrousselGit 에 2019년 06월 11일

👍17

@Hixie , Hooks를 사용하는 데 시간을 보냈습니까, 아니면 결정을 내리기 위해 Hooks를 스프레드시트로 작성하고 있습니까? Flutter 팀의 시간 중 몇 %가 고객을 위한 앱 작성과 프레임워크 작성에 소요되는지 잘 모르겠습니다. 고객용 앱을 작성하는 사람들은 프레임워크 개발자와 약간 다른 각도에서 이 질문에 접근할 것이라고 생각합니다. 즉, 기존 솔루션과 동일한 기준을 충족하는 것이 아니라 어떻게 이것이 나를 더 효과적으로 만들고 고객에게 더 많은 가치를 제공할 수 있습니까?

lukepighetti 에 2019년 06월 14일

👍11

나는 최근에 우리의 새로운 인기 앱 중 하나에서 functional_widget과 함께 flutter_hooks를 소개했습니다.

상용구 코드를 크게 줄였으며 모든 지저분한 상태 저장 위젯을 후크가 있는 작은 기능으로 리팩토링한 후 코드베이스가 약 70% 축소되었습니다.

더 높은 수준에서 볼 때 후크 세트가 있는 기능적 위젯은 RX에서 CombineLatest를 사용하여 여러 관찰 가능 항목을 결합하는 필수 단순화와 같습니다. 그러나 서문에 있는 모든 관찰 가능 항목을 명시적으로 언급하고 이에 대해 작동하는 기능을 갖는 대신 후크는 값이 필요한 코드에 연결하기 때문에 훨씬 더 유연합니다.

그러나 결국 이러한 각 위젯은 RX 스트림의 한 단계와 같습니다.

derolf 에 2019년 09월 05일

👍16

나는 확실히 우리가 flutter_hooks를 제거해야 한다고 생각하지 않습니다. 나는 우리(Flutter 팀)가 더 가치 있는 것을 제공할 수 있는지 알지 못합니다.

후크는 전자가 원자에 대해 위젯에 대한 것입니다.

제 생각에는 Flutter를 쿼크 또는 하드론으로 간주해야 한다는 은유를 따른다고 생각합니다. Hooks의 전자는 위의 층입니다.

Hixie 에 2019년 09월 18일

@Hixie , Hooks를 사용하는 데 시간을 보냈습니까, 아니면 결정을 내리기 위해 Hooks를 스프레드시트로 작성하고 있습니까? Flutter 팀의 시간 중 몇 %가 고객을 위한 앱 작성과 프레임워크 작성에 소요되는지 잘 모르겠습니다.

나는 Hooks를 직접 사용하지 않았습니다. Flutter로 앱을 작성합니다. 그렇게 할 때 Hooks와 같은 것이 필요하지 않습니다. 그러나 위에서 언급했듯이 Hooks가 내 개발 스타일과 일치하지 않는다고 생각합니다(저는 상용구를 보는 것을 선호합니다). Hooks를 사용하려는 사람에게서 Hooks를 제거하고 싶지는 않을 것입니다.

Hixie 에 2019년 09월 18일

👍6 👎1

나는 우리(Flutter 팀)가 더 가치 있는 것을 제공할 수 있는지 알지 못합니다.

후크를 진정으로 유용하게 만들려면 분석기 플러그인과 맞춤형 리팩토링 옵션이 필요합니다.
이들만이 후크가 진정으로 빛납니다.

후크를 사용하면 일반적인 StatefulWidget에서는 불가능한 매우 강력한 정적 분석이 가능합니다.
이렇게 하면 위젯의 로컬 상태를 더 안전하고 확장성 있게 관리할 수 있습니다. 나에게 상용구 감소는 보너스일 뿐입니다.

하지만:

매우 낮은 수준의 API에는 _많은 작업_이 있습니다.
분석기 플러그인 인터페이스가 안정적이지 않고 부족하고 거의 사용되지 않으며 팀에서 권장하지 않습니다(각 플러그인에 대해 하나의 분석이 수행됨).
flutter 자체는 플러그인 API를 사용하지 않고 대신 서버에서 직접 구현합니다.

따라서 커뮤니티에서 유지 관리하는 패키지로서 후크에 대한 완전한 도구를 가질 확률은 매우 낮습니다.

제 생각에는 Flutter를 쿼크 또는 하드론으로 간주해야 한다는 은유를 따른다고 생각합니다. Hooks의 전자는 위의 층입니다.

Flutter가 쿼크라면 그것은 은하이기도 합니다.

실제로 Layer 와 같은 매우 낮은 수준의 클래스가 있습니다.
그러나 Switch 와 같은 고급 클래스도 엄청나게 많습니다.

전체 Material 및 Cupertino 라이브러리는 패키지로 추출된 다음 Navigator로 추출되어 관련 객체를 형성할 수 있습니다. 하지만 그들은 그렇지 않습니다.
그리고 후크는 이것들보다 아래에 있는 몇 개의 레이어입니다.

rrousselGit 에 2019년 09월 18일

👍5

관련이 없지만 Material과 Cupertino는 초저수준 구성요소와 Material 고급 구성요소 사이에 좋은 인터페이스가 부족하기 때문에 핵심 Flutter 라이브러리에 포함되어서는 안 된다고 강력히 믿습니다. Material 라이브러리 없이 앱을 만들어 본 적이 있다면 엄청나게 어렵습니다.

lukepighetti 에 2019년 09월 18일

👍4

후크는 실제로 상용구를 줄이는 것만큼 중요한 것이 아닙니다. (우리는 상용구도 신경 쓰지 않습니다.) 나에게 가장 중요한 가치는 상태 저장 논리를 캡슐화하고 구성할 수 있다는 것입니다.

const [value, setValue] = useState(0)
const debouncedValue = useDebounced(value, 1000)
const interpolatedValue = useSpring(debouncedValue, {
  friction: 10,
  mass: 20
})

상태가 포함되어 있는지 여부에 대해 걱정하지 않고 데이터를 파이프할 수 있고 이 논리를 사용자 정의 Hook으로 추출하거나 동일한 Hook을 여러 번 적용할 수 있다는 것은 매우 표현력이 뛰어납니다. 그리고 Rx와 같은 접근 방식과 달리 실제로 결합자를 살펴보지 않고도 모든 코드를 단계별로 실행할 수 있습니다.

gaearon 에 2019년 09월 18일

👍18

후크를 진정으로 유용하게 만들려면 분석기 플러그인과 맞춤형 리팩토링 옵션이 필요합니다.
이들만이 후크가 진정으로 빛납니다.

이를 지원해야 한다는 데 동의합니다. 하지만 그것은 Dart GitHub 프로젝트에 대해 제기된 버그여야 합니다. 확실히 Dart 코드베이스에서 Flutter 관련 린트를 옮기고 싶습니다.

전체 Material 및 Cupertino 라이브러리는 패키지로 추출된 다음 Navigator로 추출되어 관련 객체를 형성할 수 있습니다. 하지만 그들은 그렇지 않습니다.

예, 아마도 사실이기도 합니다. 그렇게 하지 않는 실질적인 이유가 있습니다(예: "Hello World"를 복잡하게 만들어 Flutter 사용을 시작하기 더 어렵게 만들 수 있음). 하지만 그럼에도 불구하고 고려할 수는 있습니다. 다시 말하지만, 그것은 우리가 그것을 고려하고 싶다면 별도로 제기해야 하는 별도의 문제입니다.

나에게 가장 중요한 가치는 상태 저장 논리를 캡슐화하고 구성할 수 있다는 것입니다.

그것은 참으로 매우 가치 있는 일입니다. 그러나 그것이 핵심 프레임워크에 있어야 하는지는 분명하지 않습니다.

Hixie 에 2019년 09월 18일

🎉3 👍3

그것은 참으로 매우 가치 있는 일입니다. 그러나 그것이 핵심 프레임워크에 있어야 하는지는 분명하지 않습니다.

이렇게 하면 일부 핵심 State 믹스인을 더 이상 사용하지 않을 수 있습니다.

예를 들어 AutomaticKeepAliveClientMixin 는 이상한 위치에 있습니다.
super.build 를 호출해야 합니다. 이는 매우 직관적이지 않습니다. 그리고 super.build 는 nullable이 아닌 유형에서는 작동하지 않는 null 를 반환합니다.
그러나 후크로서 이 두 가지 문제가 모두 해결됩니다.

마찬가지로 후크는 원하는 만큼 재사용할 수 있으므로 SingleTickerProviderStateMixin 및 TickerProviderStateMixin 둘 다 필요하지 않습니다.

또는 후크에는 중요한 커뮤니티 측면이 있습니다. 핵심이 아닌 경우 사용자 지정 후크를 만들고 공유할 가능성이 훨씬 적습니다.

rrousselGit 에 2019년 09월 18일

👍8

IMHO가 가독성을 떨어뜨리기 때문에 우리는 실제로 핵심 프레임워크에서 후크를 _사용_하지 않을 것입니다. 따라서 핵심 프레임워크에 포함하면 다른 코드를 제거하는 데 도움이 되지 않습니다.

또는 후크에는 중요한 커뮤니티 측면이 있습니다. 핵심이 아닌 경우 사용자 지정 후크를 만들고 공유할 가능성이 훨씬 적습니다.

후크가 좋다면 사람들은 그들이 Flutter 오픈 소스 프로젝트에서 왔는지 아니면 Hooks 오픈 소스 프로젝트에서 왔는지에 상관없이 그것을 사용할 것입니다.

Hixie 에 2019년 09월 19일

👍6

IMHO가 가독성을 떨어뜨리기 때문에 우리는 실제로 핵심 프레임워크에서 후크를 _사용_하지 않을 것입니다. 따라서 핵심 프레임워크에 포함하면 다른 코드를 제거하는 데 도움이 되지 않습니다.
또는 후크에는 중요한 커뮤니티 측면이 있습니다. 핵심이 아닌 경우 사용자 지정 후크를 만들고 공유할 가능성이 훨씬 적습니다.
후크가 좋다면 사람들은 그들이 Flutter 오픈 소스 프로젝트에서 왔는지 아니면 Hooks 오픈 소스 프로젝트에서 왔는지에 상관없이 그것을 사용할 것입니다.

나쁜 생각은 아닌 것 같습니다. Hooks는 별도의 오픈 소스 프로젝트로 실행할 수 있습니다. 핵심 팀은 hook 프로젝트의 핵심 변경 요구 사항을 우선적으로 처리합니까? IMHO hook 프로젝트의 성공을 위해서는 상당히 중요합니다.

ivenxu 에 2019년 09월 19일

👍1

"핵심 변경 요구 사항"이란 무엇입니까?

Hixie 에 2019년 09월 19일

"핵심 변경 요구 사항"이란 무엇입니까?

데브툴즈.
주로 분석기 플러그인에 관한 것이지만 잠재적으로 flutter/devtools의 플러그인 시스템에 관한 것입니다.

거기에는 커뮤니티에서 할 수 없는 많은 작업이 포함되어 있습니다.

rrousselGit 에 2019년 09월 19일

IMHO가 가독성을 떨어뜨리기 때문에 우리는 실제로 핵심 프레임워크에서 후크를 _사용_하지 않을 것입니다. 따라서 핵심 프레임워크에 포함하면 다른 코드를 제거하는 데 도움이 되지 않습니다.

모든 존경심을 가지고 있지만 이것은 약간 무지하게 들립니다. 당신은 정말로 그들에게 시도해야합니다! 상태의 각 단일 측면에 대해 initState/dispose/setState/build를 사용하여 춤을 추는 것보다 훨씬 간결합니다.

Flutter는 구성에 관한 모든 것이며 후크를 사용하는 것은 자연스럽게 구성 패턴을 따르는 반면에 mixin을 사용하는 것은 구성의 반대입니다.

derolf 에 2019년 09월 19일

👍13

나는 우리가 분석기를 높은 우선 순위로 확장 가능하게 만드는 것을 계속 고려할 것이라고 생각합니다. 불행히도, 기본적인 첫 시간 작업에 대한 경험 개선 및 기본적으로 nullable이 아닌 변경을 위한 도구 구현과 같은 더 높은 우선 순위가 많이 있습니다.

그렇긴 하지만 Google 직원이 아닌 사람은 왜 이 작업을 수행할 수 없는지 모르겠습니다. Flutter와 Dart는 모두 오픈 소스 프로젝트이며 많은 것들이 Google 직원이 아닌 사람들에 의해 구현됩니다.

Hixie 에 2019년 09월 19일

🎉3

그렇긴 하지만 Google 직원이 아닌 사람은 왜 이 작업을 수행할 수 없는지 모르겠습니다. Flutter와 Dart는 모두 오픈 소스 프로젝트이며 많은 것들이 Google 직원이 아닌 사람들에 의해 구현됩니다.

우리는 팀이 "낮은 우선 순위 기능"으로 간주하고 많은 주요 변경 사항을 포함하여 여러 프로젝트에서 몇 달 동안 작업하는 것에 대해 이야기하고 있습니다. 그리고 영향을 받는 프로젝트는 공개 문서가 거의 없는 매우 낮은 수준입니다.

필요한 투자와 거절의 위험이 / 중간에 갇힐 위험이 너무 높습니다. 특히 우리가 돈을 벌지 못할 때.

그래서 내가 당신의 요점을 이해하는 동안, 그것은 극히 가능성이 낮습니다

rrousselGit 에 2019년 09월 19일

👍11

이에 대한 로드맵이 있습니까? 후크가 플러터에 떨어질 수 있는지, 그리고 언제 가능한지 알고 있습니까?

pie6k 에 2019년 10월 02일

👍3

Flutter가 1년 안에 성공하면(나는 그렇게 되기를 바랍니다) Flutter에 온보딩하려는 모든 React 개발자는 여기에 후크에 대한 일급 지원이 없다는 것을 알았을 때 비명을 지르게 될 것입니다.

Flutter 팀은 클래스 기반 React 모델을 복사하는 좋은 결정을 내렸지만 그것은 이제 과거의 일이고 기능적 구성 요소와 후크는 미래입니다. Flutter 팀이 동등하게 유지하려면 이 새로운 현실에 깨어나야 합니다 .

cgarciae 에 2019년 11월 17일

👍26 ❤7 🎉6 😕2 👎2

cgarciae가 언급했듯이 React 커뮤니티는 앞으로 후크 및 기능 구성 요소로 이동합니다. 그리고 프로그래밍 모델과 생산성이 다른 크로스 플랫폼 개발 솔루션과 동등하지 않기 때문에 Flutter가 구식으로 보입니다.

최근에 반응과 플러터를 모두 사용해 본 결과, 플러터의 후크 누락은 생산성, 일관성 및 유지 관리 측면에서 비교 대상 아파트에 큰 구멍을 남깁니다. 조직이 새 프로젝트에서 flutter를 채택하거나 사람들이 React 기반 솔루션에서 노력할 가치가 있는 flutter로 전환하도록 설득하는 데 도움이 되지 않습니다.

나는 누군가가 도구 세트, 저수준 프레임워크 구현, 상용구 코드를 구축하는 것이 별로 문제가 되지 않을 수 있다는 것을 완전히 이해합니다. 그러나 앱 개발자가 무언가를 작동시키기 위해 "불필요한" 상용구를 많이 작성해야 하는 경우 그 효과는 바람직하지 않습니다.

사람들이 특정 문제를 보는 각도에 따라 절충/균형이 다르게 보일 수 있습니다. 적절한 도구를 제공하지 않거나 특정 기능을 제공하지 않으면 프레임워크 내부 구현이 더 깔끔해 보일 수 있지만 프레임워크 소비자의 책임을 덜어주고 클라이언트 측 구현을 필요한 것보다 더 복잡하고 서투르게 만들며 결과적으로 제공하는 적응에 도움이 되지 않습니다. 뼈대. 애플리케이션 개발자에게는 생산성과 일관성이 중요하며, 팀워크와 커뮤니티를 위해 통합 접근 방식/표준이 중요합니다. 전체적인 접근 방식은 항상 사람들이 울타리 반대편에 살고 있다는 점을 고려해야 합니다.

sunflash 에 2019년 11월 18일

👍16 ❤5

후크는 구현하기 쉬워야 하지만 기능적 위젯은 더 어렵습니다. 다음과 같이 표현해야 하기 때문에 Dart에서 공용체 유형이 필요합니다.

'위젯 | 위젯 기능(BuildContext)'.

derolf 에 2019년 11월 18일

기능적 위젯은 더 어렵습니다. Dart에서 공용체 유형이 필요합니다.

그것은 충분하지 않습니다.
여전히 다음과 같은 질문이 있습니다.

함수에 매개변수를 전달하는 방법? 카레?
위젯 트리에서 두 개의 기능적 위젯은 다른 runtimeType을 가져야 합니다.
devtools로 위젯을 연결하는 방법은 무엇입니까? (위젯의 debugFillProperties 메소드)

나는 꽤 오랫동안 그것에 대해 생각해 왔다. 기능적 위젯에 대한 쉬운 솔루션이 보이지 않습니다.
내가 생각할 수 있는 유일한 것은 코드 생성 및 분석기 플러그인의 조합(적절한 정의로 이동하기 위한 것)입니다.

rrousselGit 에 2019년 11월 18일

👍1

사실, 코드 생성 부분은 우리로 하여금 당신의 functional_widget 패키지에서 빠지게 만들었습니다. 코드를 검토할 때 너무 많은 점프를 생성합니다. 그래서 그것은 나를 위해 날지 않을 것입니다 ...

derolf 에 2019년 11월 18일

코드를 검토할 때 너무 많은 점프를 생성합니다.

따라서 내가 분석기 플러그인을 언급한 이유입니다.

사용자 정의 분석기 플러그인을 사용하면 다음을 수행할 수 있습니다.

함수가 직접 사용되지 않고 클래스가 선호되는지 확인하십시오.
클래스를 클릭하면 함수로 리디렉션되도록 적절한 "정의로 이동"/"피크"/...가 있어야 합니다.

이렇게 하면 모든 문제가 해결됩니다.
그러나 우리는 "후크에는 적절한 분석기 플러그인 시스템이 필요합니다"로 돌아가겠습니다.

rrousselGit 에 2019년 11월 18일

functional 위젯을 도입할 필요가 없을 수도 있습니다.

후크 사용이 StatelessWidget build 메서드 내에서만 허용된다고 가정해 보겠습니다.

기술적인 관점에서 - 그것이 클래스인지 함수인지는 (지금 내가 생각할 수 있는 한) 별로 중요하지 않습니다. 중요한 부분은 상태 저장 클래스와 후크를 혼합하지 않는다는 것입니다. 후드 아래에서 flutter 렌더러는 build 메서드 내에서 호출되고 적절하게 관리되는 경우 후크와 해당 순서를 계속 계산할 수 있습니다.

미래에 기능적 위젯을 만드는 것이 가능하다면 변경 사항을 깨는 것이 아닙니다. 또한 기존 앱을 손상시키지 않기 때문에 이전 버전과 호환됩니다.

StatelessWidget 내부에 후크를 사용하는 것과 관련하여 구성과 같은 후크 사용의 이점을 없애는 명백한 문제는 보이지 않습니다.

그러나 어쨌든 인스턴스 메소드를 사용하는 능력과 비교하여 반응의 useCallback 등과 같은 경우와 비교하면 확실하지 않습니다.

pie6k 에 2019년 11월 18일

👍2

"React 개발자가 화를 낼 것이기 때문에 이것을 추가해야 합니다" 인수가 유효하지 않습니다. (500개 이상의 주석 JSX 토론 참조).

Flutter는 Flutter이며 고유한 언어와 디자인 패턴을 가지고 있습니다.
React 개발자에게 더 친숙하게 만들기 위해 프레임워크에 항목을 추가해서는 안 된다고 생각합니다. 원하는 경우 패키지를 사용할 수 있습니다.

SpajicM 에 2019년 12월 19일

👎20 👍6

토론을 읽었고 Flutter 프레임워크 개발자인 @Hixie 는 문제의 측면(구현 및 ... 항목)을 보았고 Flutter 앱 개발자(그의 대상 고객)가 생각하고 사용하는 방식에 대한 관점이 적었다고 생각합니다. 그들의 발전.

나는 안드로이드 개발자로서 그런 문제가 있었고, 내 앱 사용자가 내 추한 UI와 이해하기 어려운 UX를 볼 때 어떻게 경험할 것인지 전혀 모르는 상태에서 내 애플리케이션을 위한 훌륭한 백엔드 구조를 개발하려고 노력합니다.

다른 사람이 전에 말했듯이 후크는 훌륭합니다. 누가 그것을 소개하든 상관없이 사악한 FB 또는 Apple입니다.
그냥 작동합니다. 상태 논리와 해당 수명 주기를 분리합니다. 우리는 다른 것 위에 유용한 다른 후크를 만들고, 앱 상태에서 독립적인 위젯, API, 도구를 게시하고, 다른 프로젝트에서 미리 제작된 것을 재사용할 수 있습니다.

그리고 pubspec.yaml 에 미리 import material이나 cupertino를 추가하는 것이 간단한 hello-word 앱을 만드는 것이 어렵다면!!! 여기에서는 논의할 것이 없다고 생각합니다.
그러나 StatefullWidget 는 Flutter 생태계에 매우 중요하므로 hook과 관련성은 Flutter의 미래와 생태계 및 Flutter 개발자 커뮤니티에서 더 중요합니다.

어떻게 플러터 앱 개발이 더 간단하고, 버그가 없으며, 이해하기 쉽고, 확장 가능하고, 읽기 쉽고, 디버그 가능하고, 이식 가능하며, 코어(또는 무언가)로 직접 지원되는 후크를 사용하여 ... 핵심과 재료와 같은 일부 복잡한 위젯 사이의 중간에 있습니다. ...) 특별히 공식적입니다.

내 요점을 더 잘 이해하려면 Java 및 지원 라이브러리를 사용한 Android 개발이 얼마나 끔찍했는지, Kotlin에서 얼마나 멋지고 달콤한지 살펴보세요.
Coroutines, Flow, AndroidX + Kotlin 지원, 새로운 UI 시스템(Compose)과 같은 다른 좋은 것들도 가능합니다.
심지어 자바 커뮤니티가 에코에서 kotlin futures를 시작하고 구현하도록 했습니다.

그래서 pls는 후크에 모든 버퍼를 삭제하고 반응하고 그냥 합니다.

HKhademian 에 2020년 01월 31일

👍4

공식 후크 지원의 부족은 내가 반응 네이티브에서 전환하지 않은 유일한 이유입니다.

후크는 삶을 너무 쉽게 만들어 다시는 예전 방식으로 쓰고 싶지 않습니다.

pie6k 에 2020년 02월 25일

"네이티브 후크"의 놀라운 부분은 많은 내부 StatefulWidget 또는 ...을 이 간단하고 이해할 수 있는 형식으로 이식할 수 있다는 것입니다.
또한 Flutter 팀은 Flutter와 Dart가 사용하기 쉽고, 이해하기 쉽고, 빠르게 배울 수 있도록 만들었습니다. Native Hooks를 사용하면 이 모든 것이 사실이고 더 나아질 수 있습니다.
그리고 (initState/dispose/setState/build) 방법은 이 경로에 없습니다. (플랫폼의 백엔드에서는 필요할 수 있지만 새로운 개발자나 심지어 자신의 아이디어를 설명하기 위해 코드를 사용하려는 디자이너에게는 필요하지 않을 수 있습니다(복잡한 논리가 아님)).

HKhademian 에 2020년 02월 27일

👍2

이 스레드에서 읽은 내용은 많은 사람들이 Flutter에서 후크를 사용하는 것에 흥미를 느끼고 있으며 후크에 대한 몇 가지 공개 질문이 있다는 것입니다.

성능 영향/측정 - 특히 항상 함수를 호출하는 효율성 대 해당 상태를 보는 것이 새 함수를 호출하지 않고 재사용하는 것이 좋습니다.
전역 키를 잘 사용하거나 트리 주위를 효율적으로 이동할 수 있는 능력(무능력?)
후크와 관련된 분석기 지원/린트.
일반 이전 상태 저장/상태 비저장 위젯으로 핫 리로드와 함께 작동하는 기능.
추가 프레임워크 API가 필요할 수 있습니다.

이 모든 질문을 해결할 수 있다고 확신하지만, 해결하는 것이 쉬운 일은 아닙니다. 문제는 "후크가 프레임워크에 있어야 하는지 아니면 별도의 패키지에 있어야 하는지"가 아닙니다. 어느 정도 그 결정은 이미 내려졌습니다. flutter_hooks는 pub.dev에서 1년 넘게 사용 가능했으며 인기 있는 패키지로 보입니다. flutter_hooks를 진정으로 세련된 경험으로 만들려면 이미 완료된 것 외에도 상당한 작업과 투자가 필요합니다.

그 많은 작업이 이미 핵심 프레임워크 클래스에 대해 수행되었으며 _여러 개의 엔지니어링 팀과 여러 오픈 소스 기여자가 있는 지점에 도달하는 데 수년이 걸렸습니다. 때로는 "repo X에 병합하면 해결되지 않은 모든 것이 해결됩니다!"라는 환상이 있는 것 같습니다. 그러나 이러한 일이 발생하는 방식은 그것에 대해 흥분하는 사람들이 구현 작업을 수행한다는 것입니다. @rrousselGit 은 이 문제를 해결하기 위해 이미 많은 작업을 수행했으며, 다른 여러 기여자들도 후크 저장소에 있는 것처럼 보입니다.

간단히 말해서 후크는 Flutter 저장소에 있지 않아도 훌륭하게 작동할 수 있고, Flutter 저장소에 있다고 해서 미해결 문제를 더 빨리 해결할 수는 없으며 Hooks가 Flutter에서 작동하는 것을 보고 싶어하는 모든 사람이 그렇게 할 수 있는 권한이 완전히 있습니다.

dnfield 에 2020년 02월 27일

👍5 👎1

글쎄, 내 의견으로는 후크는 대신 sync /async 생성기와 유사한 언어 기능이어야 합니다.
그것은 플러터와 전혀 관련될 필요가 없습니다.

후크가 해결하는 문제는 다음과 같습니다.

선언적 및 반응적 상태 관리.
State 는 필수입니다.
DRY를 수정하기 위한 상태 구성.
이러한 모든 XXController는 생성+업데이트+폐기되어야 하며 해당 논리를 인수분해할 방법이 없습니다.
가독성, 그 결과를 달성하기 위해 함수/위젯의 끝없는 중첩을 포함하지 않기 때문에

그러나 대체 구문은 다음과 같을 수 있습니다.

class MyWidget extends HookWidget {
  const MyWidget({Key key, this.title}): super(key: key);

  final String title;

  Hook<Widget> build() hook* {
    final (flag, setFlag) = yield false;
    final (animationController) = yield* useAnimationController(duration: const Duration(seconds: 2));

    // TODO: do something with animationController
    return CheckBox(
      value: flag,
      onChanged: setFlag,
    );  
  }
}

Hook<AnimationController> useAnimationController({required Duration duration}) hook* {
  final (tickerProvider) = yield* useTickerProvider();
  final (animationController) = yield AnimationController(duration: duration, vsync: tickerProvider);
  animationController.duration = duration;

  return animationController;
}

이것은 flutter_hook과 동일한 효과를 달성하지만 flutter와 독립적이며 flutter_hook이 할 수 없는 여러 최적화 요소를 사용합니다.

그리고 이것은 기본적으로 _anything_이 위젯뿐만 아니라 후크를 사용할 수 있도록 합니다.

rrousselGit 에 2020년 02월 27일

👍4

흥미로운 아이디어네요. 거기에 여러 언어 기능 요청이 있는 것처럼 들립니다(Go의 defer , C++의 결정적 소멸자, 암시적으로 기능을 개체로 구성하는 기능) - 그러나 이것은 실제로 올바른 위치가 아닙니다. 추적할 수 있습니다.

Flutter에 후크와 같은 기능이 없어 사람들이 겪고 있는 문제를 식별하고, 시작할 솔루션을 선택하지 않고 해당 문제에 대해 구체적으로 문제를 제기하는 것이 중요하다고 생각합니다. 그러나 이러한 고충 중 일부는 성능, 품질 또는 사용성 트레이드오프에 대한 목표를 달성하기 위해 프레임워크가 강제하는 것일 수도 있습니다(예: 고통점 Y를 훨씬 더 악화시키는 비용).

현재 상태로 이 문제를 종료하겠습니다. 이 특정 솔루션을 다루는 좋은 패키지가 있으며 솔루션 자체는 현재 상태에서 프레임워크에 병합할 준비가 된 것이 아니며(위에 설명된 이유로) 솔루션이 실제로 프레임워크에 병합되는 이점을 얻을 수 있습니다.

dnfield 에 2020년 02월 27일

👎6 👍6 😕3

@dnfield Hooks는 요구 사항의 모든 주요 영역을 다룰 때만 '가족'처럼 잘 작동합니다.

상태 변경 후 어떤 종류의 효과가 필요할 때 벽에 부딪히면 상태 후크를 사용하는 것은 쓸모가 없습니다.

설계상 모든 후크는 렌더러의 코어 내부에 상당한 변경이 필요하거나 새로운 종류의 코어 구성요소를 도입해야 합니다.

그런 노력은 한 종류의 훅(고통점)에 대해서만 가치가 없기 때문에 이 문제를 작은 문제의 집합으로 해결하는 것은 불가능하다고 말하고 싶습니다. 단일 후크는 상태 저장 구성 요소에서 전환할 가치가 없으며 렌더링 엔진에 중요한 변경 사항을 도입할 가치도 없습니다.

pie6k 에 2020년 02월 27일

이 문제가 "나는 Flutter가 React와 같으면서도 Flutter와 같기를 원합니다"라고 말하는 것이라면 그것이 얼마나 실행 가능한지 잘 모르겠습니다. 그리고 GitHub 문제는 아마도 그런 것을 추적하는 올바른 방법이 아닐 것입니다. 우리가 그러한 것을 추적하는 것이 합리적이라고 인정하더라도.

다시 말해 Flutter의 핵심을 다시 작성해 달라는 요청이라면 접근 방식이 옳지 않습니다. 접근하는 올바른 방법이 무엇인지는 모르겠지만 저장소를 분기하고 엄청난 노력을 기울이는 것으로 시작될 것입니다.

dnfield 에 2020년 02월 27일

👍4 👎3

후크를 알지 못하고 다른 기술을 유지 관리하는 사람들에게 후크가 도입되면 이상한 느낌이 듭니다.

"X가 React와 같게 하려면 반응을 사용하십시오"와 같은 응답이 자주 있는 것 같습니다.

내 생각에 후크는 복잡한 데이터 로직을 재사용해야 하는 많은 프런트엔드 문제에 대한 일반적인 솔루션입니다. 어떤 기술에서나 사용할 수 있는 아이디어에 가깝습니다.

그러나 후크는 값이 완전히 표시되기 전에 데이터 흐름에 대해 생각하는 데 일종의 전환이 필요합니다. 다른 프레임워크에서 후크를 "요청"할 때 큰 문제가 될 수 있다고 생각합니다.

나는 React 팀이 hooks를 설명하기 위해 훌륭한 일을 했다고 생각하지만, hooks가 React와 강하게 관련되어 있는 것처럼 보이게 하기 때문에 약간의 저항이 생길 수 있습니다.

나는 React가 다음 훅이 발명된 곳이기 때문에 자주 언급된다고 생각합니다. React는 또한 (지금까지) 후크에 대한 최고의 정보 소스입니다.

일반적으로 - Flutter에서 직접 데이터 논리에 구성 패턴을 사용할 수 없다는 "고통점"을 설명합니다. 후크는 이를 허용하는 예시일 뿐입니다.

또한 후크를 도입하는 것이 엄청난 작업이라는 것을 이해하고 있으며 수행할 의사가 없다고 말해야 합니다.

pie6k 에 2020년 02월 27일

👍2

나는 개인적으로 "커뮤니티가 그 문제를 해결하려고 했기 때문에 우리는 아무것도 할 필요가 없다"는 주장을 이해하지 못합니다.

커뮤니티 수정이 Google에서 더 잘할 수 없다는 의미는 아닙니다.
컬렉션 내부의 표현식을 예로 들어 보겠습니다.
커뮤니티는 null 를 지원하도록 Row/Column/ListView/... 를 분기하여 "수정"할 수 있습니다.
그러나 Google은 언어를 수정하여 문제를 해결했습니다.

또한 Flutter 자체에서 다음과 같이 말합니다. Flutter는 React에서 영감을 받았습니다.
이것은 Widget이 사용되는 방식의 큰 부분이 기본적으로 React 클래스가 사용되는 방식을 보면 알 수 있습니다.

이것이 Flutter가 React와 일치해야 한다는 의미는 아니지만 Flutter 팀이 최소한 React 업데이트와 생태계를 면밀히 살펴보기를 기대합니다.
이것은 커뮤니티 주장 외에 "프레임워크에서 후크를 원하지 않는" 이유에 대해 최소한 더 나은 답변을 제공해야 합니다.

rrousselGit 에 2020년 02월 28일

👍5

@rrousselGit @pie6k

저는 개인적으로 Hooks API가 React에서와 같이 이해하기 어렵다고 생각합니다. 나는 수명 주기 방법과 설명이 포함된 이름을 선호합니다.

나는 이것이 "나의 문제"라는 것을 알고 있지만 우리가 문제를 받아들이고 솔루션을 다르게 구현해야 한다고 말하는 @dnfield 의견을 지지합니다.

또한 두 개의 개별 위젯이 동일한 논리를 공유해야 하는 상황에 거의 도달하지 않았습니다(이것이 Hooks의 주요 이점으로 이해한 것입니까?)

Flutter가 React에서 영감을 얻었다는 것은 괜찮습니다. 하지만 이것이 모든 React 패턴과 아키텍처를 영원히 따를 것이라는 의미는 아닙니다.
내가 React에서 겪었던 주요 문제 중 하나는 무언가를 하는 방법이 너무 다양하고 "권장 사례"가 매일 변경된다는 것입니다. 그것이 소프트웨어 엔지니어링의 특성이라는 것을 이해하지만, 여전히 기존 방식에 나쁜 점이 있다면 개선을 시도해야 한다고 생각합니다. 같은 것을 달성하기 위해 여러 가지 방법을 쌓는 대신…

나는 이것이 당신에게 약간 다른 관점을 제공하고 누군가의 기분을 상하게 하지 않기를 바랍니다.

Flutter 커뮤니티에 대한 귀하의 기여에 대해 깊은 존경을 표합니다.

SpajicM 에 2020년 02월 28일

슬프게도 이 문제는 종료되었습니다. Flutter 팀이 후크에 대해 무지하거나 디자인 패턴의 현재 상태에 관심이 없는 것처럼 보입니다(그렇지 않기를 바랍니다). 이것은 어떤 기술에도 좋지 않습니다. 수백 시간을 투자하는 사람들은 자신이 사용하는 것이 최고 수준이고 그에 필적할 수 있다는 것을 알고 싶어하며 현재 가장 생산적인 패턴은 후크이고 Flutter는 뒤쳐져 있지만 유지 관리자가 설득력 있게 더 나은 대안을 위해 고려하거나 무시하지도 않습니다.

cgarciae 에 2020년 02월 28일

👍4

@cgarciae 아무도 무지하지 않습니다. @dnfield 는 분명히 말했습니다. 기존 솔루션을 짜내려고 하는 대신, 해당 문제에 대한 문제를 열어서 Flutter 팀이 이를 평가하고 아마도 Flutter에 더 적합한 솔루션을 제시할 것입니다.

SpajicM 에 2020년 02월 28일

😕2

이것은 커뮤니티가 강력하게 요청하고 요청하려고 하는 기능입니다. 문제가 올바른 위치가 아닌 경우 커뮤니티에서 요구 사항을 등록하는 기능 요청이 있습니까?

ivenxu 에 2020년 02월 28일

👍6

@SpajicM 나는 대답으로 "아니오"로 완전히 괜찮습니다.
내가 동의하지 않는 것은 현재의 정당성입니다.

몇 가지 참고 사항:

후크는 Flutter의 아버지인 React의 중요한 기능입니다.
이 문제는 Flutter에서 가장 많은 투표를 받은 문제 중 하나입니다.
flutter_hooks는 꽤 유명합니다.
React 팀의 Dan Abramov는 팀과 논의할 것을 제안했습니다. https://github.com/flutter/flutter/issues/25280#issuecomment -456404333

이것들은 후크에 대해 논의하는 데 집중해야 합니다. 반드시 구현하지는 않지만 최소한 탐색합니다.

결국 소통의 문제로 귀결된다.

Flutter 팀이 Dan Abramov가 제안한 대로 React 팀에 연락했습니까?
팀이 React에서 hook을 실험했나요?
후크가 해결하는 문제에 대한 대안이 고려되었습니까?

커뮤니티로서 우리는 그것에 대해 아무것도 모릅니다.

한 걸음 더 나아가 React 팀이 Flutter 팀에 이러한 문제가 무엇인지 설명하겠다고 제안했을 때 커뮤니티가 이 문제를 "훅이 해결하는 문제는 무엇입니까"로 나누도록 제안된 것은 아이러니컬하다고 생각합니다.

rrousselGit 에 2020년 02월 28일

👍9

@rrousselGit 나는 그 이면에 있는 아이디어가 사용자로부터 직접 Flutter 관련 측면의 문제를 듣고 React의 추론을 취하는 대신 출발점으로 받아들이는 것이라고 생각합니다. 즉, 그들의 입력이 가치가 없다는 말은 아닙니다.

내 생각에는 위젯의 논리와 디자인을 명확하게 구분할 수 있는 방법이 있으면 좋을 것 같습니다. 그래서 해결해야 할 문제가 있다는 데는 동의 하지만 React가 수행하는 방식이 저에게 다소 혼란스럽고 Flutter의 미래 솔루션이 덜 극적인 패러다임 변화/학습 곡선. 생각은 없지만 열린 마음을 갖고 기존 Hooks 구현에 고정되지 않는다면 커뮤니티와 팀이 함께 뭔가를 생각해낼 수 있을 것이라고 확신합니다.

다음 단계는 다음과 같은 문제를 여는 것입니다.

_"Flutter는 위젯 로직을 분리하기 위한 더 나은 방법이 필요합니다"_

SpajicM 에 2020년 02월 28일

나는 https://svelte.dev/ 가 이러한 문제를 해결하기 위한 다른 더 나은 접근 방식을 가지고 있다고 생각합니다. 첫 번째 단계로 Flutter 팀은 문제가 있고 해결책이 필요하다는 것을 인식해야 합니다.

ansarizafar 에 2020년 02월 28일

👍5

저는 플러터가 처음이고 API에 많은 상용구가 있다는 느낌이 듭니다. Dart에는 일반 기능이 있다고 생각했는데 복사하여 붙여넣기가 더 일반적이고 더 쉬운 Go에서 프로그래밍하는 것처럼 느껴집니다. 특히 확장 방법을 최대한 사용하여 NNDB가 출시될 때 엄청난 리팩토링이 있기를 바랍니다. 확장 메서드와 같은 것을 통한 점진적 API 추상화는 탐색할 가치가 있습니다.

DrSensor 에 2020년 02월 28일

IMHO, Flutter 팀은 "모든 것이 위젯이다"라는 아이디어에 너무 열중하고 있습니다. 위젯은 시각적 항목 및 레이아웃에 적합하지만 데이터 가져오기/처리에는 적합하지 않습니다. 번거로운 FutureBuilder , StreamBuilder , TweenAnimationBuilder 등 대신 기능적 API를 선호합니다.

Widget build(BuildContext context) {
    final a = useFuture(someFuture);
    final b = useStream(someStream);
    if (a.value == null || b.value == null) {
        return CircularProgressIndicator();
    }

    final value = a.value + b.value;
    final smoothedValue = animate(value, duration: Duration(milliseconds: 100), curve: Curves.easeInOut);

    return Slider(
        value: smoothedValue
    );
}

사실 Flutter는 이미 몇몇 곳에서 후크를 사용하고 있습니다. 그래서 "Fluttery"보다

MediaQueryGetter {
    builder: (BuildContext context, MediaQueryData data) {
        ...
    }
}

당신이 사용할 수있는
final data = MediaQuery.of(context);

불행히도 이 메커니즘(가져오는 동안 구독)은 InheritedWidget과 함께만 작동합니다.

t-artikov 에 2020년 02월 28일

👍3

이 부분에서 얼마나 더 발전할 수 있을지는 모르겠지만 여기서 보고 있는 몇 가지 사항을 말씀드리고자 합니다.

GitHub 문제에서 _problem_을 평가하는 것보다 _solution_을 평가하는 것이 훨씬 더 어렵습니다. 솔루션을 제시할 때 승인을 얻기 위해 도달해야 하는 훨씬 더 높은 기준이 있습니다. 솔루션이 잘 구성되었으며 그에 따른 노력의 가치가 있으며 필요한 노력 수준에 상응하는 몇 가지 실제 문제를 해결한다는 것을 보여주어야 합니다(초기 프로토타입 제작 및 구현뿐만 아니라 지속적인 관리 및 품질 포함). . 다시 말해, 데이터 및 위젯 상태 관리와 관련된 특정 문제를 논의하는 문제는 많은 솔루션으로 이어질 가능성이 높습니다. 그 중 일부는 프레임워크에 채택될 수 있고 일부는 타사 패키지가 될 수 있으며 일부는 그 중 하나는 좋지만 비용이 너무 많이 듭니다.
Flutter 및 Dart에서 작업하는 Google 엔지니어는 항상 더 나은 기능을 제공하기 위해 노력하고 있으며 일반적으로 항상 분주합니다. Flutter에 기여하는 많은 비 Google 엔지니어도 마찬가지입니다. 이 버그가 닫혔다고 해서 어떤 Google 엔지니어도 Flutter에서 후크가 더 잘 작동하도록 하는 작업을 하지 않을 것이라는 의미는 아닙니다. 후크 패키지가 커뮤니티 구성원의 소유라는 사실은 패키지의 품질이나 그 가치를 어떻게든 떨어뜨리지 않습니다. 또한 분석/린팅에 대한 더 나은 지원과 같이 이 버그에서 식별된 일부 단점을 충족하는 능력을 감소시키지도 않습니다.
기능을 수락하거나 거부하는 데에는 여러 가지 이유가 있습니다. 때로는 기능이 정말 멋지지만 아키텍처와 잘 맞지 않는 경우가 있습니다. 때로는 기능이 표면적으로는 좋아 보이지만 해결되지 않은 몇 가지 주요 단점이 있습니다. 때로는 기능이 훌륭하고 충분한 노력을 기울이면 적합하지만 비용이 사용자에게 제공하는 가치보다 크거나 다른 훨씬 더 가치 있는 기능에 필요한 시간을 빼앗을 수 있습니다. 특히 Flutter의 경우 때로는 타사 패키지로 확장할 수 있는 고도로 계층화된 아키텍처가 있기 때문에 프레임워크에 새로운 것을 포함하는 것보다 배치를 유지하고 타사가 훌륭한 작업을 수행할 수 있도록 하는 것이 여러 번 더 좋습니다. https://github.com/flutter/packages/tree/master/packages/animations에 있는 새로운 애니메이션 패키지와 같은 패키지에서 이 작업을 직접 수행합니다.

마지막으로, 나는 이것의 반대편에 있었습니다. 저는 패키지 관리자이며 패키지를 더 쉽게 유지 관리하거나 개발할 수 있도록 하는 기능 제안을 거부했습니다. 내 유일한 조언은 마음에 드는 훌륭한 패키지가 있으면 계속 작업하라는 것입니다. 이 저장소에 포함되어 있는지 여부에 관계없이 다른 사람들도 이를 인식하고 도움을 줄 것입니다.

dnfield 에 2020년 02월 29일

👍5 👎2

Android 새 ComposeUI에는 상태와 같은 후크가 있습니다. (preview2)

val state = remember { CardDesignerState() } // react: let state = useState(CardDesignerState())
val thing = stateFor<T?> { null } // react: let thing = useState()

또한 iOS의 새로운 SwiftUI에는 비슷한 것들이 있습니다(그러나 내부적으로).

// from https://developer.apple.com/tutorials/swiftui/animating-views-and-transitions
Image(systemName: "chevron.right.circle")
                        .imageScale(.large)
                        .rotationEffect(.degrees(showDetail ? 90 : 0))
                        .scaleEffect(showDetail ? 1.5 : 1)
                        .padding()
                        .animation(.easeInOut)

iOS의 swiftUI가 onCreate, onInit, onUpdate, onExit, ... 🤢

그러나 최고의 프레임워크(물론 Flutter임)는 여전히 후크 사용 아이디어에 저항합니다. 그 이유는 무엇입니까?
React/ReactNative처럼 생겼으니까!!! 또는 유지 관리자 팀의 놀라운 인용문:

나는 상용구를 보는 것을 선호한다

분명히 선언적 구문 으로 UI를 작성하는 플러터 아이디어에 반대합니다.

후크 믹스 인이 좋은 솔루션이라고 생각합니다.
우리가 좋아하는 곳에 후크를 두고 구식 개발자 코드와 프레임워크를 건드리지 마십시오.
그러나 이 아이디어와 다른 훌륭한 아이디어는 핵심 라이브러리와의 긴밀한 통합이 필요하며 이러한 기능을 일급 지원하는 핵심 유지 관리자를 보는 것이 좋습니다.
또한 후크 통합 이후의 미래를 상상할 수 있습니다. 많은 최상위 프레임워크 라이브러리(예: 머티리얼)가 크게 지원하고 사용하기까지 합니다.

Flutter가 더 아름다울 수 있습니다.

// this is just scratch, not a complete and true use-case
build(context) {
    final angle = useAnimation(2*PI, 0, 5 /*seconds*/);
    return Image.from(myAwesomeImage)
        .padding(8)
        .scale(2.5)
        .rotate(angle);
}

HKhademian 에 2020년 06월 17일

👍7 ❤5

@HKhademian 전적으로 동의합니다. 후크와 같은 것(또는 다른 용어로 재사용 가능한 비즈니스 로직의 적절한 구성을 허용하는 것)에 대한 일급 지원의 부족은 사실 제가 마지막 프로젝트에서 Flutter를 선택하지 않은 유일한 이유입니다.

pie6k 에 2020년 06월 17일

2. 후크 패키지가 커뮤니티 회원의 소유라는 사실은 패키지의 품질이나 가치를 어떻게든 떨어뜨리지 않습니다. 또한 분석에 대한 더 나은 지원과 같이 이 버그에서 식별된 일부 단점을 충족하는 능력을 감소시키지도 않습니다. /린팅

커뮤니티 회원이 패키지를 고스트합니까? 예. Google은 고스트 코어 Flutter를 사용할 예정입니까? 글쎄요, 당신의 입장에 따르면 그럴 가능성이 있는 것 같습니다. 핵심 Flutter가 커뮤니티 패키지만큼 소비에 실행 가능하다고 주장하는 것은... 기껏해야 잘못되고 최악의 경우 거짓말입니다.

또한 커뮤니티 요청을 무시하기 위해 개인 선호도를 사용하는 것에 대한 친화성을 입증한 @Hixie 의 동의가 없으면 커뮤니티가 원하는 것이나 필요로 하는 것이 중요하지 않다는 것이 여러 번 입증되었습니다. 구매하지 않고는 발생하지 않습니다. 그렇지 않은 경우 결정 프로세스가 너무 불투명하여 달리 볼 수 없습니다.

내가 관심을 갖는 것은 기능의 존속 여부를 결정하는 사람들이 모바일 앱을 구축하는 비즈니스 경험이 거의 없는 것처럼 보인다는 것입니다. 이러한 관점은 항상 Flutter에 혼합할 설탕에 대한 가장 큰 통찰력을 제공합니다.

의사 결정 프로세스에 기여하기 위해 커뮤니티에 더 많은 비중을 두는 Flutter의 기능을 결정하기 위한 공식화된 프로세스가 필요하다고 생각합니다. 분명히 100%는 아니지만 지금 당장은 약 5%, 그 정도면 슈퍼 플레이키 5%처럼 느껴집니다. @timsneath

lukepighetti 에 2020년 06월 17일

👍8

GitHub 문제에서 문제를 평가하는 것보다 솔루션을 평가하는 것이 훨씬 더 어렵습니다.

React 팀은 이 문제의 시작 부분에서 Hooks의 이유를 설명하겠다고 제안했습니다.
React 팀보다 후크를 더 잘 설명할 수 있는 사람이 없기 때문에 후크가 필요한 이유를 설명해야 합니다.

rrousselGit 에 2020년 06월 17일

👍8 👀3

관련 이슈(메타) https://github.com/flutter/flutter/issues/28884

lukepighetti 에 2020년 06월 17일

루크, 나는 당신의 열정을 존중하고 감사합니다. 하지만 광고 인신공격은 그만하세요. 우리는 모두 리소스 용량, 사용자 연구, 이해 관계자 입력, 고객 요구 및 커뮤니티 입력을 기반으로 모든 종류의 절충안을 만들어 우리가 할 수 있는 최고의 플랫폼을 구축하기 위해 노력하고 있습니다.

친절하세요. https://github.com/flutter/flutter/blob/master/CODE_OF_CONDUCT.md

timsneath 에 2020년 06월 17일

👍2

인신공격은 의도하지 않았습니다. 피드백 감사합니다. CoC에 따르면 우리는 함께 모여 내가 전달하려는 내용을 논의해야 합니다.

의견이 다른 사람들이 모여서 서로의 관점을 이해하고 모든 사람의 관심사를 해결할 수 있는 디자인을 찾기 위해 노력해야 합니다.

lukepighetti 에 2020년 06월 17일

👍4

이에 대한 업데이트가 있었습니까? 아니면 어디에서 솔루션을 조정할 수 있습니까? 저는 Flutter 프로젝트, 특히 Animations 및 Transitions에서 이 문제를 겪고 있습니다. 후크는 무엇보다도 이 initState 및 dispose 상태를 단일 함수로 캡슐화하고 모든 것을 설정하는 대신 해당 함수를 사용하는 데 도움이 됩니다.

Flutter Overlays(#50961)의 다른 문제와 같이 플러그인 유지 관리자가 아닌 Flutter의 외부 관찰자/사용자에게 들리는 것처럼 느껴지지 않는 합법적인 문제가 있다고 생각합니다. ), 그리고 그것들은 메인테이너라기 보다는 사용자들에게 실질적인 문제가 아닌 것으로 일축된 것 같다. 다시 말하지만, 관리자에 대한 무례함은 없습니다. 이것은 누군가가 이 문제 스레드를 아무렇지 않게 읽는 내 의견일 뿐이며 다른 문제에 대해서는 잘 알지 못합니다.

그렇다면 사용자가 합법적으로 가지고 있는 것처럼 보이는 문제에 대한 솔루션을 생각하는 데 있어 보다 일반적으로 어떻게 진행할 수 있습니까? 나는 Rust가 새로운 솔루션을 설계하는 데 잘 작동하는 것처럼 보이는 흥미로운 RFC 시스템을 가지고 있다는 것을 알고 있습니다.

satvikpendem 에 2020년 07월 26일

👍2

@satvikpendem 여기에서 RFC 프로세스는 문제를 설명하는 버그를 제출하고 문제가 명확하게 설명되면 가능한 솔루션을 논의하는 것입니다.

Hixie 에 2020년 07월 28일

👍1

지금까지 문제가 설명된 것 같으므로 이제 귀하의 의견에 따라 솔루션을 논의할 수 있습니다. 다음으로 할 수 있는 일은 후크 또는 이와 유사한 것보다 더 잘 작동하는 다른 솔루션이 있습니까?

satvikpendem 에 2020년 07월 28일

버그를 알려주시면 # 문제가 가능한 솔루션에 대해 논의하는 것이 타당할 만큼 충분히 자세하게 문제를 설명하는지 알려드릴 수 있습니다.

Hixie 에 2020년 07월 28일

👍1

@hixie https://github.com/flutter/flutter/issues/51752

또한 Dan의 의견에 대한 후속 조치가 있어야 한다고 생각합니다. https://github.com/flutter/flutter/issues/25280#issuecomment -456404333
이 토론의 결과는 무엇이었습니까?

rrousselGit 에 2020년 07월 28일

안녕 Remi, 버그 #51752에 대해 정말 감사합니다. 나는 당신이 이 공간에 엄청난 시간을 투자했고 여기에 매우 가치 있는 패키지를 제공했다는 것을 알고 있습니다. x1000 감사합니다!

@dnfield 의 의견 을 반복하자면, 우리는 아직 문제 영역과 그 중요성에 대해 조정하지 않은 것 같습니다. 위의 버그 는 해당 목표를 향한 유용한 단계 및/또는 문제에 대한 잠재적인 접근 방식을 논의하는 데 유용합니다. 여기에 있는 귀하의 후속 질문은 React 팀과의 대화가 여기에서 첫 번째 단계라고 가정하지만 아직 문제 영역에 대한 조정이 없다면 시기상조로 보입니다.

timsneath 에 2020년 07월 28일

아마도 우리는 후크로 수정될 그러한 문제가 있는 앱의 전체 예를 보여줄 수 있습니다. 후크로 다시 작성할 필요는 없지만 복사 붙여넣기가 얼마나 되는지 보여줍니다. @timsneath, 토론에 적합한 것입니까? 아니면 다른 생각을 하시겠습니까? 문제 공간을 가능한 한 명확하게 표시하는 방법을 알아 내려고 노력하고 있습니다.

satvikpendem 에 2020년 07월 28일

:웨이브: @timsneath
솔직히 말하면 왜 React 팀과 논의하는 것이 시기상조인지 잘 이해가 되지 않습니다.

후크를 요청하는 커뮤니티가 없더라도 React 팀과의 토론은 여전히 매우 중요합니다.
React는 Flutter와 많은 유사점을 공유하며 위젯과 같은 객체를 다루는 데 몇 년의 추가 경험이 있습니다.

그들과 논의하는 것은 양 당사자에게만 이익을 가져다 줄 수 있습니다.

예로서:
flutter_hooks를 만든 후 Dan으로부터 연락을 받아 후크에 대한 핫 리로드를 처리하는 방법에 대해 논의했습니다.
내 대답은 "Flutter가 유형 언어를 사용하기 때문에 할 일이 거의 없었습니다"였습니다.
몇 개월 후 Babel을 사용하여 유형과 유사한 것을 생성하여 React의 핫 리로드를 개선했습니다.

Flutter와 React 팀이 논의했다면 그러한 상호 작용이 많이 일어날 수 있고 두 기술 모두 발전할 것이라고 확신합니다.

특정 문제 없이 질문할 수 있는 몇 가지 개방형 질문:

왜 후크?
왜 서스펜스/동시 모드인가?
왜 포털인가?

rrousselGit 에 2020년 07월 28일

👍11 ❤1

@satvikpendem 여기에서 RFC 프로세스는 문제를 설명하는 버그를 제출하고 문제가 명확하게 설명되면 가능한 솔루션을 논의하는 것입니다.

이것은 버그가 아닌 모든 토론이 무시된다는 것을 의미합니까? RFC의 목적은 버그가 아니라 일반적으로 개발자 경험이나 도구 의미와 같은 보다 주관적인 것을 확장하는 것이라고 생각했습니다.

누군가가 "후크가 여러 프레임워크에서 관용적이 되고 있고 사람들이 개선된 경험과 생산성을 보고하기 때문에 후크가 있어야 한다고 생각합니다."라고 말한다면 이는 유효한 토론이지만 재현 가능한 버그는 아닙니다.

lukepighetti 에 2020년 07월 28일

나는 아무도 "버그가 아닌 토론은 무시될 것이다"라고 말한 사람이 없다고 확신합니다. 자, 서로를 존중하고 예의 바르게 대하면서 선의로 함께 일합시다. 우리는 모두 여기에서 최선을 다하고 있지만, 우리의 관심을 끌기 위해 경쟁하는 다른 많은 버그, 디자인 및 아이디어가 있습니다. :)

@lukepighetti , 아이러니하게도 "다른 프레임워크에 후크가 있기 때문에 후크가 있어야 합니다"는 실제로 우리가 피하려고 하는 대화의 종류입니다. 왜냐하면 정의에 따라 다른 프레임워크의 요구에 최적화된 디자인으로 이어지기 때문입니다. Flutter의 맥락에서 해결하려고 하는 문제를 설명하는 과정에서 정말 도움이 됩니다. 이는 문제가 동일한지 여부, 솔루션이 동일해야 하는지 여부 등에 대해 모두 동의하는 데 도움이 되기 때문입니다.

@rrousselGit -- 물론, React 팀과 할 수 있는 유용한 일반적인 대화가 있습니다. 나는 그 제안을 환영하며, 아마도 우리는 언젠가는 그렇게 해야 할 것입니다. 그들은 확실히 그 팀에 많은 영리함을 가지고 있으며 그들의 제안은 매우 은혜롭고 친절합니다. 지금 당장은 논의할 수 있을 만큼 충분한 정보를 얻은 특정 질문이 있기 때문이 아니라 귀하가 요청했기 때문에 주로 그들과 이야기하고 있습니다. :)

또한, "Flutter 팀"은 Flutter에 기여하는 사람들일 뿐이라는 사실을 상기시켜 드립니다. 일부 기여자는 Google에서 일하고 일부 기여자는 프로젝트 아키텍처를 관리하는 데 더 강력한 역할을 하지만 프로젝트에 기여하는 다른 사람과 마찬가지로 Flutter 팀에도 있습니다. :)

언제나처럼 -- 감사합니다 -- 이 문제를 논의하는 데 있어 인내심을 갖고, 커뮤니티에 기여하고, 이 공간에서 창의적인 아이디어로 프로젝트를 계속 추진해 주셔서 감사합니다!

timsneath 에 2020년 07월 28일

명확히 하자면, 우리가 사용하는 "버그"는 변경으로 이어질 수 있는 모든 것을 지칭하는 일반적인 용어입니다. 유스 케이스일 수도 있고, 아이디어일 수도 있고, 논리 오류일 수도 있고, 문서의 오타일 수도 있고, 웹 사이트에서 혼란스러운 것일 수도 있습니다.

Hixie 에 2020년 07월 28일

👍2

아마도 우리는 후크로 수정될 그러한 문제가 있는 앱의 전체 예를 보여줄 수 있습니다. 후크로 다시 작성할 필요는 없지만 복사 붙여넣기가 얼마나 되는지 보여줍니다.

@satvikpendem 문제가 "내 응용 프로그램에 너무 많은 상용구를 가지고 있습니다"라면 그것은 분명히 당신이 신고해야 하는 버그이며 문제를 개선하는 방법에 대해 논의할 수 있습니다. 여기에 버그 #를 언급하면 버그에 대한 대화를 계속할 수 있습니다.

Hixie 에 2020년 07월 28일

👍1

@Hixie 댓글 감사합니다. 내 문제는 @rrousselGit 이 언급한 것과 동일한 버그(#51752)에 의해 광범위하게 다루어지므로 해당 문제에서 읽은 내용을 기반으로 더 추가할 필요가 없다고 생각합니다.

@timsneath @lukepighetti 에 대한 귀하의 의견을 이해했는지 잘 모르겠습니다. 이 문제, # 51752 및 기타와 같이 Flutter의 맥락에서 문제를 여러 번 설명한 것처럼 느껴집니다. 무엇을 더 포함해야 합니까? 이 문제 공간에 대해 더 많은 정보를 얻을 수 있도록 어떻게 도와드릴까요? React 팀이나 다른 사람들과 이야기를 하면 당신이 말했듯이 정보에 입각한 질문을 할 수 있는 충분한 지식을 갖게 될 것입니다.

예를 들어, React에 있다고 해서 다른 프레임워크에서 무언가를 복사해서는 안 된다는 데 동의합니다. 따라서 이 코드 중복 문제에 대한 다른 솔루션을 보는 것이 도움이 될 수 있습니다. Vue의 설립자 @yyx990803 은 Vue의 RFC(https://www.github.com/vuejs/rfcs/tree/function-apis/active-rfcs%2F0000-function-api.md)에 자신의 생각을 게시하여 도움이 될 것입니다. 지나가 다. 어떤 문제가 해결되었는지, 그리고 클래스 기반 API에 대해 정중하게 동의하지 않는 이유에 대한 섹션을 특별히 살펴보는 것이 유용합니다.

satvikpendem 에 2020년 07월 28일

@Hixie 를 명확히 해 주셔서 감사합니다. 나는 '버그'에 대한 더 넓은(내부적으로?) 정의를 오해했습니다.

@timsneath 팔로우하고 있는지 잘 모르겠습니다. 이미 일련의 문제를 식별 및 전달한 핵심 반응 개발자 그룹인 또 다른 그룹의 사람들은 구조적으로 유사한 프레임워크에서 솔루션을 만들었으며 여러 프레임워크에 걸쳐 많은 프런트 엔드 팀이 성공을 보고하고 있습니다. 이것이 "문제 이전의 솔루션" GitHub 문제라는 표시는 없습니다. @Hixie 는 해결해야 할 문제가 있다는 데 동의하지 않는 것으로 보이며, 이는 개발자 경험의 이점을 반영하지 않는 스타일 또는 유지 관리 선택을 기반으로 하는 것으로 보입니다. 이 RFC에 대한 거부감이 어디서 오는지 이해하려고 노력하면서 최대한의 존경심을 표합니다.

나는 일반적으로 앵무새 기능을 권장하지 않지만 후크에 대한 RFC는 정당한 근거가 있는 선행 기술이 없는 것은 아닙니다. 선행 기술은 핵심 반응 팀에서 사용할 수 있으며 우리가 제시하는 모든 정당성은 그들이 할 수 있고 전달한 것을 반복할 것입니다. @rrousselGit 은 GitHub 문제에서 우리가 할 수 있는 것보다 훨씬 더 많은 통찰력을 제공할 수 있기 때문에 이 주제에 대해 논의하기 위해 회의를 주선하는 것을 옹호하는 것 같습니다.

메타 문제로서 개인적으로 커뮤니티에서 제시한 flutter/flutter 로드맵에 광범위한 RFC를 통합하는 구체적인 프로세스가 있다면 도움이 될 것입니다. 힘들고 필요한 작업을 원하는 것은 외부 이해관계자라는 말이 있기 때문에 이들을 포함하고 진지하게 받아들여야 합니다. flutter/flutter 컨텍스트에서 외부는 비 팀, 비 Google, 비 GDE입니다.

lukepighetti 에 2020년 07월 28일

Wiki에 RFC 프로세스 를 문서화했습니다.

Flutter/flutter의 맥락에서 외부는 비 팀, 비 Google, 비 GDE입니다.

정의에 따르면 RFC를 제출하는 경우 팀의 구성원입니다.

내 문제는 @rrousselGit 이 언급한 것과 동일한 버그로 광범위하게 다루어집니다(#51752).

그런 경우에는 해당 토론에 참여하는 것이 좋습니다. 이 특정 문제는 닫혀 있지만 그 문제는 열려 있습니다. 그 문제에 대한 제안에 대한 몇 가지 설명이 있었지만 아무 것도 제대로 작동하지 않는 것 같습니다. "후크"에 대한 명확한 설명은 아직 없으며 그냥 지나칠 정도로만 언급되었습니다.

Hixie 에 2020년 07월 29일

👍1

나는 여전히 문제와 제안된 솔루션이 React와 Vue에 의해 매우 명확하게 문서화되어 있는데 왜 우리가 문제를 설명해야 하는지 이해하지 못합니다.

후크의 RFC 에는 많은 똑똑한 사람들의 약 1400개의 댓글, 소개 동영상, 문서 및 기사가 포함되어 있습니다.

우리는 이러한 문제에 대한 해결책에 동의하지 않을 수 있습니다. 하지만 문제를 설명할 필요가 없어야 합니다

rrousselGit 에 2020년 07월 29일

문제는 #51752에 설명되어 있지 않습니까? 그게 문제가 아닌가요?

Hixie 에 2020년 07월 29일

(이유: 개발팀이 다른 제품에 대해 1400개의 댓글이 달린 RFC를 지시하는 것은 해당 개발팀과 효과적인 의사 소통 방법이 아니기 때문입니다. 제가 둔감하게 느껴진다면 죄송합니다.)

Hixie 에 2020년 07월 29일

👍1

메가 스레드를 핑해서 죄송합니다. https://github.com/flutter/flutter/issues/51752#issuecomment -665380355에서 React 관점에서 몇 가지 생각을 더 남겼으며 기꺼이 답변해 드리겠습니다. 그것이 유용하다면 더 많은 질문.

나는 또한 이(및 관련 스레드)가 "React에서 작동합니다"와 같은 주장으로 유지 관리자에게 압력을 가하지 않고 정중하게 유지될 수 있다는 희망을 표현하고 싶었습니다. React와 Flutter는 프로그래밍 모델에서 상당한 차이가 있으며 React Hooks는 특히 우리의 약간의 뉘앙스에 상당히 의존합니다. 그들은 또한 결과적으로 많은 사람들이 받아들이지 않을 수 있는 몇 가지 단점을 가지고 있습니다.

gaearon 에 2020년 07월 29일

❤9

후크에 대한 생각이 바뀌었습니다. 나는 그것들이 환상적인 패턴이라고 생각하지만, 방금 React Native 계약을 마쳤고 후크가 (내 생각에) 개발 시스템을 끔찍하게 파편화하여 거의 이득을 보지 못했습니다. Flutter는 현재 React 클래스 구성 요소와 매우 유사한 패턴을 사용하고 있으며 이를 기반으로 구축된 수많은 도구가 있습니다. 프레임워크가 기본 상태 관리 솔루션으로 후크로 전환되는 경우 Flutter 개발자가 거의 이득을 위해 사용하지 않는 기존 작업과 정신적 패턴을 모두 파괴할 것입니다.

후크가 생산적인 개발을 위한 우수한 패턴이라는 주장이 있다고 생각하지만, 시간이 지남에 따라 일관성이 "더 나은" 것보다 낫다는 더 설득력 있는 주장(dartfmt 핵심 주장과 같은)이 있다고 생각합니다.

또한 새로운 React 개발자를 다룰 때 예기치 않은 결과를 생성하는 후크가 있는 장애물에 자주 부딪히며 먼저 클래스 구성 요소를 사용하도록 가르쳐야 합니다. (좋은 비교는 새로운 개발자가 map/reduce/filter/fold와 같은 수집 방법에 비해 for 루프를 사용하는 시간이 더 쉽다는 현상입니다). 후크는 고급 패턴이며 때때로 이를 당연하게 여깁니다. 여기서 실망스러운 점은 React 커뮤니티가 클래스 구성 요소 패턴에 대한 문서 및 지원을 신속하게 단계적으로 중단하여 새로운 개발자에게 이 교육 또는 옵션을 제공하는 것을 더 어렵게 만들고 있다는 것입니다.

lukepighetti 에 2020년 08월 04일

👍3

다른 문제 #51752에서 후크 자체에 단 한번의 렌더링을 위한 useEffect(() => ..., [] ) 패턴과 같은 몇 가지 단점이 있는 것처럼 보이기 때문에 더 Flutter 전용 버전을 만드는 작업을 해야 한다고 언급했습니다. @Hixie 는 후크와 유사한 작업을 수행하지만 이러한 단점이 없을 수 있는 Property 및 PropertyManager 패턴으로 흥미로운 버전을 만들었습니다. 적어도 Flutter의 경우에는 React 스타일 후크보다 더 잘 작동하지만 여전히 동일한 문제를 해결하는 무언가가 있는 것처럼 느끼기 때문에 후크에 대한 대안을 더 살펴봐야 합니다.

satvikpendem 에 2020년 08월 04일

👍3

이 페이지가 도움이 되었나요?

0 / 5 - 0 등급

Flutter: 위젯 후크

정의:

원칙:

사용 사례

단점

결론

보너스

가장 유용한 댓글

모든 100 댓글

관련 문제