React: 경고: prop이 'null'인 경우 PropTypes.object.isRequired

null 는 값이 없는 것과 동일하며 객체가 아닙니다(비어 있거나 그렇지 않은 경우). null 에 대해 경고하지 않으려면 필수 항목으로 지정하지 않아도 동일한 효과가 있습니다. 키의 존재 여부를 테스트하는 것은 내가 권장하는 것이 아닙니다.

나는 동의한다. 사용자에게 값을 지정하도록 강제하고 싶지만 null을 유효한 값으로 기꺼이 받아들이는 사용 사례는 많지 않습니다. 실용적인 목적을 위해 null에 대한 isRequired 경고는 합리적이고 예상되는 동작입니다.

관련: https://github.com/facebook/react/issues/2166
(이 문제는 여전히 검색 결과에 두드러지게 나타납니다)

내가 보는 일반적인 사용 사례는 데이터에 대한 API 호출이 완료되기 전에 구성 요소를 렌더링하는 React입니다. 첫 번째 렌더링은 예를 들어 항목 목록( items: null )을 렌더링합니다. 그런 다음 API 호출이 완료되고 이제 items 가 배열로 채워집니다.

나는 PropTypes.oneOfType([null, PropTypes.object]).isRequired 시도하고 있으므로 null 또는 객체 중 하나가 현재 가능하지 않습니까?

CHANGELOG 에 따르면 15.4.0 이후로 가능하다고 가정합니다.

사실, 15.4.0에서는 반대입니다: Required PropTypes now fail with specific messages for null and undefined.

나는 또한이 문제에 직면 해 있습니다.
@Noitidart 의 해결 방법이 작동하지 않습니다. 다음과 같은 오류가 발생합니다.
Failed prop type: The prop 값 is marked as required in , but its value is null .

속성이 필요하지만 null 값도 허용하는 것이 정말 유용하다는 것을 알았습니다.

null 어떻게든 허용한 것에 대해 +1입니다.

구성이 JSON을 통해 로드되는 사용 사례가 있으며 다음과 같이 표시되어야 하는 문자열을 지정하는 여러 레이블 구성 옵션이 있습니다.

{
  "title": "my title"
}

따라서 제목을 표시하지 않아야 하는 경우 null 를 사용하여 해당 사례를 나타냅니다.

{
  "title": null
}

(이러한 설정이 수십 개 있으므로 병렬 hasTitle: false 를 추가하는 것은 금지됩니다.)

JSON 콘텐츠의 경우 null을 사용하는 것은 정의되지 않은 것( undefined )과 의도적으로 생략된 것( null )을 구별하는 매우 유용한 방법입니다.

null을 허용할 수 있습니다. propType은 필수가 아니므로 필요하지 않도록 설정하십시오.

@jquense 감사합니다 매우 도움이 됩니다! 이 SO 답변 이 같은 내용을 말했기 때문에 이전 의견을 삭제했습니다.

@jquense null AND undefined는 허용할 수 있지만 둘 중 하나는 허용하지 않습니다.

그것이 모든 문제입니다! Javascript는 이러한 2가지 다른 구성을 제공한 데는 이유가 있으므로 모든 사람이 PropTypes에 대해 null === undefined 를 처리하도록 하는 것은 인위적인 제한입니다.

PropType이 null을 명시적으로 허용하기를 원한다고 해서 undefined도 허용해야 한다는 의미는 아닙니다. 그들은 두 가지 별개의 경우이며 언어는 의도적으로 그렇게 설계했습니다.

여기에서 이 감독을 해결하기 위한 PR이 있습니다: https://github.com/facebook/prop-types/pull/90

undefined 를 허용하지 않는 이유는 오타가 있음을 의미하고 null 허용한다는 것은 호출자가 null 명시적으로 전달했음을 의미하기 때문입니다. 이것이 이 문제의 요점입니다. 흐름으로 전환하는 것이 권장되기 때문에 이 문제가 종료되었음을 이해합니다.

@binki null 하지만 undefined 는 허용하지 않는 한 가지 방법은 고유한 PropType 유효성 검사기 기능을 사용하는 것입니다.

아래 예에서는 null 또는 string 만 허용됩니다. PropTypes 라이브러리는 내부적으로 typeof 를 사용하여 문자열을 확인하므로 동일한 작업을 수행했습니다. 한 가지 이점은 이 함수를 구성 요소 외부로 이동하고 필요에 따라 호출할 수 있다는 것입니다.

static propTypes = {
  id: PropTypes.number.isRequired,
  email: function(props, propName, componentName) {
    const propValue = props[propName] // the actual value of `email` prop
    if (propValue === null) return
    if (typeof propValue === 'string') return
    return new Error(`${componentName} only accepts null or string`)
  }
}

