질문은 아닌데..챌린지 미션에 질문하기가 있어서 쓰니까 신경쓰지 말아주세요... Link Share 공유 url은 components/Post.tsx에 있음 공식문서: share 부분 확인 ios에서는 url을 같이 넣어주면 좋고, 안드로이드에서는 title을 넣어주면 좋음 File Share expo-sharing 라이브러리 설치 후 사용 폰에 있는 파일을 다른 앱에 공유 가능 다른 앱에서 내 expo앱으로 공유하고 싶을 때 expo기본지원x Expo Share Extension이라는 외부 라이브러리를 따로 설치해서 사용해야 함 근데 npm run prebuild를 해야하는데, 이럼 expo-go에서 벗어나 native단을 건듦 한번 설치하면 못돌아옴
안녕하세요, geek님. 영상 16:55~ 부분에서 설명해주시는 conflict를 해결할 수 있는 방법에 대해서 다음 네 가지를 설명해주셨습니다. main 브랜치 쪽 diff를 더한다. test 브랜치 쪽 diff를 더한다. (선택됨) 둘 다 더한다. 둘 다 더하지 않고, 아예 다른 내용을 적는다. 그리고 예제에서는 2번 방식을 선택해주셨고, 이에 따라서 머지 커밋은 다음과 같이 계산됩니다. base( red ) + main 최신 커밋과의 diff( green ) + test 최신 커밋과의 diff( blue ) 즉, 3개가 더해져서 만들어지는 커밋인데요. 이로 인해 3-way merge라는 이름으로 불린다고 이해했습니다. 여기서 질문이 생기는데요. 만약 1번 방식을 선택한다면, 머지 커밋이 다음과 같이 계산됩니다. base( red ) + main 최신 커밋과의 diff( green ) 즉, 2개가 더해져서 커밋이 만들어집니다. 그런데 앞서 말씀하신 내용을 고려하면 머지의 세부 명칭(예를 들어 3-way merge같은)에 영향을 주는 요소는 '커밋 히스토리의 모양'입니다. 따라서 2개가 더해져서 커밋이 만들어지는 이 상황도 여전히 3-way merge라고 부를 수 있습니다. 그래서 처음 들었던 의문은 "1번 방식을 택했을 때는 2개가 더해지는 건데, 이때도 3-way라고 부르는 것은 그냥 관례적인 표현인가?" 입니다. 그리고 질문을 작성하면서 제가 스스로 내린 답변은 "더하는 개수가 3개여야 하는 것이 아니고, 더할지 말지 고민하는 기준점이 3개 인 상황이라 3-way라는 이름이 붙은 것 같다" 입니다. 즉, 커밋 히스토리가 예제와 같은 상황에서는 다음 3가지 를 기준점으로 사용하게 됩니다. 두 브랜치의 공통 부모 (base) main 브랜치의 최종 커밋 test 브랜치의 최종 커밋 각 기준점에 대해 어떤 판단을 내리느냐에 따라 세 개를 더하는 2번 상황이 되거나 두 개를 더하는 1번 상황이 되거나, 또 다른 3번, 4번 상황이 될 수도 있습니다. 하지만 '기준점이 3개'라는 사실을 모든 상황에서 동일하기 때문에 3-way merge라는 이름이 붙여진 것으로 판단했습니다. 가르쳐주신 내용에 혼란을 느낀 부분을 서술하느라 글이 좀 길어졌는데, 결론적으로 '기준점이 3개라서 3-way merge라고 부른다'는 제 판단이 적절한지 여쭤보고 싶습니다.
혹시 ios나 android 네이티브 빌드해서 연동하는 방법도 해당 강의에서 진행하나요? 현재 25강을 듣고 있긴 한데... 들으면 들을수록 네이티브쪽도 건들어야하는 것 같아서 질문드립니다! 혹시나 해당 강의가 포함되어있으면 몇 강인지 말씀주실 수 있으신가요? 또... 스위프트, 코틀린 말고 자바나 오브젝티브씨도 같이 알아야하나요?
안녕하세요, 현재 Vue 2.0을 사용하고 있으며, React로 이직을 하고자 해당 강사님의 강의를 수강하고있습니다. 혹시 현업에서도 해당 도구를 많이 사용하는지 빈도가 궁금합니다. Vue를 사용하면서는 그러지아니하다보니 이것을 알고있는게 좋은지 파악이 안된다보니 쌩뚱한 질문을 드려 죄송합니다.
안녕하세요, 강의 잘 듣고 있습니다. Git을 정리하는 데 큰 도움을 받고 있습니다. 다름이 아니라 GitHub에서 브랜치를 메인 브랜치로 병합할 때 사용하는 전략에 대해 궁금합니다. 기본 병합(merge), 스쿼시 & 머지(squash & merge), 리베이스 & 머지(rebase & merge) 방식이 있는데, 어떤 방식을 선호하시는지 여쭤보고 싶습니다. 개인적으로는 로컬에서 작업할 때는 리베이스 & 머지 를 선호합니다. 히스토리를 깔끔하게 유지할 수 있기 때문입니다. 반면에 메인 계열 브랜치(dev, prod 등)로 병합할 때는 기본 병합 을 사용해야 기능 추가 히스토리를 명확히 추적할 수 있다고 생각합니다.
강의를 듣고 실무에 어떻게 적용해볼수 있을까 생각하다보니 궁금한 점들이 있어서 질문 남깁니다! 규모가 큰 기업들에서는 Storybook을 어떤 구조로 관리하고 있나요? 소규모 팀에서는 "프로젝트 내부 세팅 후 나중에 분리" vs "처음부터 모노레포" 중 뭐가 더 현실적일까요? (초기 비용 vs 장기 유지보수 고려)
Next.js 완벽 마스터 (v15): 노션 기반 개발자 블로그 만들기 (with 커서AI)
프로젝트 개발 중에, src/components 폴더에 재사용할 것들을 만들어서 사용하는 것과, src/app/_components 를 사용하는 것을 배웠는데, 둘의 사용성 차이가 있나요? 굳이 이 두 기능을 둘 다 사용을 할 필요가 있을까요? 오히려 하나만 사용하는게 좋지 않나 싶었습니다. 반드시 분리를 해야만 하는 특별한 이유가 있어서 굳이 분리를 하게 되는 것일까요?
Supabase, Next 풀 스택 시작하기 (feat. 슈파베이스 OAuth, nextjs 14)
안녕하세요 리액트나 NextJS는 익숙하지 않아 질문드립니다. 파이썬을 쓸때는 가상환경을 만들어서 프로젝트 마다 관리를 하는데 NextJS는 각 프로젝트 폴더마다 관리가 되나요? 이것저것 하다가 실수하면 다 지우고 처음부터 다시 하는편이라서 파이썬 가상환경이 너무 마음에 들었는데 혹시 NextJS도 가능한가 궁금합니다. 잘 모르기 때문에 실수해서 패키지가 엉망이 된 경우가 많아서 걱정부터 되네요. 다들 기본적으로 잘하셔서 그런가 보통 강의를 들을때 이런 부분은 잘 안물어보시나봐요.
안녕하세요! 강의 너무 잘 듣고 있습니다. 제가 이번에 git을 처음 써보면서 이것저것 시도해보고 있는데요! git pull merge 요청을 보낼 때 분명 한번에 merge를 시도 했는데 draft라고 남는 경우가 있더라구요! 혹시 이건 제가 요청을 제대로 보내지 않아서 생기는 걸까요?
안녕하세요! JWT 구현 중 verify_token 함수의 네이밍이 궁금합니다. app/core/jwt_handler.py def verify_token(token: str) -> int: payload = decode_token(token) return payload.get("uid") verify라는 이름은 보통 boolean을 반환할 것 같은데, 실제로는 uid(int)를 반환하고 있어서 조금 헷갈립니다. get_uid_from_token이나 extract_user_id 같은 이름이 더 명확하지 않을까요? 감사합니다!
안녕하세요. CSS 라이브러리에 대한 비교 설명까지 너무 감사합니다. 앞으로 AI Agent 를 활용한 코딩을 고려하고 있습니다. 이런 경우 더욱 적합한 CSS 라이브러리를 추천해 주실 수 있을까요? 예를 들어 저는 현재 Cursor AI를 이용하고 있습니다. 좋은 강의 감사합니다.
안녕하세요, 개인적으로 궁금한 게 있어서 질문드립니다. 요즘 React Router를 보면 SSR 프로젝트를 위한 프레임워크가 나오는 등, 서버 사이드 렌더링 환경을 지원하는 방향으로 발전하고 있는 것 같더라고요. 그래서 문득 궁금해졌는데, 요즘 시장에서는 CSR 방식의 수요가 많이 줄어드는 추세인가요? 아니면 여전히 CSR 중심의 프로젝트도 많은 편인가요? 현재는 CSR 기반으로 개발하고 있는데, 앞으로의 흐름을 생각하면 SSR 관련 기술도 공부해야 할지 고민 중입니다. 현업에서 체감하시는 부분이나 조언을 듣고 싶습니다
