[질문 내용] 준영속 상태와 비영속 상태의 차이점에 대해 이해한바는 다음과 같습니다. 비영속 상태 : 한번도 엔티티 매니저의 관리를 받아본적 없는 엔티티 준영속 상태 : 엔티티 매니저의 관리를 받다가 연결을 끊음으로써 더이상 관리 받지 않고있는 상태. 제가 아는 차이점은 이것 뿐인데 혹시나 이게 두 상태의 차이점의 전부라면 굳이 상태를 나눌 필요가 있나? 라는 생각이듭니다. 그냥 '준영속 상태' 라는 단계를 없애고 연결이 끊기면 비영속 상태 로 , 다시 연결을 맺으면 영속 상태 로 이렇게 단계를 줄여도 되지 않을까요? 혹시나 제가 모르거나 잘못이해하고 있는점이 있다면 알려주시면 감사드리겠습니다!!
섹션 13의 본문 파트는 잘 따라 갔는데 혼자 freeboard에 진행하려 하니 계속 오류가 나네요.. 답변주신대로 설치 명령어의 오타를 수정해서 yarn add -D @graphql-codegen/typescript로 한 뒤 yarn generate를 실행하니 type.ts 이 안생기고 error Command failed with exit code 127. 라는 에러가 발생하네요ㅠㅠ 설치 파트에서 계속 막히니 힘드네요.. 확인 한번 해주실 수 있으실까요?
안녕하세요 과제 중 궁금한 점이 있어 질문 남깁니다 pages - index 파일 export default function DetailBoardPage(): JSX.Element { return ( <> <DetailBoard></DetailBoard> <CommentWrite></CommentWrite> <CommentList></CommentList> </> ); } board list presenter 파일 export default function CommentListItemUI( props: ICommentListItemUI ): JSX.Element { // 수정 아이콘 클릭 시 수정 화면으로 전환 const [isEdit, setIsEdit] = useState(false); const onClickUpdateIcon = (): void => { setIsEdit(true); return ( <> {!isEdit && ( . . . )} {isEdit && ( <CommentWrite item={props.item} isEdit={true} setIsEdit={setIsEdit} ></CommentWrite> )} </> ); } CommentWrite 컴포넌트를 두 곳에서 사용하고 있습니다 1번에서는 아무런 props 인자를 넘겨주지 않고 있고요 2번에서는 3가지 props 인자를 넘겨주고 있습니다 types 파일 export interface ICommentWrite { item?: IBoardComment; isEdit?: boolean; setIsEdit?: Dispatch<SetStateAction<boolean>>; } 이에 맞춰 작성한 interface 입니다 setIsEdit state에 ? 기호를 붙이니 CommentWrite 파일(바로 아래 파일)의 props.setIsEdit state 사용 구간에서 '정의되지 않음'일 수 있는 개체를 호출할 수 없다는 오류가 뜹니다 export default function CommentWrite(props: ICommentWrite): JSX.Element { const onClickUpdate = async (): Promise<void> => { . . . props.setIsEdit(false); }; const onClickCancel = (): void => { props.setIsEdit(false); }; return ( . . . ); } 찾아보니 undefined / null 값을 제대로 다루지 못할 때 생기는 오류라고 하는데요 해당 state는 한 곳에서만 props 인자로 전달하고 있기 때문에 undefined 값이 나오는 경우가 필연적입니다 이런 경우 해결할 수 있는 방법이 있을까요? 만약 타입 지정과 관련된 방법으로 해결할 수 없는 문제라면 props 인자를 한 곳에서만 받도록 파일을 합칠까 합니다
상품등록 페이지를 cypress 를 통해 test 해보던 도중 kakao map 을 사용해 주소입력 하는 부분에서 문제가 발생하고 있습니다. 개발자 도구를 사용해서 kakao map 의 input 의 class 확인해 해당 class name 으로 get()요청을 했지만 인식을 못하고 있습니다
FAIL __test__/test/index.test.ts ● Test suite failed to run ReferenceError: TextEncoder is not defined 1 | // 하드코딩된 미니 백엔드 > 2 | import { graphql } from "msw"; | ^ 다음과 같은 에러가 뜨는 이유가 뭘까요? 찾아보니 node 18을 사용하지 않아 발생하는 문제라는데 node -v 을 확인해보면 제대로 18버전을 이용하고 있습니다
학습하는 분들께 도움이 되고, 더 좋은 답변을 드릴 수 있도록 질문전에 다음을 꼭 확인해주세요. 1. 강의 내용과 관련된 질문을 남겨주세요. 2. 인프런의 질문 게시판과 자주 하는 질문(링크)을 먼저 확인해주세요. (자주 하는 질문 링크: https://bit.ly/3fX6ygx) 3. 질문 잘하기 메뉴얼(링크)을 먼저 읽어주세요. (질문 잘하기 메뉴얼 링크: https://bit.ly/2UfeqCG) 질문 시에는 위 내용은 삭제하고 다음 내용을 남겨주세요. ========================================= [질문 템플릿] 1. 강의 내용과 관련된 질문인가요? (예/아니오) 2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예/아니오) 3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예/아니오) [질문 내용] 안녕하세요. 간단한 내용이지만 조금 고민이 있어서 질문드립니다. 요청을 통해서 받은 데이터를 통해서나 로직상에서 연관관계에 필요한 Entity의 id값을 알고 있는 경우 필요한 Entity를 DB에서 조회하는 과정 없이 id값만 초기화된 Entity를 생성하여 주입하는 방식이 가능한 것으로 알고 있습니다. 이 때, 그렇게 주입된 Entity는 persist된 상태가 아니라는 점인데요. ( cascade 옵션이 적용 안 되었다는 가정 ) 이런 경우에 두 가지 경우의 수를 고려하였습니다. 첫 번째는 연관관계 Entity가 연관관계 설정 외에는 사용될 일이 없는 로직의 경우이고 두 번째는 연관관계에 필요한 Entity가 이후에도 여러 로직에서 사용되는 경우입니다. 두 번째의 경우에는 사실 고민할 것 없이 ID를 이용해 Entity를 생성하는 것이 아닌 SELECT를 통해서 Entity를 조회하여 사용하는 것이 좋은 방법이고 EntityGraph를 맞추는 면에서도 당연히 해주어야 하는 것으로 사료됩니다. 하지만 첫 번째의 경우 굳이 Entity를 ID값을 통해 조회하는 과정이 필요한 지에 대한 의문입니다. 저런 단순한 로직의 경우 굳이 DB와의 정합성을 위해 조회 및 연관관계 편의메소드 등을 이용해서 EntityGraph를 맞춰줄 필요가 있나 싶었습니다. 이런 경우에서 실제 현업에서는 어떤식으로 처리하는 지 궁금합니다. 저렇게 각 상황에 따라 효율을 따져서 다르게 처리하는 지 아니면 ID를 통해 데이터를 조회하는 것은 크게 성능상 문제가 되지 않으니 불필요하더라도 로직의 통일성이나 혹시 모를 사이드 이펙트를 대비해서 조회한 뒤 연관관계 편의 메소드를 통해 EntityGraph까지 맞춰 주는 지 궁금합니다..! 저는 불필요하다고 생각하여 굳이 Entity그래프를 맞춰줄 필요가 없는 경우는 그런 과정을 생략하며 프로젝트를 하고 있었는데, 완성하고 보니 EntityGraph를 맞춰 주는 로직이 단 하나도 없는 걸 알게 되었습니다. 아무래도 복잡한 비즈니스 로직이 없어서 그럴 수도 있겠다는 생각은 들었지만 너무 심한 것 같아 제가 JPA를 제대로 쓰고 있는 게 맞나 싶어 질문드립니다..ㅠㅠ
수업에서 async await를 쓰게 되면, await 뒤쪽 함수가 실행 된 후, await를 보자마자 어? 오래걸리겟네? 하면서 스레드가 해당 async함수를 통째로 마이크로큐에 넣어버린다고 말씀하셨는데요. 만약 await뒤의 함수가 Promise를 반환하게 되면, 해당 Promise를 반환하는 함수가 먼저 큐에 쌓이고, 그 뒤에 async함수가 들어가서 pipo구조에 따라, promise가 반환된 후 async함수가 실행되면서 기다리는것처럼 보인다고 말해주셨습니다. 근데... 이 말 대로라면, await 함수 뒤에 굳이 Promise가 올 필요가 있나요? XMLHttpRequest()가 오더라도, 콜스택에서 해당요청이 실행된 후, 결과값을 가진 상태에서 마이크로큐로 들어가니까, 똑같이 await가 되는게 아닌지요? 분명 순차적으로 수업을 들으면서 다 이해햇다고 생각햇는데 갑자기 헷갈립니다.
Cookie 값을 삭제 하며 여러 동작을 해보던 도중, 로그인을 하기 전부터 JSSESSIONID 값이 cookie 에 들어가 있는 것을 확인하였습니다. 처음에는 오류인가 싶어 값을 삭제하고 로그인하였더니, 로그인이 동작하지 않고 그냥 페이지가 reload 된 다음 임의의 JSSESSIONID 값을 가져왔습니다. 왜 reload 할 때마다 JSSESSIONID 값을 가져오는 걸까요? 그리고 왜 JSSESSIONID 값 없이는 로그인 동작 자체가 안 되는 걸까요?
선생님, 안녕하세요. 너무 기초적인 질문일 수 있지만, 갑자기 궁금해져서 질문드립니다. 서버사이드 렌더링의 경우, 서버에서 pre-render된 코드를 만들어서 보내주고, 클라이언트에서 hydrate를 해서 페이지를 만든다고 알고 있습니다. 클라이언트 사이드 렌더링의 경우는 html코드와 js코드를 함께 보내서, 클라이언트에서 페이지를 만들구요. 서버사이드 렌더링을 할 때, pre-render된 코드를 만드는 서버는 각 클라이언트들의 컴퓨팅 자원을 사용하는 건지(클라이언트의 컴퓨터에서 만드는 건지), 아니면 배포하는 중앙(?)서버(aws ec2 또는 이 강의에서 처럼 vercel)의 컴퓨팅 자원을 사용하는 건지(서버에서 만드는 건지) 궁금합니다. 클라이언트 측에서 다 계산을 한다고 하면, 중앙(?)서버의 부담이 적을테지만, 중앙(?)서버에서 한다고 하면, 부담이 갈 수 있을 것 같아서요. 최근 next.js 14버전이 되면서 디비와 직접 통신하는 등 기능이 많이 생겼는데, 이 통신하는 등의 역할은 client side가 아닌 server side에서만 가능하더라구요. 그래서 server side라는 게 중앙서버 하나에만 있다면, 계산이 오래걸린다거나 트래픽이 늘어나거나 한다면 다른 사용자들에게도 영향을 끼치지 않을까 궁금했습니다.(자동 확장이 되지 않을때) 또, 이런식으로 간다면 따로 백엔드 서버가 필요없게 될 수도 있겠다라고도 생각해봤는데, 어떻게 보고계시는지도 궁금합니다.