프론트엔드에서 리엑트로 취업하려면 뭐가 필요하다고 생각함?

[익명(122.43)]

처음 준비할 때는 그냥 문법알고 코드 짜서 기능 만들줄만 알면 되겠지 싶어서

html, css, js, react, 기타 라이브러리나 프레임워크로 간단간단한거 뭐 만드는 데에만 집중했는데,

나중에 피드백 받으니깐.

이제는 그냥 기술을 쓰는 데 그치지 않고

사용하는 이유랑 기술의 동작 원리까지 알고 있어야 한다네.

그래서 js의 동작 원리나 react 동작 원리 같은 것도 공부하고는 있는데, 이게 맞나 싶다.

[익명(211.209)]

동작원리를 알아야 하는 이유 : 리액트가 내맘대로 움직이지 않음. 리액트가 어떤 상황에서 특히 불리함. => 이럴 때 동작원리를 알면 검색키워드 잡기 편함.

[익명(211.209)]

꼭 알아야하냐? 흠.. 몰겠다. 이게 앱이 복잡해지면 복잡해질수록 그 필요성을 절실하게 느끼게 될거임.

[익명(211.209)]

만약 react의 동작원리를 아는것으로 어필을 하고 싶으면, 정말 필드테스트나 복잡한 상황에서의 테스트 많이해둬

[익명(122.43)]

차라리 맨땅 헤딩 메타로 내가 직접 복잡한 뭔가를 해보고 그 필요성을 느끼게 되면 좀 적극적으로 배울 수 있겠는데, 그런 거 잘 못 느끼겠는 상태에서 배우고 이걸 포폴에다가 거창하게 '내가 ㅈㄴ 고민한 끝에 이 라이브러리를 도입했다' 이런 식으로 적으려니까 좀 현타가 와서 글 적어 봤음.

[익명(122.43)]

필드 테스트를 프로젝트로 만들라는 건가. 흠...

[익명(211.209)]

라이브러리 왜 도입했고 어떤 장점이 있었고 어떤 한계를 느꼈는지는 포폴에다 안써도되고 블로그같은데가 쓰면됨.

[익명(211.209)]

그리고 실무자들도 이거 왜 도입했는지 모르는 경우 허다해. 자기들도 그냥 쓰니까 쓰는 경우 많음. 문제는 다음 프로젝트때 그렇게 안쓰기 위해서 뭘 느꼈는지 정리하는 태도가 중요한거지

[익명(211.209)]

근데 간단한 앱에서는 뭘쓰던지 상관이 없어. 다 가능하거든. 그러니까 최대한 기능도 복잡하고 상태도 복잡하고 데이터 양 많은 앱을 만들어보면서 리팩토링도 겪어보고 라이브러리의 불편함도 겪어보고 해야지 회고할게 생긴다는 의미야.

[익명(211.209)]

그러면 이제 아 이걸 왜쓰는구나라는걸 깨닫게 된다는거지. 그러면서 자연스럽게 동작원리를 파해치게 되는거고

[익명(122.43)]

만약 리엑트 포폴용으로 복잡한 거 하나 구현한다고 하면 좋은 소재로 떠오르는게 있을까?

[익명(211.209)]

한가지 팁을 주자면 보통 FE생태계는 어떤 문제를 해결하기 위해서 다른 솔루션들이 나오곤 하거든. 그러면 그 두가지를 비교해보면서 생각해보는거야. 1) 신규 솔루션을 써본다. 2) 신규 솔루션의 장점을 기존 솔루션에 적용할 수 있는지 찾아본다. 3) 그리고 그 두 솔루션을 비교해본다.

[익명(211.209)]

대표적으로는 상태관리 솔루션들이 있겠지 ReactQuery, Redux, Recoil, Jotai, 각 라이브러리에서 우리들은 이런걸 왜 만들었어요. 라는 부분들을 보고. 흠.. 그러면 저 기능들은 다른 곳에서 어떻게 구현할 수 있는지 왜 저 기능들을 셀링포인트로 넣어놨는지 비교해보는걸 해보면 좋아ㅣ

[익명(122.43)]

아 그러면 react랑 바닐라 js, vue 이런 식으로 비교하고 상태 관리 라이브러리끼리 비교하고 뭐 이런 건가.

[익명(211.209)]

일단 어떻게 프레임워크가 설정되어있는지 모르는것같으니까 잡아주자면.. vanlia.js 에서 MVC패턴으로 짜는것과 <-> React에서 Flux로 짜는것은 서로 대비되는 개념이야. 두가지를 해보고 뭐가 차이가 있는지 알아봐. vue.js는 좀 다른 느낌이야. 기존에 vanlia.js로 짜던 방식을 여러가지 장점을 뭉쳐서 쉽게 만들어놨다고 해야하나. 그래서 확실한 차이를 알고싶으면 React가 좋긴 해.

[익명(211.209)]

상태관리 라이브러리는 딱 1:1 비교가 불가능한데 기본 국밥 Redux, Redux-Toolkit <-> React-Query, Recoil, Zustand 후자에 있는 라이브러리들은 Redux에 있는것을 100%대체한다는 느낌보단 몇몇가지 기능만 뗴놓고 특수화 한 느낌이야. 그렇게 개발하는게 더 편해서

[익명(211.209)]

근데 나도 말하지만 나도 실무 3년차때야 꺠달은게 많아서 ㅋㅋㅋ 이걸 취준생한테 요구한다는게 뭐하네. 그냥 나도 알아가면서 내가 어떻게 저런 문제들을 잘 알았는지 팁을 공유한다고 생각하면 되고 꼭 할필요는 없어.

[익명(211.209)]

만약 내가 면접관이라면 취준생들한테 기대하는것은 1) 저런걸 알아보려는 태도 2) 저런걸 알아봐서 어떤 회고를 했을까 에대한 태도 정도 볼 것 같긴해.

[익명(122.43)]

일단... 난 간단한 문법만 익혀서 단순한 프로젝트만 만들었고 좀 복잡해진다 싶으면 유지보수 버리고 문제가 생긴다 싶으면 적당히 마무리했었는데, 댓글 보니까 솔루션 간의 장단점이나 이슈 해결 방식, 개발 패턴 같은 걸 이해하려면 동작 방식 이론도 찾아보고, 라이브러리 간 비교 글도 찾아보고, 다른 것보다 복잡한 프로젝트를 하나 만들어봐야겠구나 싶네 좋은 정보 고맙다 ㅠ

[익명(211.209)]

FE가 BE랑 달라서 힘든 부분이 있긴 허지 ㅋㅋ 아직도 취향을 좀 타는 부분도 있는것 같고 그래서 취준생 입장에서는 여러 포인트로 본인을 어필하기 쉬운 부분도 있는 것 같아. 화잍이해

[익명(58.142)]

ㄹㅇ 포폴에다가 내가 고민해서 뭘했다 이런거 적는거 존나현타옴 ㅋㅋ

[익명(122.43)]

???: 강사님이 이거 좋다고 해서 적었어요!

[익명(223.33)]

동작원리 아는거랑 모르는거랑 디버깅 할때 차이가 커서 그럼

[프갤러 1(175.203)]

그냥 리액트가 좆같이 작동해서 그래 리액트도 벌써 거의 10년차 틀딱 라이브러리임