나는 이 솔루션이 PropTypes 라이브러리의 의도에서 벗어난다고 생각합니다 - 내가 이것을 말하는 이유는 https://github.com/facebook/prop-types/blob/master/factoryWithTypeCheckers.js에 있는 PropTypes 라이브러리의 아래 코드 때문입니다.

실제로 유효성을 검사하기 전에 속성 값이 null 이면 isRequired로 설정된 속성이 자동으로 오류를 발생시키는 빠른 검사가 수행됩니다. 다른 말로 하면 그들은 필수 속성이 null인 것이 잘못된 것이라고 생각하지만 나는 필수 null이 있는 것이 유효한 사용 사례라고 생각합니다.

if (props[propName] == null) {
  if (isRequired) {
    if (props[propName] === null) {
      return new PropTypeError('The ' + location + ' `' + propFullName + '` is marked as required ' + ('in `' + componentName + '`, but its value is `null`.'));
    }
    return new PropTypeError('The ' + location + ' `' + propFullName + '` is marked as required in ' + ('`' + componentName + '`, but its value is `undefined`.'));
  }
  return null;
} else {
  return validate(props, propName, componentName, location, propFullName);
}

명시된 이유로 @jharris4 에 동의합니다. null 는 undefined 와 다릅니다. 자리 표시자로 사용하는 것이 표준입니다.

Mozilla 개발자 네트워크에서:

null 값은 개체 값이 의도적으로 없음을 나타냅니다.

null은 undefined와 같이 전역 개체의 속성에 대한 식별자가 아닙니다. 대신 null은 식별 부족을 나타내며 변수가 객체를 가리키지 않음을 나타냅니다. API에서 null은 종종 개체가 예상되지만 관련 개체가 없는 위치에서 검색됩니다.

null은 적어도 PropTypes.oneOfType([null, PropTypes.string]).isRequired 통해 허용되어야 합니다.

@jquense — isRequired 제거하면 기본값을 설정해야 합니다. 이것은 null 를 소품의 값으로 허용하는 것을 피하기 위해 감속기의 구성 요소 _및_의 초기 값에 대한 기본값을 설정한다는 것을 의미합니까?

API 호출을 기다리는 동안 선택기에 data || '' ( isRequired 빈 문자열 '' , 빈 개체 {} 등)이 많이 있습니다. finish null 는 구성 요소에 데이터가 올 것이라고 알려주는 완벽한 방법입니다. 잠시만 기다리세요! (하지만 난 그럴 수 없어...)
@puiu91 은 지금 좋은 해결 방법을 가지고 있습니다... 코드베이스에서 사용할 유틸리티 함수를 만들어야 합니다... 이 문제가 곧 다시 열리지 않을 것 같기 때문에 한숨

나는 또한 @jharris4 와 @Findiglay가 언급한 것과 같은 이유로 null 를 값으로 받아들이는 표준 방법이 있어야 한다는 데 동의하지만, 이것은 더 이상 논의를 계속할 장소가 아닙니다. 이 문제는 종료되었을 뿐만 아니라 facebook/prop-types 에 속합니다. 여기 facebook/prop-types#90에서 pull 요청을 따르고 있습니다.

충돌. 오늘날에도 여전히 실행 중입니다. 다음과 같은 기능을 기본적으로 지원하는 것이 좋습니다.

myObj: PropType.object.isRequiredOrNull :)

나는 이것에 대한 우선 순위가 매우 낮다고 생각합니다. 흐름은 권장되는 방법입니다. http://flow.org/

@Marujah 스니펫이 올바르지 않습니다.

구성 요소에 null을 전달하면 경고가 표시됩니다.

Warning: Failed prop type: The prop 'theProp' is marked as required in 'TheComponent', but its value is null.

문제는 isRequired가 먼저 평가되고 null 또는 정의되지 않은 값을 통과시키지 않는다는 것입니다.

관심이 있는 경우 문제를 해결하기 위한 prop-types에 대한 PR이 위에 링크되어 있습니다.

아 정말! 다시 한 번 당신이 옳다

값 또는 null이 구체적으로 제공되어야 한다는 요구는 PropTypes를 통해 절대적으로 허용되어야 합니다.

다음은 내가 겪고 있는 사용 사례입니다. 선택자의 90%가 필요로 하는 몇 가지 콜백이 있습니다. 그것들이 필요하지 않은 소수는 매우 구체적인 사용 사례입니다. 일반적인 콜백을 모두 제공하는 것을 지속적으로 잊어버리는 새로운 개발자가 있습니다.

