좀 더 구체적인 세부 정보를 위해 .ex vs .exs 파일을 사용해야 하는 경우에 대해 알아본 몇 가지 패턴 또는 경험 규칙이 있습니다.
거의 모든 코드가 lib(또는 이전 Phoenix 웹앱인 경우 웹)과 같이 응용 프로그램의 '라이브러리' 디렉터리 트리에 있는 .ex 파일에 들어갑니다. 코드는 응용 프로그램의 다른 위치 또는 iex에서 호출할 수 있습니다(공용 함수 또는 매크로를 정의하는 경우). 이 값이 기본값입니다.
.ex와 .ex 사이에서 결정할 때 가장 중요하게 고려해야 할 사항은 이 코드를 어디에서(그리고 언제) 호출할 것인가입니다.
애플리케이션 자체에서 확인할 수 있습니다.
iex(예: iex -S 혼합) – .ex, 코드가 응용 프로그램에서 사용되는 경우(예: 특정 버그 또는 기타 문제) .ex, 'ad-hoc' 스크립트의 경우(예: .ex
셸에서 믹스 – .ex를 통해 사용자 지정 믹스 작업의 경우 또는 mix.exs의 데이터로 사용할 수 있습니다(단순 작업 별칭의 경우).
셸에서, 즉 '일반 스크립트' - .ex로, elixir some-script.ex를 통해 실행됩니다.
놀라운 점은 [2], [3] 또는 [4] 중 하나로 시작하는 양호한 코드 비트가 결국 [1]에 도달한다는 것입니다.
또한 코드를 .exs 파일에서 .ex 파일로(또는 그 반대로) 쉽게 이동할 수 있습니다.
[2]의 경우, 특히 한 애플리케이션에 대해 iex와 함께 사용할 수 있도록 몇 가지 추가 '스크립트 모드' 혼합 환경을 설정했습니다. 기본적으로 애플리케이션(또는 기타 백엔드 서비스)의 기본 'dev' 로컬 인스턴스를 실행하지만 프로덕션/테이징 DB에 연결합니다. 이러한 '명령 환경'에 대한 도우미 기능/매크로가 있지만 대부분 애플리케이션 코드를 사용하여 프로덕션/준비 데이터베이스를 쿼리하고 일부 데이터를 수정/정리/검사합니다. 만약 제가 조금이라도 '관련된'(복합된) 작업을 해야 한다면, 저는 보통 애드혹 '이슈 스크립트'를 만들 것입니다. iex보다 편집기에서 코드를 작성하는 것이 훨씬 쉽습니다.