openlang

getItem이 돌려주는 null과 ReScript external

ReScript 타입 검사기는 external이 어떤 JavaScript 함수가 무엇을 돌려주는지 알려 주는 그 줄까지만 엄격해요. 그다음부터는 그냥 믿어요. localStorage의 getItem을 string을 돌려준다고 바인딩하면 모든 호출자가 결과를 문자열로 다룰 수 있게 되는데, 실제 브라우저는 없는 키에 null을 돌려줘요. 런타임에 확인하는 코드는 하나도 안 들어가요. 비용 없는 바인딩의 핵심이 그거고, 타입 안전성이 조용히 끝나는 곳도 거기예요.

정직한 바인딩은 Nullable.t<string>을 돌려주고 값이 들어오는 입구에서 딱 한 번 option으로 바꿔요. 그러면 나머지 UI 코드는 Some과 None으로 매칭하고 빈 경우를 잊을 수가 없어요. TypeScript도 .d.ts 파일에 같은 약점이 있어요. 거기서는 그냥 더 익숙하게 느껴질 뿐이에요.

계속 왔다 갔다 하는 건 얼마나 감쌀지예요. 얇은 바인딩에 변환 함수 하나면 싸요. 라이브러리마다 손으로 쓴 모듈을 두면 더 안전하지만 라이브러리가 바뀔 때마다 낡아요.

이어지는 대화 1

서로의 근거를 따라
  1. 고유 링크

    들어오는 길에 변환하십시오. 그 뒤로는 아무것도 경고하지 않습니다. nullable 컨텍스트 없이 컴파일된 C# 라이브러리에서 온 string은 oblivious 상태라, 역참조해도 경고가 나오지 않기는 마찬가지입니다.

같은 질문의 다른 갈래

  1. 레이블은 바뀌었는데 화면에도 보였을까요?

    프로미스가 이행돼요. 리액션이 레이블을 Loading에서 Calculating으로 바꿔요. 긴 동기 계산이 돌아요. 레이블이 Done이 돼요. 사용자가 세 레이블을 순서대로 다 봤겠거니 하기 쉬운데, 저는 가운데 것이 화면에…