이 구성 요소의 모든 사용이 특정 콜백을 포함하지 않도록 의식적인 결정을 내리도록 강제하고 싶습니다. 누군가가 몇 가지 소품을 잊어버리는 것이 아니라.

예, 흐름을 통해 보다 구체적인 검사를 해킹할 수 있지만 이는 props 유효성 검사를 두 곳으로 분할하고 propTypes 정의를 살펴보는 사람에게는 다소 직관적이지 않습니다.

여기에 내 사용 사례를 추가하고 싶었습니다. 데이터를 가져온 시간과 함께 데이터가 있는 redux 저장소가 있습니다. 오류가 있는 경우 등이 있습니다. 내 구성 요소에는 '오류' 소품이 필요합니다(따라서 데이터를 가져올 수 없는 경우 사용자에게 오류를 표시할 수 있음). 데이터가 성공적으로 로드되면 null이지만 오류가 있으면 채워집니다.

로더 구성 요소( PropTypes.node )를 props 전달하고 로더를 렌더링하지 않으려면 null 합니다.
Afaik, render 함수는 아무 것도 렌더링하지 않을 때 undefined 대신 null 를 반환해야 합니다. 따라서 null 를 값으로 전달하는 것이 올바른 방법으로 보입니다.

내가 InputNumber 구성 요소를 구현했다 (래퍼 <input type="number"> ), 내가 가진 그래서 propTypes 내 소품에 대한 value - PropTypes.number.isRequired , 그리고 내 구성 요소, I를 사용하는 경우 항상 속성을 전달했습니다. 하지만 오늘은 기본적으로 값에 대한 링크를 nullable로 전달해야 하며 구성 요소가 경고를 추가합니다. 내가 상상할 수 있는 유일한 결정은 propTypes 대한 value 를 PropTypes.oneOfType([PropTypes.number, PropTypes.string]) 하고 defaultProps 를 null로 설정하는 것입니다. 그러나 input type=number는 숫자로만 작동해야 하기 때문에 올바른 것이 아니라고 생각합니다.

나는 PropTypes.oneOfType([null, PropTypes.object]).isRequired 시도하고 있으므로 null 또는 객체 중 하나가 현재 가능하지 않습니까?

Warning: Invalid argument supplied to oneOfType. Expected an array of check functions, but received null at index 1. 함수가 필요합니다.

따라서 다음과 같은 기능을 제공해야 합니다.

PropTypes.oneOfType([
  () => null,
  PropTypes.object
]).isRequired

방금 이 버그가 발생하여 이를 해결하기 위해 편의 기능을 작성했습니다.

function nullable(subRequirement) {
  const check = (required, props, key, ...rest) => {
    if (props[key] === null) {
      return null;
    }
    const sub = required ? subRequirement.isRequired : subRequirement;
    return sub(props, key, ...rest);
  };
  const fn = check.bind(null, false);
  fn.isRequired = check.bind(null, true);
  return fn;
}

용법:

static propTypes = {
  someCallbackFunction: nullable(PropTypes.func).isRequired,
};

nullable 없이 isRequired nullable 를 사용하는 것이 가능합니다(그러나 오히려 무의미합니다). isRequired 와 호환되도록 만든 이유는 react/require-default-props eslint 규칙과 함께 작동하기 위함입니다.

내 사용 사례는 콜백을 처리하는 단일 구성 요소로 래핑된 공통 API를 준수하는 일련의 구성 요소입니다. null 콜백은 '읽기 전용'을 의미하므로 래퍼 구성 요소는 때때로 의도적으로 null 합니다. 동시에 새 속성이 추가될 때 누락되지 않도록 모든 속성을 하위 구성 요소에 전달하는 것이 중요합니다. 또한 이 API를 준수하는 모든 구성 요소에 대해 defaultProps null을 제공하고 싶지 않습니다. 그들이 알고 있는 한 호출자는 값을 지정해야 합니다.

나는 전에 작성한 도우미를 가져 와서 정확성을 증명하기 위해 많은 테스트와 함께 패키지에 넣었습니다.

npm install --save git+https://github.com/davidje13/prop-types-nullable.git#semver:^1.0.0

용법:

import PropTypes from 'prop-types';
import nullable from 'prop-types-nullable';

[...]

static propTypes = {
  thing: nullable(PropTypes.string).isRequired,
};

새로운 솔루션: PropTypes.oneOfType([PropTypes.object]).isRequired

오류가 발생합니다.
어떻게 고치는 지.

./~/prop-types/prop-types.js의 경고 중요한 종속성: 1:482-489 이것은 미리 빌드된 자바스크립트 파일인 것 같습니다. 가능하지만 권장되지는 않습니다. 더 나은 결과를 얻으려면 원본 소스를 요구하십시오. @ ./~/prop-types/prop-types.js 1:482-489

