vue composition api에서 props의 재활약성을 아실 거예요.

16398 단어 Vue.jstech

이 기사에 전하고 싶은 이야기.

  • vuecompositionapi의 구성 요소setup에서 받아들일 수 있음propsreactive에서 정의한 변수와 같은 주동성
  • props의 속성에 대해 활성화된 모델과 그렇지 않은 모델의 구분 사용
  • !
    이처럼 애매모호한 표현 방식은 행동이 비슷하기 때문이지만, 같은 것이라고 판단할 수는 없다.

    재활성 API ref, reactive, computed


    composition api에서 재활동을 가져오는 API로는 ref,reactive,computed 등이 있는데 특히 refreactive 어느 것을 사용해야 하는지에 대한 인상이 많다.
    각자의 비교로 다른 개발자들의 글이어서 참고 가치가 있다고 생각합니다.
    https://zenn.dev/azukiazusa/articles/ref-vs-article
    제가 직접 돌이켜보면 자주 사용합니다refcomputed.ref Type Script를 사용하면 재활성 변수인지 쉽게 판단할 수 있습니다.computed는 다른 유원 변수에 의존하는 유원 변수를 간단하게 나타낼 수 있고 사용하기 쉽다. ref처럼 다른 논리에서 바뀌지 않기 때문이다.
    const isOpen = ref(true);
    const message = computed(() => isOpen.value ? '開いてるよ!' : '閉まっているよ!');
    // messageに入る値は上記の2パターンのみであり更新はされない。下記を実行すると `Write operation failed: computed value is readonly` というワーニングが表示される
    message.value = '全然関係ないメッセージ';
    
    는 UI 논리 등을 나타낼 때refcomputed는 기본적으로 충분하지만 store 등을 사용할 때reactive를 사용한다.
    그러나 reactive 중 하나는 자동으로 사라지는 것이다.

    간단히 말하면, reactive의 재활동은 사라진다


    재활성에 대한 사라짐은 유연한 상태의 분할 대입에서 보듯이 분할 대입을 통해 재활성을 제거한다.
    분할 대입의 예로도 다음과 같은 모델이 있다.
    const state = reactive({ name: 'karino' });
    
    // 1. リンクにある通りの分割代入を行うパターン
    const { name } = state;
    
    // 2. プロパティを直接参照して代入するパターン
    const name = state.name;
    
    // 3. プロパティを直接参照して他の処理に渡すパターン
    const { length } = useLength(state.name);
    // useLengthの戻り値のlengthはリアクティブな変数のはずですが、state.nameが更新されてもその値が変わることはないです
    
    // 一種のcomposable
    const useLength = (name: string) => {
      const length = computed(() => name.length);
      return { length };
    };
    
    이런 것들은 분할 대입으로 인해 주동을 잃었다고 할 수 있지만 다시 말하면'reactive가 정의한 변수 자체는 주동적이지만 그 속성은 주동적이지 않다'는 표현을 사용할 수 있다.
    실험 1: 모든 종류의 속성은 자동으로 사라집니다
    https://stackblitz.com/edit/vue-eysy8a?embed=1&file=src/App.vue&hideDevTools=1&hideExplorer=1&hideNavigation=1
    실험2: 속성이ref라도 분기대입, 회복작용 사라짐
    https://stackblitz.com/edit/vue-kjypvk?embed=1&file=src/App.vue&hideDevTools=1&hideExplorer=1&hideNavigation=1

    주제1:props는 무엇에 해당하는가


    구성 요소setup에 전달되는 첫 번째 매개 변수props의 변수도 활동 변수이다.
    그리고 reactive에서 생성된 변수 속성은 다시 활성화된 모드가 사라졌습니다.
    마찬가지로 props도 같은 조작으로 이 속성의 재활동을 삭제한다.
    예:props가 분할 대입으로 주동을 잃었다
    https://stackblitz.com/edit/vue-cnb8my?embed=1&file=src/App.vue&hideDevTools=1&hideExplorer=1&hideNavigation=1
    상기 실험1에서 링크 목적지reactive에서 제작된 변수의 분할 대입 변수는 다시 활성화되지 않았고, 마찬가지로 props의 속성도 분할 대입으로 인해 다시 활성화되지 않았다.
    이로써 propsreactive에서 정의한 변수와 같은 재활동성을 가진다.

    테마 2:props 속성에 대한 재활성화 요구 모드와 요구하지 않는 모드의 구분


    나는 props 속성이 활성화되지 않은 모드를 보았다.
    그렇다면props 재활용된 상태에서 논리를 쓰려고 할 때와 그렇지 않을 때 각각 어떻게 구분해서 사용해야 하는지, 다음은 서로 다른 문법에 따라 정리해 본다.

    props 속성을 다시 활성화해야 하는 모드


    props를 직접 사용하면 활성화 상태를 유지하십시오


    지금까지props의 속성은 재활동을 잃는 모델을 보았지만, 모두 분할대입의 집행정시setup의 바로 아래였다.
    분할 대입의 실행 시간을 변경하면 당시 속성의 값을 얻을 수 있습니다.
    아래의 예에서 단추를 눌렀을 때 id 값을 사용해서 someAPI 라고 부른다.
    <template>
      <button @click="callAPI">call api</button>
    </template>
    
    <script>
    export default {
      props: { id: { type: Number } },
      setup(props) {
        const callAPI = () => {
          someAPI(props.id);
        };
    
        return { callAPI };
      },
    };
    </script>
    

    props + toRefs , toRef


    https://v3.ja.vuejs.org/api/refs-api.html#toref toRefs, toRef는 모두 reactive 변수props에 사용할 수 있다.
    예:props에서 사용toRef하여 아버지, 아들로부터 각각 업데이트된 실험을 진행하다
    https://stackblitz.com/edit/vue-rcqnny?embed=1&file=src/App.vue&hideNavigation=1
    부모는 아이의 변경 사항을 전달하지만 자식으로 얻은 활성화 변수Set operation on key "〇〇" failed: target is readonly.를 업데이트하려면 오류가 발생하고 업데이트되지 않는다.
    이는 props의 아이 측이 변경을 불허하는 뷔의 지침이다.
    이 방법의 장점은props 속성을 독립된 재활동 변수로 성명할 수 있다는 데 있다.
    이렇게 하면 composable의 방법에만 속성을 제공하고 논리를 분할할 수 있다.
    그러나 TypeScript를 사용할 때toRefs, toRef 에서 얻은 변수는 Ref형으로 〇〇.value = △△ 유형 오류가 발생하지 않는다.
    만약 이런 코드가 있다면 실행 시 문제가 발생할 수 있습니다. 오류 로그가 아니라 경보 로그이기 때문에 발견과 수정이 지연될 수 있습니다.좀 무서운데.
    향후 뷰 자체 업데이트가 대응할 수 있을지, 라이트 설정 등을 통해 처리될지는 모르겠지만 어쨌든 주의해야 한다.

    props + computed

    computed도 속성props을 활동 변수로 독립시킬 수 있다.
    저는 개인적으로 사용toRef보다 toRefs이 더 좋다고 생각합니다.
    추천
    export default {
      props: { name: { type: String } },
      setup(props) {
        // プロパティに連動した別のリアクティブな変数を作るのに便利
        const nameLength = computed(() => props.name.length);
        // プロパティとまったく同じ意味合いのリアクティブな変数を作ることも可能
        const name = computed(() => props.name);
      },
    };
    
    computed의 이유는 두 가지다.
    첫 번째는 Type Script의 ComputedRef형입니다.ComputedRef형이 ReadOnly형〇〇.value = △△일 때 유형 오류가 발생합니다.실행하기 전에 완비되지 않은 것을 주의할 것이다.
    두 번째는 기억 API의 수를 줄일 수 있다는 것이다.computed 편리한 특성이 있어 API를 적극적으로 사용하고 기억하고 싶어요toReftoRefs,toRefs의 사용 빈도가 상대적으로 높지 않습니다.toRef 여러 속성을 한꺼번에 꺼낼 수 있지만 적어도 computedprops도 되지 않을까요?

    const 〇〇 = props.〇〇 속성에서 다시 활성화할 필요가 없는 모드


    setup

    props의 바로 아래에 이 맞춤법을 사용합니다. 즉, 구성 요소가 설치된 후에 업데이트되지 않는 값입니다.

    ref + ref


    const input = ref(props.initialValue);
    const onUpdate = (inputValue: string) => input.value = inputValue;
    
    상기 예에서 보듯이 props에서 ref 속성을 사용할 때 props 속성을 이 변수의 초기값으로 사용하는 것을 의미한다.props의 속성과 연동ref의 변수는 변하지 않는다.props의 속성에 대응하는 변수는 부모의 구성 요소에 업데이트되고 서브 구성 요소ref도 업데이트되지 않으며 반대로 서브ref가 업데이트되더라도 부모의 값은 변하지 않는다.
    https://stackblitz.com/edit/vue-qyqwmo?embed=1&file=src/Child.vue&hideDevTools=1&hideExplorer=1&hideNavigation=1

    최후


    왜 이제야 이런 당연한 기사를 썼을까? 사실 나는 잘 모르겠다props 더 이상 적극적으로 사용하지 않는 조건에서 사용했다.
    하지만 곰곰이 생각해 보니 자신의 동작이 reactive과 똑같아 둔함을 통감했다.
    그다지 좋지 않은 논리를 양산한 것 같다.부끄럽다~
    이상

    좋은 웹페이지 즐겨찾기