허.. 프론트엔드 분야에 갈길이 한참 멀군요 ㅠㅠ

저는 신입으로 몇군데 넣었는데 아직 연락도 없어요 유유

2,3번 좋은 답 좀 알 수 있을까요? 궁금합니다.!

켁 //

그냥 리액트 공식문서의 리액트로 사고하기 부분 보시고 렌더링할 컴포넌트가 엄청 많아져서 공식에서 주장하는 방식을 지키지 못할 경우 어떻게 될까를 한번 고민해보시는게 좋을거 같습니다. 그런 내용이였어요.

 공통 컴포넌트에서 자식 컴포넌트에 props방식으로 ui데이터를 바인딩 하는데 그 자식이 엄청 많아지면 그 리소스를 어떻게 관리할건가 정도? 그게 다 부모에 있을테니 spa 방식 입장에선 당연히 모바일 고려해서 모달로 관리하기에 부모가 관리하는게 맞는건데 팝업창으로 띄우는 입장에선 그걸 부모가 가지고 있으면 쓸데 없는 성능을 잡아먹는다는 내용입니다.(사실 그런 상황을 상상해본적이 없어요. 모달창이면 어차피 다 부모가 가지니까요. 그런 상황에서 나름 대안들 고민해보긴 했는데 개인적인 판단이라 ㅎㅎ)

그건 결국 databind를 통한 ui렌더링 을 어떻게 할건가와 그 리소스가 비대 해질 경우 그 리소스 자체가 가지는 트래픽을 어떻게 관리 할까인데 그 정도 규모로 생각해본적은 딱히 없어서 아직도 솔직히 그게 성능에 이슈가 될지 잘모르겠습니다.(복잡한 컴포넌트 100개 불러올때 어느 정도 성능 이슈가 발생하는지 궁금하긴합니다.)

면접에선 성능에 영향을 주는 상황을 가정하시더군요. 

세상넓네요 1~4번 다 이해를 못하겠어요 ㅠㅠ

1번은 개인적인 고정관념이라 의미없고

2번 3번은 데이터플로우에 대한 고민 + 리액트의 한계 를 고민하는 부분이에요.

4번은 그냥 프론트엔드에서 왜 oop가 아닌 fp방향으로 가는가 라는 트렌드 변화에 대한 맹목적인 추종이 아니라 명확한 이유들이 있었는가? 라는 내용인데

트랜드만 따라간다고 깊이 고민해보지는 않았어요. 뷰는 단순히 보이는데 치중하기에 따로 상태 값을 가져서 사이드 이펙트를 일으킬 필요가 없다는..그런 디자인 패턴적인 결론인데 확신을 가지고 남을 설득 할 정도는 아니죠.

아무튼..이부분은 저도 나중에 꼭 알아야하는 내용이기 때문에..

스크랩 해놓을게요 감사합니다.

내일 면접이나 신경써야지

//

오 내일두 면접있으신가보네요 제가 과거에 이직할때랑은 다르시게 면접 자주있으신가봐요,

꼭 잘되시면 좋겠어요

아무리 세상이 넓어도그렇지 이렇게 잘하시는분을 안뽑아간다니 ㅡㅡ;

덕담 고마워요. 진지하기 보다는 이 놈은 뭐하는 놈인지 그냥 신기해서 만나나 보자는 사람들이 많은거같아요. 저도 면접하면서 경험쌓고 나쁘진 않은거같네요.

에구

redux 팬으로써 위의 답변이 다 가능하지만 일단 패스할께요.

일다 redux라는 개념으로 보면 oop보다 functional에 가깝죠.

저도 면접에서는 스토어 개념을 말하긴 했는데 아직 제대로 이해했다고 보기힘들어서 ㅎㅎ 궁금하네요. 나중에 여유되시면 관련 글좀 써주세요.

홧팅하시구 좋은 소식있으시길 바랄게요!!

글구 혹시 시간과 여유가 되신다면 프론트앤드 면접후기 다음에도 부탁드립니닷....ㅎㅎ