나는 PropTypes.oneOfType([null, PropTypes.object]).isRequired 시도하고 있으므로 null 또는 객체 중 하나가 현재 가능하지 않습니까?

Warning: Invalid argument supplied to oneOfType. Expected an array of check functions, but received null at index 1. 함수가 필요합니다.

따라서 다음과 같은 기능을 제공해야 합니다.

PropTypes.oneOfType([
  () => null,
  PropTypes.object
]).isRequired

사실 마지막에 'isRequired'라는 오류 때문에 오류가 발생했는데, null인 동시에 필수는 호환되지 않습니다...
이것이 나를 위해 일한 것입니다.

PropTypes.oneOfType([ 
    PropTypes.string.isRequired, 
    () => null 
])

@ gugol2 그냥 비활성화 타입이 완전히 확인합니다 작성한 것을주의하십시오 (당신이 지금 소품에 번호를 통과, 또는 수 undefined , 또는 아무것도); 귀하가 제공하는 기능은 반환해야합니다 null 검증이 성공하고있는 경우 비 null 실패합니다.

해당 경로로 이동하려면 다음과 같은 것이 더 필요합니다.

PropTypes.oneOfType([
  PropTypes.string.isRequired,
  (props, key) => props[key] === null ? null : 'Not null'
])

물론 보기 흉한 도우미 함수를 미리 정의할 수 있습니다.

const nullable = (props, key) => props[key] === null ? null : 'Not null'

// ...

PropTypes.oneOfType([PropTypes.string.isRequired, nullable])

PropTypes.oneOfType([PropTypes.string.isRequired]) 사용하는 것도 기이하게도 가능합니다(하지만 정말 추천하지 않습니다!). 이것은 버그처럼 느껴지며 그런 코드가 이후 버전에서 살아남을 것이라고 기대하지 않습니다. 또한 작동하지 않는 이전에 제안된 방법 과 유사하지만 동일하지는 않습니다.

기다릴 수 있다면 믿을 수 없을 정도로 느리게 움직이지만 분명히 여전히 고려 중인 공개 PR 이 있습니다.

그리고 PR이 병합될 때까지 내가 만든 패키지 (또는 그 뒤에 있는 .isRequired 를 추가하여 Linting 규칙과 호환되기 때문입니다.

IMHO 이것은 올바른 동작이지만 문서화해야 합니다.

내가 보는 일반적인 사용 사례는 데이터에 대한 API 호출이 완료되기 전에 구성 요소를 렌더링하는 React입니다. 첫 번째 렌더링은 예를 들어 항목 목록( items: null )을 렌더링합니다. 그런 다음 API 호출이 완료되고 이제 items 가 배열로 채워집니다.

이것을 처리하는 가장 좋은 방법은 무엇입니까? 이 소품이 필요하지만 API에서 다시 가져오기 전에 null입니다.

PropTypes.oneOfType([
  PropTypes.string.isRequired,
  (props, key) => props[key] === null ? null : 'Not null'
])

@ davidje13 이 접근 방식에 약간의 문제가 있습니다. 적용 범위 테스트에는 적용되지 않는 1/4 케이스가 있습니다.

null 또는 문자열이 필요할 수 있는 하나의 prop 'name'만 있는 로그인 구성 요소가 있다고 가정해 보겠습니다.

const Login = ({name}) => {
  return <div>{name}</div>
} 

따라서 그 proptypes는 다음과 같습니다.

Login.propTypes = {
  name: PropTypes.oneOfType([
    PropTypes.string.isRequired,
    (props, key) => (props[key] === null ? null : 'Not null'),
  ]),
};

이 구성 요소를 테스트할 때 null 또는 필수 문자열의 2가지 시나리오만 있습니다.

render(<Login name={null} />
render(<Login name={'anyName'} />

그러나 적용 범위에 따르면 내 테스트에는 75%만 적용됩니다.
이에 대한 공식적인 접근은 어떻게 되는지 궁금합니다.

누락된 테스트 케이스가 소품 검사에 실패한 것 같습니까? 즉, 숫자나 정의되지 않은 것을 전달하면 안 되는 것입니다.

누락된 테스트 케이스가 소품 검사에 실패한 것 같습니까? 즉, 숫자나 정의되지 않은 것을 전달하면 안 되는 것입니다.

아니, 그게 아니야.

undefined를 전달해도 적용 범위가 확장되지 않습니다.
그리고 어쨌든 숫자를 전달할 수 없습니다. 허용되는 값이 아닙니다.

나는 그 사건을 덮을 수 없다.