공감합니다~ 모던한 자바스크립트의 경우 var와 마찬가지로 function은 거의 사용할 필요가 없는 키워드이기는 합니다. 최신 함수형 프로그래밍의 경우는 this를 사용할 필요가 없는데다가 권장하지도 않죠. function만이 가지고 있는 this, name, arguments등의 활용법이 있기는 하지만 정말로 특수한 경우이고 메소드의 경우에는 prototype을 확장하기 위한 특수한 경우가 아니라면 class나 Object기반으로 생성을 하는 것이 더 나은 코드를 만들어 준다고 샹각합니다 말씀하시고자 하는 것 처럼 현대자바스크립트는 const와 arraw function을 베이스로 하고 나머지를 특수한 케이스로 상정하고 개발을 하는 것이 더 나은 방식이라고 생각합니다 좋은 영상 감사합니다 :)
좋은 의견입니다. 주장의 내용과 이유가 분명하고, 설명이 구체적이면서도 설득력이 있군요. 전 오래된 개발자고, 자바스크립트를 많이 쓰지만 메인 툴이 아니라 이런 디테일까지 신경쓰지 않고 있었는데, 잘 설명해 주셔서 감사합니다. 팀원들을 이런 방식으로 설득하고 룰을 만들어야 겠어요.
결론만 말하면, 당신이 var를 안 쓰는 사람이라면 같은 이유로 function도 쓰지 않기를 고려해보라는 거군요! JS 배운지 얼마 안 됐는데, 일반적으로 var는 그냥 쓰지 말라고들 하는 반면에 arrow function은 항상 alternative로 제시되는 것만 봐 와서 이런 차이가 있는 줄 몰랐습니다 😂 좋은 영상 감사드려요!
모든 function을 100% arrow function으로 대체할 수는 없는건데 제목은 그런 의미로 적으셔서 사실이 아닌걸로 과장을 하신것이니 안 좋게 보시는 분들이 계신듯. 아예->웬만하면으로 쓰셨으면 사실에 기반한 과장이니 아무런 문제가 없었을 것 같아요. 별개로 영상은 너무 유익하게 잘 봤습니다
객체의 축약형은 const a=0;b=0; result={a:a, b:b} 대신 key, value 가 같은면 전달된 인자 만 사용 result={a,b} 객체에서의 일반함수는 key,value 형태의 함수표현식 method: function() {} "생성자함수로 사용가능, this 바인딩이 동적으로 됩니다," method: () => {} "Arrow Function 는 자기 this 는 없지만 사용 할 경우 한 단계(block scope) 위의 this 정적 바인딩 됩니다 ES6 에 추가된 객체의 메서드 method() {} "생성자함수 사용불가"
2줄 요약 1. jsx 만들 때 export default를 함께 못써서 아쉽지 않은가요? 2. git diff로 볼 때 중첩 함수내에 function은 아래쪽에 몰아 넣어두는게 유용하지 않나요? ## 1. jsx 만들 때 export default를 함께 못써서 아쉽지 않은가요? jsx 요소를 반환하는 함수를 작성할 때, 그러니까 리엑트에서 컴포넌트를 작성할 때 파일 하나당 하나의 컴포넌트를 담을 때 번거로운 점이 있습니다. `function`으로 작성하면 export default를 붙일 수 있는데 화살표 함수로 하면 그렇지 못해서 export문을 찾아야 합니다. compound나 HOC를 많이 사용할때는 export 를 따로 빼 줄 필요를 느끼는데, 그렇지 않을 때는 화살표 함수에 `default`를 적지 못해 아쉽습니다. ```js export default function Component () => { return } ``` ```js const Component = () => { return } export default Component ``` ## 2. git diff로 볼 때 중첩 함수내에 function은 아래쪽에 몰아 넣어두는게 유용하지 않나요? 함수 내부에 중첩 함수를 만들 때 function을 사용하면 호이스팅의 도움(?) 으로 함수 아래쪽에 중첩 함수를 몰아 넣을 수 있는데요. (리팩터링 예제들 같이) git diff를 볼 때 가독성에 좀 도움이 되는 것 같습니다. 읽어주셔서 감사합니다.
이 내용은 다른분들 의견도 듣고 싶네요! 댓글이 많이 달리면 좋겠다는 바람을 하며 제 의견 적어보겠습니다 ㅎㅎ 1. 맞아요, 좋은 지적이십니다. 이부분 때문에 호불호가 나뉘는 것 같더라구요. 그래서 저는 export default는 코드의 맨 마지막 줄에서 한다는 규칙을 정해두었습니다. 한 변수명을 두 번 적어야 하는 불편이 있긴 한데, 그 대신 export default를 중복 선언하는 경우는 확실히 막을 수 있더라구요. (물론 중복선언한 경우 ide에서부터 오류를 잡아주긴 하지만요 ㅎㅎ) 나아가 어떤 사람들은 export function() {} 같은 형태가 여러개인 코드는 어떤걸 export 했는지 확인하기 어려워서 마찬가지로 맨 마지막에 한꺼번에 export { a, b, c ... } 식으로 몰아서 하기도 하던데, 이 방법도 꽤 좋다고 생각합니다. (commonjs 시절엔 이렇게밖에 할 수 없었죠) 이런 규칙들을 정해두면, 작업할 때는 쪼끔 번거롭지만, 나중에 코드를 볼 때는 export 내용을 확인하기가 꽤 용이합니다. 나아가 중간중간 export const였다가 그냥 const였다가 들쭉날쭉하지 않아 코드 가독성도 쫌 좋아지는 효과도...ㅎ 아무튼 export default를 바로 하지 못하는건 저도 아쉽긴 하고, 그래서 function을 계속 쓰는 분들이 많다는 것도 이해는 합니다. 성능상의 불이익이나 모호함 등을 감수하더라도 약간의 편리함을 유지하는 편이 나은가, 혹은 약간의 불편을 감내하는 편이 나은가? 하는 가치판단의 영역이라 정답은 없겠죠. 추가로, 사실 '못'하는건 아니에요. export default () => { ... } 식으로 익명함수로는 가능합니다. (애초에 화살표함수는 익명함수죠. 변수에 할당할 때 name 프로퍼티의 값을 자동으로 지정해줘서 익명이 아닌것처럼 보일 뿐) 2. git diff시 가독성에 도움이 된다는건 이해가 잘 되지 않는데요. 내부함수 수정시 코드 라인이 늘거나 줄어서 그렇다는 말씀이신가요? 그렇더라도 diff가 엉뚱하게 되는건 아닌듯 한데... 함수들을 아래쪽에 몰아둘 경우, 말씀하신 가독성 측면은 제가 잘 모르겠고, 문제가 발생할 소지가 있다는 건 확실해요. 예컨대 아직 초기화되지 않은 변수에 접근하게 되는 경우가 얼마든지 발생할 수 있습니다. 이런건 휴먼에러라서 런타임 이전엔 알아내기가 어렵죠. function outer() { let a = 1; inner(); const b = 2; inner(); function inner() { console.log(a, b); } } 그렇다고 '변수선언은 함수 최상단에서만 하자!'는 규칙을 정하면, TDZ 개념을 도입한 취지가 무색해지게 옛날 방식의 코드가 되어버리고, const로 해결될 걸 let으로 선언해야 하는 경우도 발생할 수 있어서 좋은 규칙이 아닌 것 같습니다. (그래서 전부 var로 퉁치자! 라는 규칙을 정하는 곳도 봤지만...뭐 다 회사가 팀이 정하기 나름인거죠)
1번은 윤석님과 재남님의 대화로 잘 설명이 되어서 2번 의견만 덧붙이자면, git diff시 가독성 자체에는 크게 문제를 못 느꼈어요. 도리어 코드 전체를 봤을때 "이 함수는 어디에 선언이 되어있는거지?" 라는 혼란은 느낄 수 있다는 생각이 듭니다! (호이스팅 자체가 개발자가 코드를 파악하는데 긍정적으로 작용하는 동작은 아니라고 생각해요) 개인적으로는 중첩함수의 형태도 그렇게 좋은 패턴은 아니라고 생각하지만, 이 부분은 호불호의 영역인 것 같아요. 다만 휴먼 에러를 방지하자고 변수 선언을 모두 var로 퉁치자는 의견은... 납득하기 조금 어렵습니다 ㅠㅠ😥
개인적으로는, 단순하게 함수로 사용할 때는 function이 훨씬 직관적으로 보입니다. 클래스를 표현하거나, 클래스나 오브젝트 내부의 메서드는 말씀하신 것 처럼 function을 쓰지 않았을때도 가독성을 해치지 않지만, 함수와 변수를 잘 구분해주기에는 function 키워드 만큼 한눈에 파악하기 쉬운게 없지 않나 싶습니다. arrow function같은 경우는 변수들과 섞여서 있을 때 함수라는 것을 한 눈에 보지 못하는 경우가 많고, bind할 필요가 없는데 arrow function을 반드시 써야한다고 생각하지도 않습니다. 실제 최신 라이브러리(프레임워크)라고 할 수 있는 React나 Vue 역시 function 키워드를 내부 코드에서 활용하고 있습니다. 어떻게 생각하시는지 궁금합니다.
- 가독성은 IDE에서 함수와 변수의 색상을 달리 표현해주기 때문에 function이라는 키워드가 없더라도 한눈에 파악하는 데에 불편을 전혀 느끼지 못하고 있어요. - 최신 라이브러리들도 function을 쓰고 있다는 사실이 제가 주장하는 포인트들과 어떤 관련이 있나요? 그런 것을 가치판단의 근거로 삼는 것이 오히려 적절치 않을 것 같습니다. - 성능상의 이점을 누리고 휴먼에러 가능성을 배제하기 위해 function 사용을 자제할 것인가, 아니면 그럼에도 불구하고 말씀하신 가독성이나 기타 다른 이유로 사용을 고수할 것인가인데, 그 결정은 회사가, 팀이, 개인이 각자 정하면 될 일이죠. 옳다 그르다의 문제가 아니니까요 :)
@@FERoy 두번째 최신 라이브러리들에 대한 부분은 가치판단의 기준으로 삼는다기보다는 무조건 써서는 안된다는 내용에 위와같이 최신라이브러리 들에서도 활용하고 있는 만큼 가독성이나 기타 이유에서 쓰이고 있다는 점에 힘을 실고 싶었구요. function을 쓰고 쓰지 않았을때에 대해서 성능상의 이점은 사실 거의 없다고 보입니다. 직접 테스트 해보신 벤치마크가 있을까요? 저도 직접 해보진 않았지만 레퍼런스를 검색해봤을때는 오히려 function키워드가 arrow function보다 빠른 벤치마크가 있네요. (dev.to/georgecoldham/using-arrow-functions-might-be-costing-you-performance-4fm6) 사실 이런 성능차이는 실제 서비스 운영에는 거의 영향을 주지않는 무시할만한 수준이라고 보구요. 이런경우에는 함수와 변수를 구분해줄때의 이점이 분명히 있다고 생각합니다. 대부분의 프로그래밍 언어들에서 변수와 함수 선언을 구분해주는 이유가 있다고 생각합니다. 저도 회사,팀,개인이 트레이드 오프를 따져서 결정해야 한다는 말에 동의합니다. 답변 감사합니다 :)
성능상의 이점이라는게 속도측면을 말하려던건 아니고 메모리를 덜 차지한다는걸 얘기하러던 거였어요(prototype, this정보를 담지 않아 가볍다) 말씀대로 실제 속도상에 차이가 있더라도 그 차이는 미미하여 무시해도 될 수준일거 같아요! 그리고 제목에 '아예' 라고 적었지만 영상 전반의 취지는 '무조건' 쓰지 말라는건 아니었습니다. 그저 앞으론 이런걸 써보는게 좋겠다-는 제안의 목적이 강했는데, 제목 잘못 지어서 본의아니게 어그로가 많이 끌린것 같네요 ㅠ
개발을 하다보면 적지 않은 경우에 function을 써야할 때가 반드시 있습니다. Arrow function이 도입되기전에 설계된 라이브러리에 콜백 함수를 넘길 때 그 안에서 this를 써서 해당 라이브러리의 객체를 가져올 수 밖에 없는 경우가 있기 때문입니다. 무조건 이라는 말은 언제나 위험합니다.
조회수를 위해 영상 제목을 자극적으로 적는게 상당히 이질적이기는 합니다.. 댓글을 많이 봤는데 영상 주인분도 댓글들에 상당히 공격적인 성향도 있으시네요. 새로운 기능이나오고 공부하는건 상당히 좋은 활동이기는 한데.. 글쎄요 제목에서 일단 쓰지말라고 하는게... 자바스크립트를 아는사람이 보기에는 새로운 자극이 되겠지만 이제 배우는 사람 입장에서보면 상당한 혼동을 줄수가 있으니까요. 실직적으로 실무에서 사용성을 봤을때 버전업된 언어는 지양해야 하는게 대부분이죠. 리스크적인 부분도 있고, 내가 그 코드를 짜고 그코드가 사향할때까지 내가 유지보수를 평생 하지는 않을테니간 말이죠.. 0.1%의 천재개발자도 필요하지만 유지보수를 위해 99%의 개발자들이 쉽게 이해할수있는 코딩도 중요하니까요.
@@Whiteblueter 제 마지막글을 캐치해서 답글 달아주신거같은데 서로간의 이해점이 달랐던거 같습니다. 무슨 말씀이신 알겠는데 제가 말한 유지보수개념은 이미 범용적으로 사용하고 있는 함수를 무작정 쓰지못한 몹쓸것이라는 뉘앙스가 크게 다가와 적어드린겁니다. 지금까지 필요에 의해 사용해 왔고 이제 새로운 문법이 생겨서 차츰 개선을 하자는 의견을 제시한다면 상당히 긍정적으로 다가오겠지만 대안점이 없는 시점에 사용한 함수를 개선된 문법이생겼다고 깔아내리는 느낌이 제생각에는 '비행기가 생겼는데 차는 왜타고댕겨? 차는 아예 생산하지도마' 같은 느낌으로 다가와서 남겨드린 글입니다. 추가로 파이선이 한때 유행처럼 번질때 자바언어는 죽어갈거라는 말이 나온시점도 있었고, 타입스크립트가 나왔을때도 자바스크립트는 죽어갈것이라는 말이 나온적이 있습니다. 하지만 실 사용하다보니 문제점들도 발견되었고 결국 자바가 아직 우세에있고 타입스크립트가 신세계라는 말도 점점 줄어들게 된것이고요. 저또한 펑션이 만능이라는 말이아니고 영상주인분의 설명해주시는 문법이 차후에는 일반화되는 기초적인 문법이 될수도 있다는걸 압니다만, 항상 새로운 문법이 무조건 옳다는 맹목적인 맹신은 하지 말아야 한다고 생각해서 적어드린 글이었습니다.
바벨, 타입스크립트가 대중화된 요즘엔 class 대신 생성자함수쓰는걸 거의 볼수 없음. 또 함수내에서 this 쓰는것도 이제는 거의 못봄. 위 두가지가 제외되면 function이 목적을 더 명확히 보여줌. const로 화살표함수만쓰면 변수랑 헷갈릴때가있음. fp식으로 코드짜면 함수자체가 짧은경우가많아서 더 그럼. 또한 호이스팅안되는거도 불편함. 고로 저는 function을 선호합니다.
저는 중첩 함수 선언할 때 개인적으로 function으로 마지막에 몰아서 선언하는 게 가독성에는 더 좋아보이더라고요. const arrow function 방식으로 선언하고 사용하면 함수 사용하기 직전에 선언하고 사용하거나 초반에 다 선언하고 사용하거나 해야되는데 개인적으로는 함수 초반에 중첩 함수 정의를 하는 게 좋아보이지 않아서 실제 로직부터 보여주는 식으로 하고 있습니다. 물론 이걸 외부로 빼는 방식도 있지만 그러면 또 응집도가 낮아지는 문제가 있고 그렇다고 객체로 만드는 것도 너무 과해보이고요.
@@FERoy 그건 arrow function도 상황에 따라서 똑같지 않나요? 어차피 function의 경우도 호이스팅으로 인해 콘텍스트 초반에 선언되는 거라 arrow function을 초반에 선언하게 된다면 별 차이는 없을 것 같습니다. 실질적으로요. 문제는 함수에서 참조하는 외부 변수가 선언 되기 전에 함수를 호출했는지가 문제니까요. 이걸 해결하려면 함수는 항상 그 변수 선언 이후에 선언되어야 한다는 코딩 스타일이 강제되더라고요.
비즈니스로짇이 들어가서 일반적으로 3만줄 이상 들어가는 페이지의 경우 튜닝시 가장먼저 하는 것이 에로우 메소드를 걷어내는 것 입니다 제목이 자극적인데 실제 학습용이나 간단한 짧은 그크립트의 경우, 또는 한 페이지에 많은 스크립트가 아닌 메뉴를 나누거나 하여 모듈화 시킬 경우 동영상과 같이 의도를 명확히 하여 코딩하는것이 좋으나 페이지당 비즈니스로직이 복잡하여 브라우저메모리를 신경써야 하는경우 에로우 메소드를 쓸 경우와 그냥 펑션만 쓸경우 얼추 20배 정도의 속도를 채감할 구 있습니다
'일반적'이라고 하셨는데, 차던브라님이 속한 세계와 제가 속한 세계가 다를 수 있겠다는 생각이 드네요. 모던브라우저(v8엔진 등)에서 애로우함수와 기존함수의 성능비교를 해보신 적이 있나요? 최적화가 많이 이루어져서 지금은 기존 function과 arrow 함수 사이에 유의미한 성능 차이는 없습니다. 혹시 babel을 돌려서 사용하시는 것은 아닌지요?
와 function 처음 배울 때 함수하나로 여러 방법들로 사용해서 이해하기 어려웠습니다. 당연히 예외처리 또한 이해하기 어려웠구요. 그러다 디스바인딩 이슈를 보고 신문법 arrow를 사용하고 클래스를 사용했는데, 딱히 확실한 이해를 하지 못한채 사용해서 찝찝한 감이 없지않아 있었습니다. 우연히 피드에 떠서 보게되었는데..정말 유용한 내용들이네요! 바로 구독했습니다!
재남님 안녕하세요 자바스크립트딥다이브 책을 1회독 하고 아 좀 어려운데 코어자바스크립트 얇고 좋다니까 같이 보면 2회독할 때 이해되지 않을까?? 하고 의기양양하게 책 사서 읽어봤는데 .. 내용은 좋다는게 느껴졌는데 아직 제 실력이 부족해서인가 레퍼런스 부분도 온전히 이해 안가고 변수 다음으로 넘어가기가 너무 부담스럽더라구요 제가 다니는 회사는 작은 플랫폼 회사인데 상대적으로 다른 회사 대비 기능들이 가벼운 편인 것 같습니다. 16년도쯤에 개발되었다고 팀장님께 들었는데 변수들은 거의 var 키워드로 선언되어있고 제이쿼리 사용하고 $.ajax로 통신하고 클래스 못보고 prototype, symbol 쓰는 코드도 못봤습니다. ES6는 나온지 꽤 돼었고 현재 알려주신 부분도 class 등은 얼추 보았지만 사실 이걸 활용해봐야 익숙해질텐데 그렇지를 못하네요ㅜㅜ 현 상황에서 코어자바스크립트도 눈에 읽히면 좋겠고 지금은 다시금 자바스크립트 2회독을 해나가고 있는데 어떻게 스탭업을 해야할지 조언 구해도 될까요??
React 개발시 이벤트 핸들러 메소드를 선언할때는 호이스팅이 되는 Function 키워드가 좀더 편하게 다가옵니다. 함수 선언 위치를 신경쓰지 않아도 되기 때문입니다. 그리고 const clickEventHandler = ( event : ClickEvent ) => { } ; 보다 function clickEventHandler(event : ClickEvent) {} 이 가독성 측면에서도 좋다고 생각합니다. 두 구문 다 서로 다른 특징을 가지고 있고, this 개념 사용이 필요없는 개발 환경의 경우, (어규먼트 등 도 마찬가지입니다. 둘다 사용할 필요가 거의 없죠) 호이스팅이 주는 강점과 가독성 측면에서만 생각하고 사용하면 될듯싶습니다. 또한 Next.js 와 같은 대형 프레임워크 에서도 export default functoin() 과 같은 형태를 기본값으로 채택하고 있습니다. 또한, React 에서 DOM 이벤트 리스너 할당시, arrow function 을 삽입하게 되면 작동하지 않습니다. function 키워드는 JS 의 근본이자, 브라우저의 근본입니다. js 의 this는 다른 언어와 매우 다른 특징을 가지고 있으며, 그것을 활용할 때가 반드시 옵니다 특히 브라우저 단에서 DOM 을 다루거나, 이벤트를 다룰 때 반드시 필요합니다. 그리고 특정 서드파티 라이브러리 에서는, 콜백 함수에 this 를 전달해주기도 하고, this 를 통해 라이브러리 접근 경로를 안내하기도 합니다. 따라서 개발자들이 function 키워드에 대한 적절한 사용법과 시점을 반드시 숙지해야 합니다. 따라서 function 키워드는 이제 잊어도 된다, 사용할 필요가 없다 라는 말은 100% 틀렸다고 생각합니다. "상황과 때에 따라서, 그리고 팀의 스타일에 따라서 유기적으로 선택" 이 옳은 표현입니다.
길게 작성해 주셨는데, 대부분은 제가 영상에서 이미 했던 얘기라서 넘어가겠습니다. (영상 보시고 댓글 다신거 맞나요?) "React 에서 DOM 이벤트 리스너 할당시, arrow function 을 삽입하게 되면 작동하지 않습니다." 이부분은 잘못 알고 계신 것 같습니다. DOM, 이벤트를 다룰 때에도 this가 반드시 필요하지는 않습니다. event.currentTarget에 동일한 정보가 담기기 때문입니다.
export default 에서 화살표를 사용하지 않는것은 괜히 그런게 아닙니다.... 단순히 함수로써 export하는게 아니라 모듈로써 사용하기 위해 function을 쓰는것일텐데요 그러니까 함수로써의 function이 필요하다의 주장에 힘을 싣기에는 적절하지 않아보입니다.
@@FERoy 1. 만약 모듈에서 제공하는 특수한 변수나 내부메서드를 사용하기 위해선 export되는 객체나 함수 안에 this바인딩이 필요할 겁니다. 화살표는 그것을 해주지 못하구요. 2. 함수로써 다른곳에서 재사용 하기위해 export 하는 목적이라면 this바인딩이 들어갈 필요가 없겠죠.(모듈로써 사용하기 위함이지만 단순히 a*b만을 계산하는 함수라면) 근데 생각해보면, 모듈에서 객체를 만들 때 this가 필요하면 class로 만들면 될것입니다. 동영상에서 말씀하신것처럼 function으로 this를 사용할 이유가 없죠. 루루님이 말한 'Next.js 와 같은 대형 프레임워크 에서도 export default functoin() 과 같은 형태를 기본값으로 채택하고 있습니다.'의 이유는 그냥 관습이라서 그런게 아닐까요? -> 이부분은 리액트, 넥스트 동작방식을 딥하게 알지 못해서 모르겠네요. 좀 뒤져봤는데, 아마도 return문을 달아서 html요소를 보내줘야 하기 때문인것 같습니다. 그래서 class로 export를 하는 모듈이 있나 찾아봤는데 axios가 그렇게 하고있습니다. 구조를 천천히 보면 function이 남아있는 모습도 보이지만 class를 주로 사용하고있네요. 특히 TS파일들에서는 function이 보이지가 않습니다. 이미 고수들은 재남님의 의견과 동일한 생각을 가지고 있나봅니다. 12분짜리 영상에서 얻어가는게 많은것같네요 JS딥다이브 때부터 신세 많이 지고 있습니다
좋은 영상 감사합니다! 전반적인 영상의 모든 내용에 공감합니다! 다만 굳이~ 반례를 찾자면 IIFE + 함수가 섞인경우에 arrow function의 경우 익명함수로밖에 쓸수없는것 같아요 이럴경우 함수명이 없으니까.. stack tracing을 하는경우에 디버깅이 원할하지 않다? (실제 해보진 않았습니다.) 는 단점이 있을것 같네요. const a = (function getA() { return 'a' })() const b = (()=> { return 'b' })()
가변 매개변수를 가지는 함수의 경우에는 function을 사용하는 거 어떻게 생각하시나요? arrow function으로도 가변 매개변수를 커버할 수 있지만(가능한 모든 매개변수를 선언해놓고 가변 매개변수에 대해서 그 인자가 undefined인지 검사하는 방식) function을 활용하면 arguments.length를 활용할 수도 있으니까요.
arguments는 deprecated 되었어요. 대신 rest parameter를 쓰면 되는데 그건 function이냐 arrow냐와 무관합니다. developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Function/arguments
@@FERoy 오 그렇군요. 그럼 사실상 제너레이터를 제외하면 딱히 쓸 일이 없네요. 궁금한 게 더 있는데요. 자바스크립트에서 다른 클래스 기반 OOP 언어에서처럼 클래스 상속(extends)을 쓸 일이 많은지 궁금합니다. 제가 본 다른 라이브러리나 모듈에서는 클래스나 프로토타입을 이용해서 인스턴스의 원형을 정의하는 경우는 봤어도 다른 클래스를 상속하는 경우는 거의 못 본 것 같습니다.
typescript는 es2015 이전부터 진행되어온 ecmascript와 무관한 별개의 프로젝트로, typescript의 방향성이 자바스크립트의 방향성과 일치한다고 볼 수는 없을 것 같아요. 저도 함수 오버로딩은 아쉬운 부분이긴 합니다. 당장은 방법이 없어서 말씀하신대로의 상황이지만, 관련해서 arrow function의 함수 오버로딩을 지원해달라는 제안이 여럿 나오고 있는 것으로 압니다.
'좋을 때'라는게 어떤 경우를 말씀하시는건지 모르겠습니다. 제가 언급한 경우들에 대해서는 득보다 실이 많은 것 같거든요. 그래서 영상 전반에 걸쳐 말씀드린 게 바로 function에 장점은 없으니 아예 쓰지 않아도 된다- 라는거였습니다. 다만 이는 어디까지나 제 사견일 뿐이니 이를 받아들일지 말지는 시청하시는 분들 각자에 달려있는 것이고 그런 맥락에서 '취향'을 언급한 것입니다.
@@mochaloving789 caniuse.com 에서 기능별로 하나하나 확인해보실 수 있습니다. IE10 이하만 아니라면 ES2015의 중요한 기능들은 어지간해선 다 되는 것으로 알고 있지만, 나열하신 모든 환경을 제가 전부 테스트해본 것은 아니라서 확실히 말씀드리긴 어렵네요. 호환성이 중요한 업무를 하는 분이시면, babel을 도입하시는걸 추천드려요. ES3환경으로까지 트랜스파일이 가능하니, 호환성 염려는 안하셔도 될겁니다.
와 정말 정말 감사합니다. function A() { } vs const A = () => {} 어떤 스타일로 선언하는게 맞는지 항상 고민되었고 const obj = { method: function() { } } vs const obj = { method() { } } 어떤 스타일로 정의하는게 맞는지 항상 고민이었는데 명확하게 답변이 되었어요 ㅎㅎ 감사합니다 😄😄👍👍
event listener 함수 내부에서의 this는 event.currentTarget과 같으니, this 대신 event.currentTarget으로 교체하면 this를 쓸 이유가 없어집니다. developer.mozilla.org/ko/docs/Web/API/EventTarget/addEventListener#%EC%9D%B4%EB%B2%A4%ED%8A%B8_%EC%88%98%EC%8B%A0%EA%B8%B0_%EB%82%B4%EB%B6%80%EC%9D%98_this_%EA%B0%92
댓글들 보면 너무 답답함 나도 화살표함수 이해하기 처음에 좀 어려웠는데 걍 적응중임 가독성 부분은 function a(){} 이게 월등하긴 하지 영상 보면 그 외에는 장점이 없는거 같은데 유지보수 => 당연히 쓰던거 써야 겠지 다 뜯어 고칠 수 없겠지 뭔 당연한 얘기들로 시비 걸고 있음 ㅋㅋㅋㅋ 걍 가독성 때문에, 눈에 안익어서, 이해하기 힘들어서, 쓰기 힘들다고 솔직하게들 말해라 ㅋㅋ 댓글들 보니 짜증
'보편적인 방식'이란 어떤것이며, 그것은 변할 수 없는 절대명제일까요? 세상은 끊임없이 변하고 발전하고 있는데, 그 보편성의 원칙에만 얽매여 있다면 언제쯤 변화를 따라가는 것이 가능해질까요? 이런 부분도 함께 고려해 주시면 좋겠어요. 협업을 하는 모두가 함께 변화를 시도한다면 불가능한 것도 아니고 문제될 일도 없습니다. 가독성에 문제가 생기지도 않고요 :)
와 댓글 읽다 보니 영상은 안 보고 제목만 읽고 무지성 반박하는 사람들 뭐죠ㄷㄷㄷㄷ 유튜브니까 제목이 좀 자극적일수록 클릭 수 늘어나고 결과적으로 더 많은 사람들이 유익한 영상을 보는 큰 그림을 그리신 걸로 이해했습니다ㅎㅎㅎ영상 올려주신 것만으로도 너무나 감사드리고 늘 응원합니다❤🎉😊
오 내용이 너무 좋습니다. 비전공에 자바스크립트 완전 초보라 최근에 개발을 하게되면서 공부중입니다. 영상 내용의 30%정도 이해한 것 같아요. 근데 앞으로 개발을 위해 100% 이해하고 싶지만 배경지식이 너무 부족하네요! 조금더 쉬운 버전으로 다시 설명해주시면 저같은 초보에겐 더더욱 좋을것 같아요. 그럼 책사서 자바스트립트 기본지식좀 공부하러 가겠습니다
![[Javascript 미세팁] if else 리팩토링 #1 (feat. 객체 + 함수)](http://i.ytimg.com/vi/p0YEviesgRM/mqdefault.jpg)
클래스는 prototype의 편의문법이 아닙니다.
www.bsidesoft.com/5370
roy-jung.github.io/161007_is-class-only-a-syntactic-sugar/
공감합니다~ 모던한 자바스크립트의 경우 var와 마찬가지로 function은 거의 사용할 필요가 없는 키워드이기는 합니다.
최신 함수형 프로그래밍의 경우는 this를 사용할 필요가 없는데다가 권장하지도 않죠.
function만이 가지고 있는 this, name, arguments등의 활용법이 있기는 하지만 정말로 특수한 경우이고 메소드의 경우에는 prototype을 확장하기 위한 특수한 경우가 아니라면 class나 Object기반으로 생성을 하는 것이 더 나은 코드를 만들어 준다고 샹각합니다
말씀하시고자 하는 것 처럼 현대자바스크립트는 const와 arraw function을 베이스로 하고 나머지를 특수한 케이스로 상정하고 개발을 하는 것이 더 나은 방식이라고 생각합니다
좋은 영상 감사합니다 :)
헉 테오님, 누추한 곳에 귀하신 분이.. 영광입니다!
자극적인 워딩이라서 뭐지? 했는데 최신 문법에 대한 얘기를 잘 풀어주신 것 같아요. 그간의 function이 전천후로 사용되었기 때문에 자바스크립트의 발전에 맞춰 적절한(책임과 범위가 명확한) 기능들이 생겨났으니 적극적으로 활용하면 더 좋다는 것에 동의합니다.
제목이 자극적이었나요? 전 정말로 그래도 된다고 생각해서 쓴건데 ㅎㅎ
와 꿀팁이네요!! 감사합니다
좋은 의견입니다. 주장의 내용과 이유가 분명하고, 설명이 구체적이면서도 설득력이 있군요. 전 오래된 개발자고, 자바스크립트를 많이 쓰지만 메인 툴이 아니라 이런 디테일까지 신경쓰지 않고 있었는데, 잘 설명해 주셔서 감사합니다. 팀원들을 이런 방식으로 설득하고 룰을 만들어야 겠어요.
결론만 말하면, 당신이 var를 안 쓰는 사람이라면 같은 이유로 function도 쓰지 않기를 고려해보라는 거군요!
JS 배운지 얼마 안 됐는데, 일반적으로 var는 그냥 쓰지 말라고들 하는 반면에 arrow function은 항상 alternative로 제시되는 것만 봐 와서 이런 차이가 있는 줄 몰랐습니다 😂 좋은 영상 감사드려요!
우와 이펙티브 타입스크립트 부터 봤었는데 완전 떡상하셨네요 ㅋㅋㅋㅋㅋ 신기합니다 ㅋㅋㅋ 그리고 항상 느끼지만 알고 자바스크립트에 대한 깊이가 엄청나신거 같습니다 ㅋㅋㅋ 영상 잘 봤습니다~
그러게요 저도 놀랍고 부담되고 막 그르네요ㅠ
공부는 파도파도 끝이 없는거 같아요 ㅎㅎ
모든 function을 100% arrow function으로 대체할 수는 없는건데 제목은 그런 의미로 적으셔서 사실이 아닌걸로 과장을 하신것이니 안 좋게 보시는 분들이 계신듯. 아예->웬만하면으로 쓰셨으면 사실에 기반한 과장이니 아무런 문제가 없었을 것 같아요.
별개로 영상은 너무 유익하게 잘 봤습니다
c++에서 넘어와서 js배우는 중입니다.
function 키워드로 저렇게 다양한 작업을 하도록 하는게
js에서 가장 이해 안되었던 부분인데
확실히 이렇게하면 엄청 명확해지네요
감사합니다.
객체의 축약형은 const a=0;b=0; result={a:a, b:b} 대신 key, value 가 같은면 전달된 인자 만 사용 result={a,b}
객체에서의 일반함수는 key,value 형태의 함수표현식
method: function() {} "생성자함수로 사용가능, this 바인딩이 동적으로 됩니다,"
method: () => {} "Arrow Function 는 자기 this 는 없지만 사용 할 경우 한 단계(block scope) 위의 this 정적 바인딩 됩니다
ES6 에 추가된 객체의 메서드 method() {} "생성자함수 사용불가"
2줄 요약
1. jsx 만들 때 export default를 함께 못써서 아쉽지 않은가요?
2. git diff로 볼 때 중첩 함수내에 function은 아래쪽에 몰아 넣어두는게 유용하지 않나요?
## 1. jsx 만들 때 export default를 함께 못써서 아쉽지 않은가요?
jsx 요소를 반환하는 함수를 작성할 때, 그러니까 리엑트에서 컴포넌트를 작성할 때 파일 하나당 하나의 컴포넌트를 담을 때 번거로운 점이 있습니다.
`function`으로 작성하면 export default를 붙일 수 있는데 화살표 함수로 하면 그렇지 못해서 export문을 찾아야 합니다.
compound나 HOC를 많이 사용할때는 export 를 따로 빼 줄 필요를 느끼는데,
그렇지 않을 때는 화살표 함수에 `default`를 적지 못해 아쉽습니다.
```js
export default function Component () => {
return
}
```
```js
const Component = () => {
return
}
export default Component
```
## 2. git diff로 볼 때 중첩 함수내에 function은 아래쪽에 몰아 넣어두는게 유용하지 않나요?
함수 내부에 중첩 함수를 만들 때 function을 사용하면 호이스팅의 도움(?) 으로 함수 아래쪽에 중첩 함수를 몰아 넣을 수 있는데요.
(리팩터링 예제들 같이)
git diff를 볼 때 가독성에 좀 도움이 되는 것 같습니다.
읽어주셔서 감사합니다.
이 내용은 다른분들 의견도 듣고 싶네요! 댓글이 많이 달리면 좋겠다는 바람을 하며 제 의견 적어보겠습니다 ㅎㅎ
1. 맞아요, 좋은 지적이십니다. 이부분 때문에 호불호가 나뉘는 것 같더라구요. 그래서 저는 export default는 코드의 맨 마지막 줄에서 한다는 규칙을 정해두었습니다. 한 변수명을 두 번 적어야 하는 불편이 있긴 한데, 그 대신 export default를 중복 선언하는 경우는 확실히 막을 수 있더라구요. (물론 중복선언한 경우 ide에서부터 오류를 잡아주긴 하지만요 ㅎㅎ)
나아가 어떤 사람들은 export function() {} 같은 형태가 여러개인 코드는 어떤걸 export 했는지 확인하기 어려워서 마찬가지로 맨 마지막에 한꺼번에 export { a, b, c ... } 식으로 몰아서 하기도 하던데, 이 방법도 꽤 좋다고 생각합니다. (commonjs 시절엔 이렇게밖에 할 수 없었죠)
이런 규칙들을 정해두면, 작업할 때는 쪼끔 번거롭지만, 나중에 코드를 볼 때는 export 내용을 확인하기가 꽤 용이합니다. 나아가 중간중간 export const였다가 그냥 const였다가 들쭉날쭉하지 않아 코드 가독성도 쫌 좋아지는 효과도...ㅎ
아무튼 export default를 바로 하지 못하는건 저도 아쉽긴 하고, 그래서 function을 계속 쓰는 분들이 많다는 것도 이해는 합니다. 성능상의 불이익이나 모호함 등을 감수하더라도 약간의 편리함을 유지하는 편이 나은가, 혹은 약간의 불편을 감내하는 편이 나은가? 하는 가치판단의 영역이라 정답은 없겠죠.
추가로, 사실 '못'하는건 아니에요. export default () => { ... } 식으로 익명함수로는 가능합니다. (애초에 화살표함수는 익명함수죠. 변수에 할당할 때 name 프로퍼티의 값을 자동으로 지정해줘서 익명이 아닌것처럼 보일 뿐)
2. git diff시 가독성에 도움이 된다는건 이해가 잘 되지 않는데요. 내부함수 수정시 코드 라인이 늘거나 줄어서 그렇다는 말씀이신가요? 그렇더라도 diff가 엉뚱하게 되는건 아닌듯 한데...
함수들을 아래쪽에 몰아둘 경우, 말씀하신 가독성 측면은 제가 잘 모르겠고, 문제가 발생할 소지가 있다는 건 확실해요. 예컨대 아직 초기화되지 않은 변수에 접근하게 되는 경우가 얼마든지 발생할 수 있습니다. 이런건 휴먼에러라서 런타임 이전엔 알아내기가 어렵죠.
function outer() {
let a = 1;
inner();
const b = 2;
inner();
function inner() {
console.log(a, b);
}
}
그렇다고 '변수선언은 함수 최상단에서만 하자!'는 규칙을 정하면, TDZ 개념을 도입한 취지가 무색해지게 옛날 방식의 코드가 되어버리고, const로 해결될 걸 let으로 선언해야 하는 경우도 발생할 수 있어서 좋은 규칙이 아닌 것 같습니다. (그래서 전부 var로 퉁치자! 라는 규칙을 정하는 곳도 봤지만...뭐 다 회사가 팀이 정하기 나름인거죠)
1번은 취향의 문제라 생각했는데요, 2번은 재남님이 말씀하시는 상황이 분명 발생할 수 있을거 같습니다. 좋은 인사이트를 주셔서 두분 다 감사합니다 🙇🏻🙇🏻
1번은 윤석님과 재남님의 대화로 잘 설명이 되어서 2번 의견만 덧붙이자면,
git diff시 가독성 자체에는 크게 문제를 못 느꼈어요.
도리어 코드 전체를 봤을때 "이 함수는 어디에 선언이 되어있는거지?" 라는 혼란은 느낄 수 있다는 생각이 듭니다!
(호이스팅 자체가 개발자가 코드를 파악하는데 긍정적으로 작용하는 동작은 아니라고 생각해요)
개인적으로는 중첩함수의 형태도 그렇게 좋은 패턴은 아니라고 생각하지만, 이 부분은 호불호의 영역인 것 같아요.
다만 휴먼 에러를 방지하자고 변수 선언을 모두 var로 퉁치자는 의견은... 납득하기 조금 어렵습니다 ㅠㅠ😥
저는 추가로 React.forwardRef로 Function Component를 감쌀 때 익명함수는 displayName등을 지정하지 못하는게 좀 불편해요. 따로 빼서 정의하는것도 좀 그렇고 ㅋㅋ 그럴 땐 그냥 function을 쓰는게 좋겠더라구요.
개인적으로는, 단순하게 함수로 사용할 때는 function이 훨씬 직관적으로 보입니다.
클래스를 표현하거나, 클래스나 오브젝트 내부의 메서드는 말씀하신 것 처럼 function을 쓰지 않았을때도 가독성을 해치지 않지만,
함수와 변수를 잘 구분해주기에는 function 키워드 만큼 한눈에 파악하기 쉬운게 없지 않나 싶습니다.
arrow function같은 경우는 변수들과 섞여서 있을 때 함수라는 것을 한 눈에 보지 못하는 경우가 많고,
bind할 필요가 없는데 arrow function을 반드시 써야한다고 생각하지도 않습니다.
실제 최신 라이브러리(프레임워크)라고 할 수 있는 React나 Vue 역시 function 키워드를 내부 코드에서 활용하고 있습니다.
어떻게 생각하시는지 궁금합니다.
- 가독성은 IDE에서 함수와 변수의 색상을 달리 표현해주기 때문에 function이라는 키워드가 없더라도 한눈에 파악하는 데에 불편을 전혀 느끼지 못하고 있어요.
- 최신 라이브러리들도 function을 쓰고 있다는 사실이 제가 주장하는 포인트들과 어떤 관련이 있나요? 그런 것을 가치판단의 근거로 삼는 것이 오히려 적절치 않을 것 같습니다.
- 성능상의 이점을 누리고 휴먼에러 가능성을 배제하기 위해 function 사용을 자제할 것인가, 아니면 그럼에도 불구하고 말씀하신 가독성이나 기타 다른 이유로 사용을 고수할 것인가인데, 그 결정은 회사가, 팀이, 개인이 각자 정하면 될 일이죠. 옳다 그르다의 문제가 아니니까요 :)
@@FERoy
두번째 최신 라이브러리들에 대한 부분은 가치판단의 기준으로 삼는다기보다는 무조건 써서는 안된다는 내용에
위와같이 최신라이브러리 들에서도 활용하고 있는 만큼 가독성이나 기타 이유에서 쓰이고 있다는 점에 힘을 실고 싶었구요.
function을 쓰고 쓰지 않았을때에 대해서 성능상의 이점은 사실 거의 없다고 보입니다. 직접 테스트 해보신 벤치마크가 있을까요? 저도 직접 해보진 않았지만 레퍼런스를 검색해봤을때는 오히려 function키워드가 arrow function보다 빠른 벤치마크가 있네요. (dev.to/georgecoldham/using-arrow-functions-might-be-costing-you-performance-4fm6)
사실 이런 성능차이는 실제 서비스 운영에는 거의 영향을 주지않는 무시할만한 수준이라고 보구요. 이런경우에는 함수와 변수를 구분해줄때의 이점이 분명히 있다고 생각합니다.
대부분의 프로그래밍 언어들에서 변수와 함수 선언을 구분해주는 이유가 있다고 생각합니다.
저도 회사,팀,개인이 트레이드 오프를 따져서 결정해야 한다는 말에 동의합니다.
답변 감사합니다 :)
성능상의 이점이라는게 속도측면을 말하려던건 아니고 메모리를 덜 차지한다는걸 얘기하러던 거였어요(prototype, this정보를 담지 않아 가볍다)
말씀대로 실제 속도상에 차이가 있더라도 그 차이는 미미하여 무시해도 될 수준일거 같아요!
그리고 제목에 '아예' 라고 적었지만 영상 전반의 취지는 '무조건' 쓰지 말라는건 아니었습니다. 그저 앞으론 이런걸 써보는게 좋겠다-는 제안의 목적이 강했는데, 제목 잘못 지어서 본의아니게 어그로가 많이 끌린것 같네요 ㅠ
타입 명료한 언어로 주로 개발하다 js 쓰게되면 function이 정말 이해가 안가더라구요. 협업할때 문제가 일어날 가능성이 높다 생각합니다.
class라던지 let const 함수는 안쓸 이유가 없는거같습니다.
Node 개발 할 때 너무 혼용해서 쓰는 걸 어떻게 하면 나아질까 했는데 이렇게 논리적으로 나눠서 생각하니까 길이 확연히 보이네요! 좋은 영상 감사합니다!
공감!!!
function내 this의 사용이 혼란을 가중시키지 function은 가독성 측면에서 아주 유용합니다.
회사코드는 linter가 빨간줄 그어서 const 로 바꾸긴 하지만 가독성 측면에서는 아무리 에디터가 컬러링 해준다 해도 함수를 함수라고 쓰는게 좋긴 좋아요ㅋ
개발을 하다보면 적지 않은 경우에 function을 써야할 때가 반드시 있습니다. Arrow function이 도입되기전에 설계된 라이브러리에 콜백 함수를 넘길 때 그 안에서 this를 써서 해당 라이브러리의 객체를 가져올 수 밖에 없는 경우가 있기 때문입니다. 무조건 이라는 말은 언제나 위험합니다.
당연히 쓸수밖에 없는 환경에선 써야죠~
조회수를 위해 영상 제목을 자극적으로 적는게 상당히 이질적이기는 합니다..
댓글을 많이 봤는데 영상 주인분도 댓글들에 상당히 공격적인 성향도 있으시네요.
새로운 기능이나오고 공부하는건 상당히 좋은 활동이기는 한데.. 글쎄요 제목에서 일단 쓰지말라고 하는게...
자바스크립트를 아는사람이 보기에는 새로운 자극이 되겠지만 이제 배우는 사람 입장에서보면 상당한 혼동을 줄수가 있으니까요.
실직적으로 실무에서 사용성을 봤을때 버전업된 언어는 지양해야 하는게 대부분이죠. 리스크적인 부분도 있고,
내가 그 코드를 짜고 그코드가 사향할때까지 내가 유지보수를 평생 하지는 않을테니간 말이죠..
0.1%의 천재개발자도 필요하지만 유지보수를 위해 99%의 개발자들이 쉽게 이해할수있는 코딩도 중요하니까요.
@@Whiteblueter 제 마지막글을 캐치해서 답글 달아주신거같은데 서로간의 이해점이 달랐던거 같습니다.
무슨 말씀이신 알겠는데 제가 말한 유지보수개념은 이미 범용적으로 사용하고 있는 함수를 무작정 쓰지못한 몹쓸것이라는 뉘앙스가 크게 다가와 적어드린겁니다.
지금까지 필요에 의해 사용해 왔고 이제 새로운 문법이 생겨서 차츰 개선을 하자는 의견을 제시한다면 상당히 긍정적으로 다가오겠지만 대안점이 없는 시점에 사용한 함수를 개선된 문법이생겼다고 깔아내리는 느낌이 제생각에는 '비행기가 생겼는데 차는 왜타고댕겨? 차는 아예 생산하지도마' 같은 느낌으로 다가와서 남겨드린 글입니다.
추가로 파이선이 한때 유행처럼 번질때 자바언어는 죽어갈거라는 말이 나온시점도 있었고, 타입스크립트가 나왔을때도 자바스크립트는 죽어갈것이라는 말이 나온적이 있습니다.
하지만 실 사용하다보니 문제점들도 발견되었고 결국 자바가 아직 우세에있고 타입스크립트가 신세계라는 말도 점점 줄어들게 된것이고요.
저또한 펑션이 만능이라는 말이아니고 영상주인분의 설명해주시는 문법이 차후에는 일반화되는 기초적인 문법이 될수도 있다는걸 압니다만, 항상 새로운 문법이 무조건 옳다는 맹목적인 맹신은 하지 말아야 한다고 생각해서 적어드린 글이었습니다.
조회수 때문에 조금 자극적으로 쓴 감이 없지 않나 합니다. 가끔 유튜브를 보다보면 내가 잘못 알고있는 것인가 싶어서 헉 하고 시간 내서 들어보면 그냥 자극적인 소리인경우가 있긴합니다.
바벨, 타입스크립트가 대중화된 요즘엔 class 대신 생성자함수쓰는걸 거의 볼수 없음.
또 함수내에서 this 쓰는것도 이제는 거의 못봄.
위 두가지가 제외되면 function이 목적을 더 명확히 보여줌.
const로 화살표함수만쓰면 변수랑 헷갈릴때가있음.
fp식으로 코드짜면 함수자체가 짧은경우가많아서 더 그럼.
또한 호이스팅안되는거도 불편함.
고로 저는 function을 선호합니다.
개발환경은 정말 다양한 것 같아요. HG님처럼 class를 쓰는 곳도 많이 있지만, 댓글들 보다보면 아직까지 그런 환경이 갖춰지지 않은 곳도 많이 보이는 것 같습니다.
저는 중첩 함수 선언할 때 개인적으로 function으로 마지막에 몰아서 선언하는 게 가독성에는 더 좋아보이더라고요. const arrow function 방식으로 선언하고 사용하면 함수 사용하기 직전에 선언하고 사용하거나 초반에 다 선언하고 사용하거나 해야되는데 개인적으로는 함수 초반에 중첩 함수 정의를 하는 게 좋아보이지 않아서 실제 로직부터 보여주는 식으로 하고 있습니다.
물론 이걸 외부로 빼는 방식도 있지만 그러면 또 응집도가 낮아지는 문제가 있고 그렇다고 객체로 만드는 것도 너무 과해보이고요.
선언 위치에 따른 가독성은 개인적인 취향의 문제니 옳다 그르다를 논할 건 아니죠. 다만 그럴 경우 초기화되지 않은 변수에 접근하는 휴먼에러를 조기에 발견하기가 어렵다는 단점이 있습니다.
@@FERoy 그건 arrow function도 상황에 따라서 똑같지 않나요? 어차피 function의 경우도 호이스팅으로 인해 콘텍스트 초반에 선언되는 거라 arrow function을 초반에 선언하게 된다면 별 차이는 없을 것 같습니다. 실질적으로요.
문제는 함수에서 참조하는 외부 변수가 선언 되기 전에 함수를 호출했는지가 문제니까요.
이걸 해결하려면 함수는 항상 그 변수 선언 이후에 선언되어야 한다는 코딩 스타일이 강제되더라고요.
그렇네요! 제가 잘못 생각했네요.
그렇다면 중복선언을 허용하느냐 그렇지 않느냐의 문제만 있겠네요.
@@FERoy 중복 선언 문제는 확실히 const arrow function이 방지 가능하네요.
우와 완전 꿀강의!! 이해도 잘되고 납득도 잘되고 도움도 되었습니다❤
각자 역할에 맞게 사용하자 ! 좋은 영상 잘 보고갑니다
Java / C++에서는 함수선언과 구현이 따로있고 function 없이 사용되어 가독성이 문제였는데 JS도 가능하군요
감사합니다!! 항상 잘 보고 있습니다.
비즈니스로짇이 들어가서 일반적으로 3만줄 이상 들어가는 페이지의 경우 튜닝시 가장먼저 하는 것이 에로우 메소드를 걷어내는 것 입니다
제목이 자극적인데 실제 학습용이나 간단한 짧은 그크립트의 경우, 또는 한 페이지에 많은 스크립트가 아닌 메뉴를 나누거나 하여 모듈화 시킬 경우 동영상과 같이 의도를 명확히 하여 코딩하는것이 좋으나
페이지당 비즈니스로직이 복잡하여 브라우저메모리를 신경써야 하는경우 에로우 메소드를 쓸 경우와 그냥 펑션만 쓸경우 얼추 20배 정도의 속도를 채감할 구 있습니다
'일반적'이라고 하셨는데, 차던브라님이 속한 세계와 제가 속한 세계가 다를 수 있겠다는 생각이 드네요.
모던브라우저(v8엔진 등)에서 애로우함수와 기존함수의 성능비교를 해보신 적이 있나요? 최적화가 많이 이루어져서 지금은 기존 function과 arrow 함수 사이에 유의미한 성능 차이는 없습니다. 혹시 babel을 돌려서 사용하시는 것은 아닌지요?
정리해서 알려주셔서 정말 감사합니다!
이건 짱이네요 ! 바로 적용하겠습니다 !
와 function 처음 배울 때 함수하나로 여러 방법들로 사용해서 이해하기 어려웠습니다. 당연히 예외처리 또한 이해하기 어려웠구요. 그러다 디스바인딩 이슈를 보고 신문법 arrow를 사용하고 클래스를 사용했는데, 딱히 확실한 이해를 하지 못한채 사용해서 찝찝한 감이 없지않아 있었습니다.
우연히 피드에 떠서 보게되었는데..정말 유용한 내용들이네요!
바로 구독했습니다!
감사합니다 이런 거 자주 올려주세요 너무 좋아요~!!❤
이런 강의를 볼 때마다 새삼 유튜브에게 얼마나 감사한지 모릅니다. 잘 보고 갑니다!
this 는 진짜 쉽고 강력한 기능인데... 왜 어렵다고 생각할까요??
글쎄요, 전 this와 관련해서는 여전히 헷갈리는 케이스가 참 많던데요-
물론 저 개인의 능력부족 때문이겠지만요 :)
좋은 영상 감사합니다! 항상 명확한 디테일로 근거를 들어주셔서 js 공부를 할 때 큰 도움이 됩니다 😆
재남님 안녕하세요 자바스크립트딥다이브 책을 1회독 하고 아 좀 어려운데 코어자바스크립트 얇고 좋다니까 같이 보면 2회독할 때 이해되지 않을까?? 하고 의기양양하게 책 사서 읽어봤는데 .. 내용은 좋다는게 느껴졌는데 아직 제 실력이 부족해서인가 레퍼런스 부분도 온전히 이해 안가고 변수 다음으로 넘어가기가 너무 부담스럽더라구요
제가 다니는 회사는 작은 플랫폼 회사인데 상대적으로 다른 회사 대비 기능들이 가벼운 편인 것 같습니다. 16년도쯤에 개발되었다고 팀장님께 들었는데 변수들은 거의 var 키워드로 선언되어있고 제이쿼리 사용하고 $.ajax로 통신하고 클래스 못보고 prototype, symbol 쓰는 코드도 못봤습니다. ES6는 나온지 꽤 돼었고 현재 알려주신 부분도 class 등은 얼추 보았지만 사실 이걸 활용해봐야 익숙해질텐데 그렇지를 못하네요ㅜㅜ 현 상황에서 코어자바스크립트도 눈에 읽히면 좋겠고 지금은 다시금 자바스크립트 2회독을 해나가고 있는데 어떻게 스탭업을 해야할지 조언 구해도 될까요??
따로 연락 드리겠습니다.
React 개발시 이벤트 핸들러 메소드를 선언할때는
호이스팅이 되는 Function 키워드가 좀더 편하게 다가옵니다.
함수 선언 위치를 신경쓰지 않아도 되기 때문입니다.
그리고
const clickEventHandler = ( event : ClickEvent ) => { } ; 보다
function clickEventHandler(event : ClickEvent) {} 이
가독성 측면에서도 좋다고 생각합니다.
두 구문 다 서로 다른 특징을 가지고 있고, this 개념 사용이 필요없는 개발 환경의 경우,
(어규먼트 등 도 마찬가지입니다. 둘다 사용할 필요가 거의 없죠)
호이스팅이 주는 강점과 가독성 측면에서만 생각하고 사용하면 될듯싶습니다.
또한 Next.js 와 같은 대형 프레임워크 에서도 export default functoin() 과 같은 형태를 기본값으로 채택하고 있습니다.
또한, React 에서 DOM 이벤트 리스너 할당시, arrow function 을 삽입하게 되면 작동하지 않습니다.
function 키워드는 JS 의 근본이자, 브라우저의 근본입니다.
js 의 this는 다른 언어와 매우 다른 특징을 가지고 있으며, 그것을 활용할 때가 반드시 옵니다
특히 브라우저 단에서 DOM 을 다루거나, 이벤트를 다룰 때 반드시 필요합니다.
그리고 특정 서드파티 라이브러리 에서는, 콜백 함수에 this 를 전달해주기도 하고, this 를 통해 라이브러리 접근 경로를 안내하기도 합니다.
따라서 개발자들이 function 키워드에 대한 적절한 사용법과 시점을 반드시 숙지해야 합니다.
따라서 function 키워드는 이제 잊어도 된다, 사용할 필요가 없다 라는 말은 100% 틀렸다고 생각합니다.
"상황과 때에 따라서, 그리고 팀의 스타일에 따라서 유기적으로 선택"
이 옳은 표현입니다.
길게 작성해 주셨는데, 대부분은 제가 영상에서 이미 했던 얘기라서 넘어가겠습니다. (영상 보시고 댓글 다신거 맞나요?)
"React 에서 DOM 이벤트 리스너 할당시, arrow function 을 삽입하게 되면 작동하지 않습니다." 이부분은 잘못 알고 계신 것 같습니다. DOM, 이벤트를 다룰 때에도 this가 반드시 필요하지는 않습니다. event.currentTarget에 동일한 정보가 담기기 때문입니다.
export default 에서 화살표를 사용하지 않는것은 괜히 그런게 아닙니다....
단순히 함수로써 export하는게 아니라 모듈로써 사용하기 위해 function을 쓰는것일텐데요
그러니까 함수로써의 function이 필요하다의 주장에 힘을 싣기에는 적절하지 않아보입니다.
@@권도훈-o1f
1. export default에서도 화살표 함수를 사용할 수 있습니다.
2. 무슨 말씀이신지 모르겠습니다. 함수로써 export하는 것과 모듈로써 사용하는 것의 차이가 무엇인가요? 모든 export는 모듈로써 사용하기 위함이 아닌가요?
@@FERoy 1. 만약 모듈에서 제공하는 특수한 변수나 내부메서드를 사용하기 위해선 export되는 객체나 함수 안에 this바인딩이 필요할 겁니다. 화살표는 그것을 해주지 못하구요.
2. 함수로써 다른곳에서 재사용 하기위해 export 하는 목적이라면 this바인딩이 들어갈 필요가 없겠죠.(모듈로써 사용하기 위함이지만 단순히 a*b만을 계산하는 함수라면)
근데 생각해보면, 모듈에서 객체를 만들 때 this가 필요하면 class로 만들면 될것입니다. 동영상에서 말씀하신것처럼 function으로 this를 사용할 이유가 없죠.
루루님이 말한 'Next.js 와 같은 대형 프레임워크 에서도 export default functoin() 과 같은 형태를 기본값으로 채택하고 있습니다.'의 이유는 그냥 관습이라서 그런게 아닐까요? -> 이부분은 리액트, 넥스트 동작방식을 딥하게 알지 못해서 모르겠네요. 좀 뒤져봤는데, 아마도 return문을 달아서 html요소를 보내줘야 하기 때문인것 같습니다.
그래서 class로 export를 하는 모듈이 있나 찾아봤는데 axios가 그렇게 하고있습니다. 구조를 천천히 보면 function이 남아있는 모습도 보이지만 class를 주로 사용하고있네요. 특히 TS파일들에서는 function이 보이지가 않습니다. 이미 고수들은 재남님의 의견과 동일한 생각을 가지고 있나봅니다.
12분짜리 영상에서 얻어가는게 많은것같네요 JS딥다이브 때부터 신세 많이 지고 있습니다
좋은 강의였습니다
좋은 영상 감사합니다!
전반적인 영상의 모든 내용에 공감합니다!
다만 굳이~ 반례를 찾자면 IIFE + 함수가 섞인경우에 arrow function의 경우 익명함수로밖에 쓸수없는것 같아요 이럴경우 함수명이 없으니까..
stack tracing을 하는경우에 디버깅이 원할하지 않다? (실제 해보진 않았습니다.) 는 단점이 있을것 같네요.
const a = (function getA() {
return 'a'
})()
const b = (()=> {
return 'b'
})()
하하 그렇네요. 다만 즉시실행함수 내부까지 stack을 살펴봐야할 정도의 상황이면 그냥 즉시실행함수를 쓰지 않는 편이 어떨까 싶기도 하군요 ㅎㅎ
가변 매개변수를 가지는 함수의 경우에는 function을 사용하는 거 어떻게 생각하시나요? arrow function으로도 가변 매개변수를 커버할 수 있지만(가능한 모든 매개변수를 선언해놓고 가변 매개변수에 대해서 그 인자가 undefined인지 검사하는 방식) function을 활용하면 arguments.length를 활용할 수도 있으니까요.
arguments는 deprecated 되었어요. 대신 rest parameter를 쓰면 되는데 그건 function이냐 arrow냐와 무관합니다.
developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Function/arguments
@@FERoy 오 그렇군요. 그럼 사실상 제너레이터를 제외하면 딱히 쓸 일이 없네요.
궁금한 게 더 있는데요. 자바스크립트에서 다른 클래스 기반 OOP 언어에서처럼 클래스 상속(extends)을 쓸 일이 많은지 궁금합니다. 제가 본 다른 라이브러리나 모듈에서는 클래스나 프로토타입을 이용해서 인스턴스의 원형을 정의하는 경우는 봤어도 다른 클래스를 상속하는 경우는 거의 못 본 것 같습니다.
객체지향이 필수가 아니라서 그렇겠죠. 리액트 클래스 컴포넌트는 React.Component를 extends하긴 합니다 ㅎㅎ
??? : "엑셀 퐝숀? 그런거 너무 믿지 마요"
의도는 알겠으나, 반대의견을 남깁니다.
ts 에서 함수에 여러 제네릭 케이스를 다루기 위해선, function 이 반드시 필요해집니다.
이 때문에 라이브러리 프로젝트들은 대부분 function을 사용하고 있습니다.
typescript는 es2015 이전부터 진행되어온 ecmascript와 무관한 별개의 프로젝트로,
typescript의 방향성이 자바스크립트의 방향성과 일치한다고 볼 수는 없을 것 같아요.
저도 함수 오버로딩은 아쉬운 부분이긴 합니다. 당장은 방법이 없어서 말씀하신대로의 상황이지만,
관련해서 arrow function의 함수 오버로딩을 지원해달라는 제안이 여럿 나오고 있는 것으로 압니다.
typescript 만 사용하다 보니 제가 너무 그쪽으로 생각해서 작성한 것 같습니다.
확실히 함수 오버로딩 개념자체가 필요 없는 js 환경에서는 올바른 글 같습니다.
저는 자바스크립트를 처음 배우기 시작한 지 꽤 오래 되었지만 모던 자바스크립트는 레거시 자바스크립트와 혼재되어 있다보니 요즘 세대들은 더욱 배우기가 어렵다고 생각되네요. 저도 헷갈리고요. 잘 정리해주고 계셔서 감사합니다. 구독+좋아요+알림 드릴께요.
고수의 향기가 느껴집니다
잘 배우고 갑니다
function을 선언하는 목적으로 function 키워드를 사용하지 않는 언어가 재정신 박힌 언어인가...
2ality.com/2014/12/one-javascript.html
요거 참고하시면 어느정도 수긍은 하실수 있으리라 생각해요
비교해주신 내용을 보면 장단점이 있는 것 같아서
제생각에는 목적에 따라서는 function이 좋을때도 있을 것 같아요
말씀대로 취향이라 아예 쓰지 말아야된다는 제목을 붙이신건 조금 지나치지 않나 싶은데요..
협업환경에서 어떤진 잘 모르겠네요
'좋을 때'라는게 어떤 경우를 말씀하시는건지 모르겠습니다.
제가 언급한 경우들에 대해서는
득보다 실이 많은 것 같거든요.
그래서 영상 전반에 걸쳐 말씀드린 게 바로
function에 장점은 없으니 아예 쓰지 않아도 된다-
라는거였습니다.
다만 이는 어디까지나 제 사견일 뿐이니
이를 받아들일지 말지는 시청하시는 분들
각자에 달려있는 것이고
그런 맥락에서 '취향'을 언급한 것입니다.
@라루스, 근거나 사례를 들어서 반대 의견을 내주시면 한 수 배워가겠습니다 :)
영상에 완전 설득 당했어요 ㅋㅋ
리액트 함수 컴포넌트 공식문서에 function을 사용하던데 이것도 arrow함수로 바꿔 사용해도 무방하나요?
물론입니다.
es6 문법이라 호환성 문제는 전혀 없는 걸까요? 클래스 부분도 호환성 문제가 있을 수 있다고 해서 사용을 안하고 있긴 합니다...
IE 대응을 말씀하시는 거라면 babel을 사용해보심을 추천합니다.
@@FERoy ie까지는 아니더라도 파폭, 오페라, 사파리, 네이버웨일, 그리고 모바일일때 삼성브라우저, 네이버앱브라우저, 카카오인앱, 기타 인앱 등등 모두 호환성 문제가 없는지 궁금해요...
@@mochaloving789 caniuse.com 에서 기능별로 하나하나 확인해보실 수 있습니다.
IE10 이하만 아니라면 ES2015의 중요한 기능들은 어지간해선 다 되는 것으로 알고 있지만, 나열하신 모든 환경을 제가 전부 테스트해본 것은 아니라서 확실히 말씀드리긴 어렵네요.
호환성이 중요한 업무를 하는 분이시면, babel을 도입하시는걸 추천드려요. ES3환경으로까지 트랜스파일이 가능하니, 호환성 염려는 안하셔도 될겁니다.
자바스크립트가 점점 발전함에 따라 목적성에 맞는 코드스타일을 적용할 수 있다는 점을 잘 짚어주신것 같습니다.
FE 개발자라면 한번쯤은 고민해볼 주제인데, 정리를 잘 해주셔서 도움이 되었습니다 구독 합니다 ^^!
구독 좋아요 알람설정
근데 댓글에 써주신 슈가신택스가 아니라는 링크를 고정시켜주세용.
엇 고정했었는데 언제 풀렸지.. 얼른 다시 해놓았어요 감사합니다!
function을 객체 생성자로 활용하는 경우가 많이 있나요?
전 생성자로 쓸 수 있다는 것을 알고는 있었지만 그렇게는 거의 안 써봐서요.
회사에 따라 환경에 따라 다르죠. 다른 댓글중에도 class를 포기하고 function으로 돌아갔다는 분이 보이네요
@@FERoy 아하. 어젯밤에 무슨말씀이신가 했는데, 방금보니 이해 됐습니다.
function을 그래도 기억해주세요,,, - function 올림
ㅜㅠ알고리즘덕분에 내용을 보게되었는데
평소에 왜이렇게 다양하게 펑션을 표현하지? 했던 부분을 상세하게 알 수 있었습니다.
아직 자바스크립트가 어려워서 여러번 보면서 더 편하게 이해해야할것 같아요
자세한 설명영상 감사합니다
Vue는안써요?
어떤 말씀이신지 모르겠습니다.
와 정말 정말 감사합니다.
function A() {
}
vs
const A = () => {}
어떤 스타일로 선언하는게 맞는지 항상 고민되었고
const obj = {
method: function() {
}
}
vs
const obj = {
method() {
}
}
어떤 스타일로 정의하는게 맞는지 항상 고민이었는데
명확하게 답변이 되었어요 ㅎㅎ
감사합니다 😄😄👍👍
혹시.. 이벤트리스너에 쓰일때는 그래도 필수일까요? 예를들어 탭 전환 이벤트를 만들 경우에 this를 많이 사용해서요
event listener 함수 내부에서의 this는 event.currentTarget과 같으니, this 대신 event.currentTarget으로 교체하면 this를 쓸 이유가 없어집니다.
developer.mozilla.org/ko/docs/Web/API/EventTarget/addEventListener#%EC%9D%B4%EB%B2%A4%ED%8A%B8_%EC%88%98%EC%8B%A0%EA%B8%B0_%EB%82%B4%EB%B6%80%EC%9D%98_this_%EA%B0%92
@@FERoy 감사합니다!
요즘 자막도 깔끔하게 다시고
전업 유투버의 길로 가시는 건가요
아뇨, 편집 넘넘 어려워서 전업은 좀...
그냥 시간 될때만 하고자 해요.
그러기에 당장은 미세팁 시리즈가 딱인것 같아요! ㅎㅎ
고맙습니다🦊💙
다만 ts에서 데코레이터 함수를 구현할때는 function 키워드를 반드시 써야되더라구요!
네 맞습니다. 영상에서도 언급했어요.
댓글들 보면 너무 답답함
나도 화살표함수 이해하기 처음에 좀 어려웠는데 걍 적응중임
가독성 부분은 function a(){} 이게 월등하긴 하지
영상 보면 그 외에는 장점이 없는거 같은데
유지보수 => 당연히 쓰던거 써야 겠지
다 뜯어 고칠 수 없겠지
뭔 당연한 얘기들로 시비 걸고 있음 ㅋㅋㅋㅋ
걍 가독성 때문에, 눈에 안익어서, 이해하기 힘들어서, 쓰기 힘들다고 솔직하게들 말해라 ㅋㅋ
댓글들 보니 짜증
😭
화살표함수 사용하는게 얼마나 어렵다고 그러겠습니까.. 제 입장에선 IE에서 지원하지 않는다는게 가장 큰 문제일듯 싶습니다 :)
잘봤습니다.
잘보고가용
ㅎㅎ 준형이 잘지내고 있어?
정말 좋은 팁 입니다.
깊은 고찰과 이해가 느껴지는 짧막한 영상이네요
감사합니다
args 를 arguments 라고 안 읽고 철자 하나씩 읽길래 키자마자 껐다…
ㅋㅋㅋ 꺼주셔서 감사합니다
영어를 못하면 그럴수도 있죠
if ( this !== window) 이렇게밖에 타이핑을 할수가 없는데... 어떻게 하면 유투브에서 보여주시는데로 타이핑을할수가 있을까요?
혹시 폰트 말씀하시는거라면 요것이에요
github.com/tonsky/FiraCode
@@FERoy 감사합니다. 똑같이 해야 심신이 안정이 되려나봐요 ^^;;
Class는 c, c++언어 함수 명령어이므로 더 엄격하고 메모리도 관리할수있어 js에서도 c함수도 정확히 표현도 되나보네요. 참고로 전 잘하지못함.
IE를 그만쓰게 해야 저도 이런거 도입 좀 해볼텐데...안타깝네요..
babel부터 얼른 도입해보세요. 당장도 사용 가능하세요..
var, function을 20년을 써왔더니... 새로운게 낮설고 눈에 잘 안들어와서 안쓰게 되었는데.. 이제 좀 노력을 해봐야겠네요. 감사합니다.
혼자만 할거면 이래도 될거 같아요. 그런데 여럿이 하는 작업에서는 항상 보편적인 방식으로 해야합니다. 소스 코드는 누가 봐도 쉽게 이해되고 가독성이 좋은게 베스트라고 생각합니다.
'보편적인 방식'이란 어떤것이며, 그것은 변할 수 없는 절대명제일까요? 세상은 끊임없이 변하고 발전하고 있는데, 그 보편성의 원칙에만 얽매여 있다면 언제쯤 변화를 따라가는 것이 가능해질까요? 이런 부분도 함께 고려해 주시면 좋겠어요.
협업을 하는 모두가 함께 변화를 시도한다면 불가능한 것도 아니고 문제될 일도 없습니다. 가독성에 문제가 생기지도 않고요 :)
클래스로 해놨더니 당신 퇴사 할때까지 유지보수 할거냐 책임질거냐 해서 다 함수로 바까놓고 퇴사했습니다 아직 받아들이지 못하는 사람들이 많아요 금방 도태 되겠지만요 시간표는 다가오는것이 느껴집니다
ㅋㅋㅋㅋㅋㅋㅋㅋ 그냥 웃지요
😆
호이스팅 못 잃어! 하고 보았는데, 협업 부분에서 무릎을 탁 치고 갑니다...
function 키워드는 범용적이지만
정확한 동작을 위해 명확한 정의로 사용하자!
좋은 의견 감사합니다 🫰
이해하려면 아래 es6 공부부터 해야겠ㄴ..듀....ㅠ.
이해는 천천히 하셔도 됩니다!
와 댓글 읽다 보니 영상은 안 보고 제목만 읽고 무지성 반박하는 사람들 뭐죠ㄷㄷㄷㄷ
유튜브니까 제목이 좀 자극적일수록 클릭 수 늘어나고 결과적으로 더 많은 사람들이 유익한 영상을 보는 큰 그림을 그리신 걸로 이해했습니다ㅎㅎㅎ영상 올려주신 것만으로도 너무나 감사드리고 늘 응원합니다❤🎉😊
응원 감사합니다. 제목은 그냥 별생각 없이 저랬는데 이렇게 됐네요ㅠ ㅎㅎ
근데 노드로 서버개발할때는 function 쓸일이 많더라구오 ㅠㅠ
왜 그런가요? 안그러셔도 되는데..
서버쪽 패키지들 중에 콜백으로 this 써야하는 경우가 있어요
정확히 어떤 케이스인지 모르겠지만, 다른 프로퍼티에 원하시는 값을 할당해주는 경우도 있을 수 있으니 한 번쯤 확인해보셔도 좋을것 같아요.
생각나는게 mongoose 쪽 커스텀훅 작성할때 this 써야하긴 했어요
찾아봐도 마땅히 없을땐 어쩔수 없겠네요... 라이브러리들이 시대를 못쫓아오니;
김대리... 내가 감히 조언하고 싶은게 있읍니다.
자바스크립트 그 팡?션 아예 쓰지 마세요.
이 드립 참 많이 나오네요 ㅋㅋ
th-cam.com/video/5iGGvJn8K1U/w-d-xo.html
반대 의견도 들어보고 스스로 판단
일반 웹에서는 아직... ㅜㅡㅜ
'일반 웹'이란게 IE를 말씀하시는 걸까요? 그밖의 모던 웹브라우저에서는 모두 잘 지원합니다..
@@FERoy 공단 및 정부 홈페이지들이요
민원들어온다고 11을 버리지 못해요
바벨을 사용한다해도 유지보수 측에서 용납할지도 문제구요
IE11은 클래스 사용 가능해요. 바벨 없이도요. 물론 유지보수 측에서 용납할지 같은 현실적인 문제는 사정에 따라 다르겠지요 ㅠ
그냥 멍때리고 보다가 1분뒤자시고쳐앉음.
ㅋㅋㅋㅋㅋ
공부하는 영상에 어그로를 너무 세게 끄네
어그로 아닙니다
펑션위주로 사용한 사람으로써 이런거 보면 금방 적응은 하겠지만 새롭게 코딩하기엔 어려움이 따를거같아요
기존 펑션에 너무 익숙해진 탓이겠죠....
잘 봤습니다!!
this의 모호함에 하도 당해서... 아예 this자체를 안쓰게 되더군요. 제 안에서 this는 항상 달라지는 뭔지 모를 정체불명의 녀석이란 인식이 박혀버렸습니다. ㅡㅡ;;
감사합니다!
음 JS초보인데 초보가 볼 내용은아니군요
초보이시면 내용을 전부 이해하지 못하더라도 그냥 그렇구나 하는 마음으로 편하게 보셔도 충분히 도움이 되리라 생각해요.
감사합니다
오 내용이 너무 좋습니다. 비전공에 자바스크립트 완전 초보라 최근에 개발을 하게되면서 공부중입니다. 영상 내용의 30%정도 이해한 것 같아요. 근데 앞으로 개발을 위해 100% 이해하고 싶지만 배경지식이 너무 부족하네요!
조금더 쉬운 버전으로 다시 설명해주시면 저같은 초보에겐 더더욱 좋을것 같아요. 그럼 책사서 자바스트립트 기본지식좀 공부하러 가겠습니다
초보분들을 대상으로 한 컨텐츠는 이미 너무 많아서.. 저는 나름대로 차별화를 하려고 노력하고 있어요 ㅎㅎ
???: 아니, 팡션을 사용하지 말라니! 화살표 이상한. 거 눈에 잘 뵈지도 않는
야리꾸리한 기호나 쓰라고나 하고 말이야!
하여간 요즘 것들은 코드에 남을 생각하는 배려라는 게 없어!
🙂
재남형ㅎ
김대리 너무 엑셀 팡션? 사용 하지 마세요
어휴...
감사합니다
감사합니다