vscode

본인 환경에 따라 단축키가 다를 수 있다. <code spellcheck="false">command + p</code> 를 치고 <code spellcheck="false">&gt; open keyboard shortcuts</code> 으로 keyboard shortcut에 설정되어 있는 내용을 참고하자.<hr>코드 접기 (fold)<code spellcheck="false">option + command + [</code>코드 펼치기 (unfold)<code spellcheck="false">option + command + ]</code>

[vscode] VSCode 능률 높여주는 단축키 (모으는 중...)

<h3>0. 16.8버전 이전의 함수 컴포넌트</h3>0.14 버전에서 소개된 함수 컴포넌트는 staless functional component, 이른바 무상태 함수 컴포넌트였다. 별도의 상태 없이 단순히 어떠한 요소를 정적으로 렌더링하는 것이 목적이었다.즉, 함수 컴포넌트는 클래스 컴포넌트에서 별다른 생명주기 메서드나 상태가 필요없이 render만 하는 경우에만 제한적으로 사용됐다. 함수 컴포넌트가 각광받기 시장한 것은 16.8버전에서 hook이 등장한 이우였다.함수 컴포넌트에서 hook이 등장한 이후 함수 컴포넌트에서 상태나 생명주기 메서드 비슷한 작업을 흉내낼 수 있게되자 상대적으로 보일러플레이트가 복잡한 클래스 컴포넌트보다 함수 컴포넌트를 많이 쓰기 시작했다.<h1>1. 클래스 컴포넌트</h1>기본적으로 클래스 컴포넌트를 만들려면 클래스를 선언하고, extends로 만들고 싶은 컴포넌트를 extends해야한다.<ul class="tight" data-tight="true"><li>React.Component</li><li>React.PureComponent</li></ul><pre spellcheck="false"><code class="language-jsx">// Component 제네릭에 props, state를 순서로 넣어준다.
class SampleComponent extends React.Component&lt;SampleProps, SampleState&gt;
</code></pre><ul><li>constructor(): 컴포넌트가 초기화되는 시점에 호출된다. 컴포넌트의 state를 초기화해주는 역할을 한다.</li><li>super(): 컴포넌트를 만들면서 상속받은 상위 컴포넌트에 접근할 수 있게 도와준다.</li><li>props: 함수 인자에 넣는 것과 비슷하게 컴포넌트에 특정 속성을 전달하는 용도로 쓰인다.</li><li>state: 클래스 컴포넌트 내부에서 관리하는 값을 의미한다. 값은 항상 객체여야만 하고, 해당 값에 변화가 있을 때 리렌더링이 발생한다.</li><li>method: 렌더링 함수 내부에서 사용되는 함수이며, 보통 DOM에서 발생하는 이벤트와 함꼐 사용된다.<ul><li>constructor에서 this를 바인드 하는 방법: 생성된 함수에 bind를 활용해 강제로 this를 바인딩해야 한다. (일반적인 함수로 메서드를 만든다면 this가 undefined로 나온다. 생성자가 아닌 일반 함수로 호출하게 되면 this 전역 객체가 바인딩 되기 때문이다.<pre spellcheck="false"><code class="language-jsx">this.handleClick = this.handleClick.bind(this)
</code></pre></li><li>화살표 함수를 쓰는 방법: 실행 시점이 아닌 작성 시점에 this가 상위 스코프로 결정되는 화살표 함수를 사용한다면 굳이 바인딩을 하지 않아도 된다.<pre spellcheck="false"><code class="language-jsx">const sampleFunction = () =&gt; {}
</code></pre></li><li>렌더링 함수 내부에서 함수를 새롭게 만들어 전달하는 방법: 메서드 내부에서 새롭게 함수를 만들어서 전달하는 방법이다.<pre spellcheck="false"><code class="language-jsx">&lt;button onClick={()=&gt; this.handleClick()}&gt;증가&lt;/button&gt;
</code></pre>그러나 이 방법을 사용하게 되면 매번 렌더링이 일어날 때마다 새로운 함수를 생성해서 할당하게 되므로 최적화를 수행하기 매우 어려워진다.</li></ul></li></ul><h2>클래스 컴포넌트의 생명주기 메서드</h2>클래스 컴포넌트를 사용하면서 가장 많이 언급되는 것이 바로 생명주기이다. 클래스 컴포넌트는 많은 코드가 생명주기 메서드에 의존하고 있다.생명주기 메서드가 샐행되는 시점은 크게 3가지로 나눌 수 있다.<ul class="tight" data-tight="true"><li>마운트(mount): 컴포넌트가 마운트(생성)되는 시점<ul class="tight" data-tight="true"><li>가상 돔에 붙는 순간</li></ul></li><li>업데이트(update): 이미 생성된 컴포넌트 내용이 변경(업데이트)되는 시점<ul class="tight" data-tight="true"><li>상태나 UI가 변경이 될 때</li></ul></li><li>언마운트(unmount): 컴포넌트가 더이상 존재하지 않는 시점<ul class="tight" data-tight="true"><li>컴포넌트가 사라질 때, DOM 트리가 빠질 때</li></ul></li></ul><h3>render()</h3>리액트 클래스 컴포넌ㅌ의 유일한 필수 값으로 항상 쓰인다.목적: 컴포넌트 UI를 렌더링 하기 위해서 쓰인다.실행 시점: 마운트와 업데이트 과정에서 일어난다.💡 한가지 주의해야 할 점은 render() 함수는 항상 순수해야 하며 부수 효과가 없어야 한다.<blockquote>부수 효과가 있으면 return 값이 변경될 수 있기 때문에 화면에 나오는 부분을 예측할 수 있도록 순수해야 한다.</blockquote>같은 입력값(props 또는 state)이 들어가면 항상 같은 결과물을 반환해야 한다는 뜻이다. 따라서 render() 내부에서 state를 직접 업데이트하는 this.setState를 호출해서는 안된다.state를 변경하는 일은 클래스 컴포넌트의 메서드나 다른 생명주기 메서드 내부에서 발생해야 한다. 그러므로 이 함수는 항상 최대한 간결하고, 깔끔하게 작성하는 것이 좋다.<h3>componentDidMount()</h3>클래스 컴포넌트가 마운트되고 준비가 됐다면 그 다음으로 호출되는 메서드가 바로 componentDidMount()이다.목적: render와 다르게 내부에서, state 값을 변경할 수 있기 때문에 UI를 업데이트 하기 위해 쓰인다.실행 시점: 컴포넌트가 마운드되고 준비되는 즉시 실행된다.💡 componentDidMount는 만능이 아니며 성능 문제를 일으킬 수 있음에 주의하자.일반적으로 state를 다루는 것은 생성자(constructor)에서 하는 것이 좋다. componentDidMount에서 this.setState를 허용하는 것은 다음과 같다.<ol class="tight" data-tight="true"><li>생성자 함수에서 할 수 없는 것</li><li>API 호출 후 업데이트</li><li>DOM에 의존적인 작업</li></ol><h3>componentDidUpdate()</h3>목적: 일반적으로 state나 props의 변화에 따라 DOM을 업데이트하는 등에 쓰인다.실행 시점: 컴포넌트 업데이트가 일어난 이후에 바로 실행된다.💡 그러나 적절한 조건문으로 감싸지 않는다면 this.setState가 계속해서 호출되는 일이 발생할 수 있다.<h3>componentWillUnmount()</h3>목적: 메모리 누수나 불필요한 작동을 막기 위한 클린업 함수를 호출하기 위한 최적의 메소드다.실행 시점: 컴포넌트가 언마운트되거나 더 이상 사용되지 않기 직전에 호출된다.이 메서드 내에서는 this.setState를 호출할 수 없다, 다음과 같은 상황에서 주로 사용한다.<ol class="tight" data-tight="true"><li>이벤트 제거 (window.removeEventListener)</li><li>API 호출을 취소</li><li>setInterval, setTimeout으로 생성된 타이머 제거</li></ol><h3>shouldComponentUpdate()</h3>목적: state나 props 변경으로 리액트 컴포넌트가 다시 리렌더링되는 것을 막고 싶을 때 사용한다.실행 시점: this.setState가 호출되면 리렌더링을 일으킨다. 그러나 해당 생명주기 메서드는 컴포넌트에 영향을 받지 않는 변화에 대해 정의할 수 있다.💡 일반적으로 state 변화에 따라 컴포넌트가 리렌더링 되는 것은 굉장히 자연스러운 일이므로, 해당 메서드를 사용하는 것은 성능 최적화 상황에서만 고려해야 한다.앞서 클래스 컴포넌트에는 두가지 유형, 즉 Component와 PureComponent가 있다. 이 둘의 차이점이 바로 해당 생명주기를 다루는데 있다.Component의 경우 버튼을 누르는 대로 즉 state가 업데이트되는 대로 렌더링이 일어나지만, PureComponent는 state의 값이 업데이트되지 않아서 렌더링이 일어나지 않았다. PureComponent는 state 값에 대해 얕은 비교를 수행해 결과가 다를 때만 렌더링을 수행한다.PureComponent는 먼저 얕은 비교만 수행하기 때문에, state가 객체와 같이 복잡한 구조의 데이터 변경은 갑지하지 못하기 때문에 개발자가 생각한대로 제대로 작동하지 않는다. 또한 애플리케이션에서 대다수의 컴포넌트가 PureComponent로 구성돼있다면 오히려 성능에 역효과를 미칠 수 있다.<blockquote>PureComponent의 경우 객체의 참조값이 바뀌어야 업데이트 된다, hook의 경우는 객체의 참조값을 갈아치운다.</blockquote><h3>지금까지 언급한 생명주기 메서드 정리</h3>렌더단계: virtualDOM에서 그려지는 과정커밋단계: 실제 브라우저에 반영하는 단계<h3>static getDerivedStateFromProps()</h3>이제는 사라진 componentWillreceiveProps를 대체할 수 있는 메서드다.실행 시점: render()를 호출하기 직전에 호출된다.static으로 되어 있어 this에 접근할 수 없다. 여기서 반환하는 객체는 해당 객체의 내용이 모든 state로 들어가게 된다.💡 명심해야 할 점은 해당 메서드도 마찬가지로 모든 redner() 실행 시에 호출된다는 점이다.<h3>getSnapShotBeforeUpdate()</h3>최근에 도입된 메서드중 하나로, componentWillUpdate()를 대체할 수 있는 메서드다.실행 시점: DOM이 업데이트되기 직전에 호출된다.다음과 같은 상황에서 주로 사용한다.<ol class="tight" data-tight="true"><li>렌더링되기 전에 윈도우 크기를 조절</li><li>스크롤 위치 조정</li></ol><h3>⭐&nbsp;getDerivedStateFromError()</h3>목적: 자식 컴포넌트에서 에러가 발생했을 때 렌더링 하기 위해 사용한다.실행 시점: 자식 컴포넌트에서 에러가 발생했을 때 호출된다.getDerivedStateFromError(error)를 인수로 받는다. 여기서 error는 하위 컴포넌트에서 발생한 에러를 말한다.💡 getDerivedStateFromError는 반드시 state 값을 반환해야 하며, 부수효과를 발생해서는 안된다.그 이유는 getDerivedStateFromError의 실행시점 때문이다. 자식 컴포넌트에서 에러가 발생했을 때 어떻게 렌더링할 지 결정하는 용도로 제공되기 때문에 반드시 미리 정의해둔 state 값을 반환해야 한다.또한 여기서 말하는 부수효과란 에러에 따른 상태 state를 반환하는 것 외의 모든 작업을 의미한다. (ex. console.error)<h3>⭐&nbsp;componentDidCatch()</h3>해당 3가지 메서드 getSnapShotBeforeUpdate, getDerivedStateFromError, componentDidCatch는 아직 리액트 훅으로 구현돼 있지 않기 때문에 이 3가지 메서드가 필요하다면 반드기 플래스 컴포넌트를 사용해야 한다.목적: 자식 컴포넌트에서 에러가 발생했을 때 렌더링 하기 위해 사용한다.실행 시점: 자식 컴포넌트에서 에러가 발생했을 때 호출된다, getDerivedStateFromError에서 에러를 잡고 state를 결정한 이후에 실행된다.componentDidCatch(error, 어떤 컴포넌트가 에러를 발생시켰는지 해당 컴포넌트의 정보를 가지고 있는 info)를 인자로 받는다.💡 componentDidCatch는 getDerivedStateFromError에서 하지 못했던 부수 효과를 수행할 수 있다.getDerivedStateFromError는 렌더 단계에서 실행되지만, componentDidCatch는 커밋단계에서 실행디기 때문이다.일반적으로 앞의 두 메서드는 ErrorBoundary, 즉 에러 경계 컴포넌트를 만들기위해 많이 사용된다. 그러나 모든 에러를 잡아낼 수 있는 것은 아니다. ErrorBoundary 외부에 있는 에러는 잡을 수 없다.이를 반대로 생각하여 ErrorBoundary를 여러 개 선언해서 컴포넌트 별로 에러 처리를 다르게 적용할 수 있다. 이렇게 하면 에러가 발생한 컴포넌트 트리 영역만 별도로 처리해서 애플리케이션 전체에 에러가 전파되어 표시되는 것을 방지할 수 있다.<blockquote>해당 메서드는 주로 에러 로깅할 때 사용한다. (GA, Centry) → 특정 컴포넌트에서 어떠한 에러가 발생했는지 알 수 있기 때문</blockquote><h2>클래스 컴포넌트의 한계</h2><ul class="tight" data-tight="true"><li>데이터 흐름을 추적하기 어렵다.<ul class="tight" data-tight="true"><li>데이터를 바꿀 수 있는 위치가 너무 많다.(DidUpdate, DidMount…)</li></ul></li><li>애플리케이션 내부 로직의 재사용이 어렵다.<ul class="tight" data-tight="true"><li>로직을 재사용하려면 HOC를 통해 해결이 가능하지만, 고차 컴포넌트를 많이 감싸게 되면 래퍼 지옥에 빠져들 위험성이 커진다.</li></ul></li><li>기능이 많아질수록 컴포넌트의 크기가 커진다.</li><li>클래스는 함수에 비해 상대적으로 어렵다.</li><li>코드 크기를 최적화하기 어렵다.<ul class="tight" data-tight="true"><li>번들 크기를 줄이는 게 어렵다.</li></ul></li><li>핫 리로딩을 하는 데 상대적으로 불리하다.</li></ul><blockquote>트리 쉐이킹 → 나무를 흔든다 → 나무에 걸려있는게 떨어진다</blockquote>중복선언된 로직을 호이스팅 하여 미사용된 함수/변수를 지운다. (메모리 낭비이기 때문)변수명을 바꿔준다 → 변수 명을 길게 한 것을 최소화하기 위해<blockquote>핫 리로딩 → 변경사항이 일어나면, 앱을 다시 시작하지 않고서도 해당 변경된 코드만 업데이트하여 변경 사항을 빠르게 적용하는 기법</blockquote><h2>함수 컴포넌트</h2><ol class="tight" data-tight="true"><li>render 내부에 필요한 함수를 선언할 때 this 바인딩을 조심할 필요가 없음</li><li>state는 객체각 아닌 각각의 원시값으로 관리되어 훨씬 사용하기 편하다.</li><li>렌더링하는 코드인 return에서 굳이 this를 사용하지 않아도 props와 state에 접근할 수 있게 됐다.</li></ol>

0. 16.8버전 이전의 함수 컴포넌트0.14 버전에서 소개된 함수 컴포넌트는 staless functional component, 이른바 무상태 함수 컴포넌트였다. 별도의 상태 없이 단순히 어떠한 요소를 정적으로 렌더링하는 것이 목적이었다.즉, 함수 컴포넌트는 클래스 컴포넌트에서 별다른 생명주기 메서드나 상태가 필요없이 render만 하는 경우에만 제한적

2-3. 클래스 컴포넌트와 함수 컴포넌트

<a target="_blank" rel="noopener noreferrer nofollow" href="https://blog.bytebytego.com/p/evolution-of-java-usage-at-netflix?publication_id=817132&amp;post_id=143071215&amp;isFreemail=true&amp;r=3lelmc&amp;triedRedirect=true">https://blog.bytebytego.com/p/evolution-of-java-usage-at-netflix?publication_id=817132&amp;post_id=143071215&amp;isFreemail=true&amp;r=3lelmc&amp;triedRedirect=true</a>netflix가 list of list of movies를 어떻게 해내었는지에 관한 시스템 구조입니다. netflix는 다양한 컴퓨터 환경에서도 비슷한 유저 경험을 위한 ui를 제공하고 싶었지만 microservices들로 이루어진 단일 backend에서는 한계를 느꼈기 때문에 다양한 환경에 맞는 BFF(Backend for frontend) 구조를 사용하여 필요한 성능에 맞는 backend 구조를 각각 구현하였고 거기서 gRPC나 REST api를 wrapping한 Client library를 호출하여 필요한 만큼의 데이터만 불러 올 수 있도록 성능을 개선하였습니다.<img src="https://image.until.blog/vitalemon/article/1718763839765" alt="until-553"><img src="https://image.until.blog/vitalemon/article/1718763844733" alt="until-554">

Netflix가 LOLOMO를 구현하였는지 발전 과정을 나타낸 글입니다.

Evolution of Java Usage of Netflix

Experience

안녕하세요! 2024 충북 게임잼을 다녀왔습니다! 저번 Myme 게임잼 이후로 새로운 목표가 생겨서 어떤 게임잼을 참가할까 고민하던차에, 충북게임잼을 한다는 소식을 들어, 참여하게 되었습니다. 사실 게임잼을 신청할때는 하면 좋겠다.. 싶다가도 신청자분들이 너무 많은걸 알기에 실망하지 않으려고 안되겠지 하면서 기다리고 있었는데, 너무 감사하게도 이번에도 불러주셔서 다녀왔습니다! 이번에는 저번보다 조금 더 험난한 여정이었습니다.<h3>강원도 속초에서 충청북도 청주까지.. </h3><hr>이번에는 강원도에서 충청북도까지 가야했던 여정이었습니다. 본가에서 쉬고있었던 사이에 게임잼 참여자로 선발되어버려서.. 도저히 강원도 속초에서 오전에 출발해, 오후까지 시간을 맞출 수 없을거라 생각해서 전날에 서울 도착하고 버스로 청주까지 이동할 계획을 짰습니다..<img src="https://image.until.blog/sin0105/article/1725443662417.jpeg" alt="until-1309"><img src="https://image.until.blog/sin0105/article/1725443668047.jpeg" alt="until-1310">동부창고가 어딘줄 몰라서.. 동부창고가 창고 갯수가 너무 많아서.. 길찾다가 조금 늦긴했지만 어찌됐든 도착은 했다..<h3>게임잼 분위기는 어땠나?</h3><hr>이번에는 여러가지 이슈가 있어서 조금 늦게 도착했는데, 공지 사항이랑 행사 진행중이었습니다. 처음 본 분들 중 집중하셔서 보는 분들도 있고 다음이 기획 발표 세션이라 뭔가 준비하시는 분들도 꽤나 보였습니다! 뭔가 Myme 때는 미리 팀을 주최측에서 빌딩이 이뤄진 이후에 실제로 만난거라 어색함이 덜하긴 했었는데, 충북게임잼은 와서 팀을 빌딩하는 방식이어서 완전 어색했습니다.. 쉬는 시간에 이곳저곳 돌아다녔는데, 주제가 캠핑인 만큼 1인 1텐트에서 잘 수 있도록 준비해주셔서 너무 좋았습니다. 프라이빗한 공간에서 신경안쓰고 편하게 조금이라도 잘 수 있다는 점이 너무 좋았어요. 리프레쉬를 위해 스위치도 준비해주시고, 간식과 굿즈도 신경써서 준비해주셨다는게 느껴져서 이것또한 감사했습니다. 스티커는 발견하자마자 노트북에 하나붙였습니다.. 게임잼 참가할때마다 하나씩 붙여두려구요.. 아! 맞다. Myme에서 만난분들과 BIC에서 만난분들도 인사해주셔서 너무 감사했습니다. 덕분에 어색함이 조금 사라질 수 있었어요. 감사합니다!<img src="https://image.until.blog/sin0105/article/1725446734725.jpeg" alt="until-1311"><img src="https://image.until.blog/sin0105/article/1725446758182.jpeg" alt="until-1312"><img src="https://image.until.blog/sin0105/article/1725446762625.jpeg" alt="until-1313"><h3>현장 팀 빌딩 진행 방식과 소감은?</h3><hr>팀 빌딩이 이루어지기 전에 미리 기획 포지션 분들께서 발표를 하였고, 마음에 드는 기획에 따라 프로그램, 아트 포지션이 기획자분들께 어필하는 방식으로 진행 했습니다6개의 기획 중에 3개 기획이 저한테 맞을거라 생각했습니다. 이 팀들을 위주로 물어보러 다녔고, 팀 빌딩이 정말 치열하다는 것을 느꼈습니다. 노션을 정리해서 어필하는 분들도 있었고, 아트스테이션으로 작업물을 직접 보이면서 어필하는 분들도 있었습니다. 저는 물어보러 다니면서 간단하게 제 이력만 이야기하고 고민해보고 알려주세요~ 하고 돌아다니던 찰나에 같이하자는 제안을 받아, 경쟁은 있었지만, 비교적 덜 치열했었던 것 같습니다.소감은.. 어필하러 다니는게 쑥쓰러워서 조금 힘들었습니다.<h3>빌딩은 완료, 어떤 프로젝트였나? </h3><hr>제가 속한 프로젝트는 '청화' 라는 이름의 프로젝트였고, 도트 기반의 2D 탑뷰 형식이고, 맵에 스폰된 아이템(재료)을 미니게임을 통해 얻어, 요리를 하여 관측소에서 별을 보러가며 더 높은 단계 음식의 레시피를 해금하는 게임입니다. <h3>게임잼을 진행하면서 기억나는건?</h3><hr>이번에도 역시나, 게임잼 진행하면서 사이사이에 많은 이벤트를 진행해주셨습니다. 간단한 퀴즈, 사진 공모 이벤트, 스위치를 활용한 이벤트 등을 진행해주셨어요.저는 다른건 잘 못해도 마리오카트는 몇번 해본경험이 있어서 참여했는데, 1등해서 상품을 받아왔습니다! 귀멸의 칼날 만화책 전권이라.. 받을때는 정말 좋았는데 이게 집에 들고 오기가 너무 힘들었어요.그리고 다른건 하나더 기억나긴 하는데, 타임라인 상 맨 뒤에 적어야할 것 같네요..아! 기억나는거, 샤워실 수압 엄청 셉니다. 얼굴 뚫리는줄 알았어요.<h3>1일차.. 2일차.. 그리고 3일차.. 결과는?</h3><hr>이번에는 Myme 때 같은 퍼포먼스에 대한 걱정은 역시 경험을 해보니 안들긴 했습니다. 버그픽스를 직전까지 수행하긴 했지만, 멘토분들의 도움으로 버그 없이 안정화된 빌드로 나와서 제출할 수 있었습니다.이번엔 심사를 같이 참여한 분들, 그리고 심사위원 분들의 점수를 정해진 비율로 나눠서 순위를 매기는 방식이었습니다. 결과는 이번에는 3위를 받았습니다! 처음에 이 프로젝트의 기획을 들었을 때, 무난하게 만들어진다면 In 3 가능할 것이다. 라고 생각했는데, 딱 제가 생각한 순위권에 안착한 프로젝트여서 너무 좋았습니다. 조금더 욕심이 있다면 2위까지 하면 좋겠다! 라고 생각은 했는데, 아쉽게 3위에 머무르게 되었네요.그래도, 수상권 안에 들어서 제가 생각한 성과를 이뤄낸거 같아 힘들게 온보람이 있었습니다!<img src="https://image.until.blog/sin0105/article/1725448269180.jpeg" alt="until-1314"><h3>생각한 성과도 이뤘고, 아쉬운 점은? </h3><hr>이번엔 아쉬운 점은 뭔가 수상을 해서 배부른 아쉬움일 수는 있겠는데, 수상 이후 뭔가 상장 같은게 없다는게 조금 아쉬웠습니다! 그거 외에는 기초적인건 너무 잘 준비되어 있었고, 개발하면서 아쉬운점은 없었던 것 같아요.<h3>2024 충북게임잼 리뷰를 마치며 마지막으로 할말은?</h3><hr>이번에도 역시 3일을 압축해서 쓰려니 엄청난 분량을 가진 페이지가 완성이 되어버렸네요. 여기까지 읽어주셨다면, 이번에도 재미없고, 두서없는 글을 참고 읽어주셔서 너무 감사드립니다!2일 걸려서 이동일정을 잡고, 이번에는 전보다 2시간 적게잔 3일간 4시간 수면이라는 역경과 고난을 거쳐 수상하여 새로운 제 목표인 '게임잼 도장깨기'를 할 수 있었습니다. 아직 경남, 충북만 도장을 깨서 경기, 경북, 전남, 전북, 서울 등 있다면 지역별로 아직 많이 남아있네요. 목표가 있다는 것은 뭔가를 하기에 정말 좋은 것 같습니다. 행사를 주최하여 뜻깊은 경험을 하게 해주신 충북 글로벌 게임센터, 한국인디게임협회 관계자 분들 및 참여하신 멘토분들, 서포터 분들, 모든 유관부서 관계자 분들, 저희가 쾌적하게 개발에 몰두할 수 있도록 도와주신 여사님까지 감사드립니다. 마지막으로, 모든 참가자 분들도 고생많으셨습니다! 같은 팀으로 출전해서 고생한 Team PixelJam 동료들 고생많았습니다!<h3>.. Luck..y Draw...?</h3><hr><img src="https://image.until.blog/sin0105/article/1725449197044.jpeg" alt="until-1315">이번에는 박스에서 뽑아서 구두로 말하셔서 사진은 못찍었는데.. 소니헤드폰.. 29번 축하드려요.. 부럽다<hr>게임잼 후기 시리즈 1. <a target="_blank" rel="noopener noreferrer nofollow" href="https://until.blog/@sin0105/2024-myme-%EA%B2%8C%EC%9E%84%EC%9E%BC-%EC%B0%B8%EA%B0%80-%ED%9B%84%EA%B8%B0">2024 Myme 게임잼 후기</a><a target="_blank" rel="noopener noreferrer nofollow" href="https://zdnet.co.kr/view/?no=20240903092516">기사1</a> <a target="_blank" rel="noopener noreferrer nofollow" href="https://www.khgames.co.kr/news/articleView.html?idxno=231720">기사2</a> <a target="_blank" rel="noopener noreferrer nofollow" href="https://gamefocus.co.kr/detail.php?number=158967">기사3</a>

1달만에 참여한 두번째 게임잼!

2024 충북게임잼 참가 후기

<h1>스니펫 설정하는 곳 찾아가기</h1><ol><li><code spellcheck="false">command + p</code> 로 파일 검색창 열기</li><li><code spellcheck="false">&gt;snippet</code> 입력하기</li></ol><img src="https://image.until.blog/dody/article/1722409042376" alt="until-1160"><ol start="3"><li><code spellcheck="false">Snippets: Configure User Snippets</code> 선택하기</li></ol><img src="https://image.until.blog/dody/article/1722409154676" alt="until-1161"><ol start="4"><li>스니펫을 사용할 환경을 선택해주면 된다. 나는 <code spellcheck="false">typescriptreact.json</code> 을 선택확인해보면 <code spellcheck="false">Print to console</code> 이름으로 된 예시가 있다. 그걸 참고해서 이제 나만의 스니펫을 만들어보자.</li></ol><h1>스니펫 생성하기</h1><pre spellcheck="false"><code class="language-json"> {

 "nextjs) functional component": {
 	"prefix": "rfc",
 	"body": [
 		"export default function ${TM_FILENAME_BASE}() {",
 " return &lt;div&gt; ${TM_FILENAME_BASE} component! &lt;/div&gt;",
 "}"
 	],
 	"description": "nextjs) functional component"
 }
}

</code></pre>아주 자주 사용하는 rfc 스니펫을 내 입맛에 맞게 살짝 고쳐주었다. 참고로 TM_FILENAME_BASE 는 확장자를 뺀 파일 명을 뜻한다.<h1></h1><h1>스니펫 동기화 해주기</h1>vscode는 기본적으로 스니펫은 로컬에 저장한다. 나는 2대의 맥북을 사용하기에 스니펫 설정을 동기화해주어 같은 일을 두번 하지 않으려 한다.vscode 계정에 로그인이 되어있어야한다. <ol><li><code spellcheck="false">command + p</code> 로 파일 검색창을 다시 열어주고</li><li><code spellcheck="false">&gt;setting sync</code> 를 입력한다</li></ol><img src="https://image.until.blog/dody/article/1722409917401" alt="until-1162"><ol start="3"><li><code spellcheck="false">Settings Sync: Backup and Sync Settings...</code> 을 선택</li></ol><img src="https://image.until.blog/dody/article/1722409929302" alt="until-1163"><ol start="4"><li>동기화 하고 싶은 부분들을 선택해서 <code spellcheck="false">sign in</code> 버튼을 눌러준다.</li></ol><img src="https://image.until.blog/dody/article/1722409940676" alt="until-1164"><ol start="5"><li>vscode 로그인한 계정을 선택해준다.</li><li>성공한다면 우측하단에 아래와 같은 메시지가 뜬다.</li></ol><img src="https://image.until.blog/dody/article/1722409975157" alt="until-1165"><ol start="7"><li>메시지가 뜨기 전에 conflict 가 났다고 메시지가 나왔다. 확인해보니 내가 방금 추가한 스니펫 부분이 다르다고 뜬것이었다. 컨플릭 처리 하고나면 6번과 같은 메시지가 뜰 것이다.</li></ol>

코드 치는 양을 최대한으로 줄이고싶다.. 

[vscode] snippet 만들어서 사용하기

<pre spellcheck="false"><code>"editor.codeActionsOnSave": {
 "source.organizeImports": "explicit"
 },</code></pre><code spellcheck="false">command + p</code> 로 파일 검색창 열고 <code spellcheck="false">&gt;</code> 를 입력한다.그러면 파일검색창에서 명령어팔렛트로 바뀌게 됩니다.settings.json 를 검색하면 아래 처럼 뜨는데<img src="https://image.until.blog/dody/article/1722219141216" alt="until-1153"><code spellcheck="false">Preferences: Open User Settings (JSON)</code> 을 누르면 json 파일을 열어, 맨 위에 적어놓은 코드를 추가하면 된다.

vscode 잘 써서 효율높이는 법 - import 자동 제거

[vscode] 사용하지 않는 import 자동 삭제 해줘

State of CSS 2024 설문이 시작되었습니다.<a target="_blank" rel="noopener noreferrer nofollow" href="https://survey.devographics.com/en-US/survey/state-of-css/2024">https://survey.devographics.com/en-US/survey/state-of-css/2024</a>설문은 11개 페이지에 총 소요 시간 약 20분~25분 정도 되는 것 같습니다.최신 기술항목들과 들어보지 못했던 기술들에 대한 정보와 사용사례 등을 엿볼 수 있는 좋은 기회가 되겠죠.설문을 진행하다보면,<img src="https://image.until.blog/ganymedian/article/1724427177172" alt="until-1266">설문항목 박스 우상단에 “+” 아이콘이 있습니다.자세히 알아보고 싶거나 흥미로운 항목일 때, 우상단 아이콘을 클릭하면 해당 기술항목이 차곡차곡 보관되고, 설문 종료시에 이를 모두 모아서 이메일로 받아볼 수 있습니다.이메일에는 모질라 재단의 공식문서 링크가 각각 포함되어 있습니다. 공부해야 할 기술 항목들을 이메일에서 하나씩 클릭해서 학습할 수 있겠죠...설문 결과 발표는 매우 늦습니다. 아예 궁금해 하지 않는 쪽이 정신건강에 이롭습니다.State of […] 설문조사에서는, 매년 일본인 개발자들은 눈에 뜨이지만 한국인 개발자의 참여는 목록에 보여지지도 않고 있는데, 이 점이 기분 안좋아요. 우리도 활발하게 참여해서 내년 부터는 Korean 이 리스트에 보여지면 좋겠다는 생각을 해봅니다...그리고, 설문 종료시에 무슨 의미인지는 잘 모르겠습니다만, 스코어가 뜹니다. 똬~악!!<img src="https://image.until.blog/ganymedian/article/1724427218896" alt="until-1267">상위 74% 라면.. 하위 27% 라는 거죠?? ㅋㅋㅋㅋ 기분 꿀꿀해지는군요.

State of CSS 2024 설문이 시작되었습니다.https://survey.devographics.com/en-US/survey/state-of-css/2024설문은 11개 페이지에 총 소요 시간 약 20분25분 정도 되는 것 같습니다.최신 기술항목들과 들어보지 못했던 기술들에 대한 정보와 사용사례 등을 엿볼 수 있는 좋은 기회가 되겠죠.설문을 진행하

State of CSS 2024 Survey

MakeGame

안녕하세요! 오늘은 이전 <a target="_blank" rel="noopener noreferrer nofollow" href="https://until.blog/@sin0105/%ED%8D%BC%EC%A6%90-%EA%B2%8C%EC%9E%84-%EC%A0%9C%EC%9E%91">아티클</a>에 이어서 작업 포스팅을 남겨보려합니다! 이번 포스팅엔, 아래 두 개만 완성하고 최종 결과물까지 올려보겠습니다! 1. 인접 구슬 파괴 로직 구현 2. 위에 연결된 구슬이 없을 경우, 이하 아래 모든 구슬 파괴로직 구현 ( 중력 )<h3>인접 구슬 파괴 로직 구현</h3>사실 탐색 로직으로는 여러가지 방법으로 구현할 수 있다고 생각하고 있습니다. 이런 게임의 경우는 주변 탐색을 먼저 하는게 효율적이라고 생각해서 저는 BFS 를 선택하여 구현했고, 당연하지만 DFS도 가능할 거에요. 이런 구슬을 레일 태우는 형식이 아니라, 미리 게임보드를 만들어서 베이스를 만들어둔 구조라면, 아래로 뻗어나가는 구조로 부모를 찾아가는 탐색 방식인 BST 등이 가능할 것으로 보입니다.사실 제일 먼저 생각난 부분은 모두 부모와 2개의 자식을 연결하는 BST 형식으로 생각했는데, 구현하려는 내용이 트리로 매핑하면 너무 컨트롤하기 어려워서 게임보드 안만들고 BFS 형식으로 진행했어요.먼저 BFS 의 개념은 이전에 포스팅한 내용이 있는데, <a target="_blank" rel="noopener noreferrer nofollow" href="https://sjh0105.tistory.com/186">링크</a>를 들어가보시면 간단하게 설명해두었습니다. 플로우는 다음과 같습니다. 1. 각 구슬의 타입을 RED, YELLOW, BLUE 로 설정 2. 내가 선택한 구슬의 GameObject 값을 기준으로 탐색할 버블의 리스트를 가져온다. 3. 내 주변의 버블을 큐에 담아두고, 내 기준 Position 에서 지름(r = 0.55f) + 오차(0.2f)내에 있는 버블들 중 내가 선택한 컬러 타입과 같은 버블은 파괴 예정 리스트에 넣는다. 4. 이렇게 파괴 예정 리스트가 최소 폭발 갯수 (3개) 이상이라면 파괴를 확정하고 파괴 시킨다. <img src="https://image.until.blog/sin0105/article/1723821556125" alt="until-1239">여기서 1,2,3 기준으로 파괴 예정 리스트에 넣을 거에요. 1,2,3 으로 해도 상관없고 1,3,2 로 터져도 상관은 없습니다. 어차피 지름 내 같은 컬러는 다터져야해서 다 탐색을 하긴 해야해요. 결과는 아래와 같습니다.<img src="https://image.until.blog/sin0105/article/1723821674354" alt="until-1240">의도한대로, 3개를 클릭 했을 때 잘 터지고 있네요.<h3>위에 연결된 구슬이 없을 경우, 이하 아래 모든 구슬 파괴로직 구현 ( 중력 )</h3>사실 이 부분을 만들면서 엄청 많이 고민했습니다. 이 부분 때문에 게임 보드판을 만들어서 트리처럼 만들어서 확인을 해야하나 싶기도했고, 터진 기준으로 윗 부분에 가로형 레이를 쏴서 없다면 중력 적용을 해서 파괴를 할까 싶기도 했습니다.여러가지 방법들이 있을 것이지만, 제가 만드는 스테이지는 일반적인 퍼즐버블의 스테이지랑은 조금 거리가 있어서 스폰을 담당하는 스포너 기준으로 상위부터 쭉 탐색을 진행하고, 탐색한 리스트에 없으면 연결된 버블이 없는 것으로 판단, 즉 떨어져 있는 부분으로 판단하여 파괴하는 로직을 작성하여 중력을 적용하였습니다. 구상도는 아래와 같습니다.<img src="https://image.until.blog/sin0105/article/1723822978054" alt="until-1241">그림판이라 이해가 어려울 수도 있는데, 설명해보면, 아래 주황색 그룹이 버블이 3개가 탐색되어 터집니다. 이 버블은 중력 탐색 이전에 파괴하고 넘어가야 이상한 연산이 진행되지 않아, 확실히 파괴하고 없는 상태에서 스포너의 우측 기준 Start 버블로부터 시작하여 탐색을 시작합니다. 왼쪽은 똑같아서 생략했는데, 왼쪽도 같이 시작해줍니다. 계속 탐색하게되면 결국 Pop Group이 비어있는 관계로 BFS Group 만 탐색이 됩니다. 이후에, 탐색된 버블에 존재하지 않을 시, 중력을 적용하여 파괴하도록 합니다. 터진 부분을 기준으로 탐색하는 이런 방법도 가능은 한것 같다고는 생각해요.<img src="https://image.until.blog/sin0105/article/1723823713788" alt="until-1243">설명을 해보자면, 터진 기준으로 큰 원을 만들어서 주변에 내부에 들어오는 버블을 가져와서 있는지 탐색하는 것 입니다. 당연하게도 아래는 중력을 같이 받는 입장이니까 UP 벡터와 방향벡터의 각도를 구하면 굳이 ArcCos 의 0 ~ 180 각도로도 좌측으로 가던, 우측으로 가던, 90도 이상(정확히는 우상단 좌상단 체크이기 때문에 50도 정도면 된다고 생각) 은 모두 필터링 해버리면 되니까 내적으로만해서 구하면 쉽게 필터링 될것 같네요. 단, 이렇게 탈락한 친구들은 파괴 예정 리스트에 넣어서 파괴할 준비를 해야합니다. 이게 전체의 버블을 탐색하여 리스트를 만들고 O(N^2) 의 시간복잡도를 갖는것보다는 훨씬 합리적이라고 생각합니다. 현재 게임에 적용된건 1번이긴 하지만 차차 다듬어가면 되겠네요.<h3>핵심 로직 끝, 결과는?</h3>퍼즐 버블 스타일의 게임을 간단하게 3일도 안되는 시간으로 타이트하게 구현을 해보았습니다. 이펙트도 달고, 배경도 바꿨는데, 나름 부족한 부분도 있지만, 시간대비 게임의 형태는 나온것 같아 만족스럽습니다.<img src="https://image.until.blog/sin0105/article/1723825023212" alt="until-1244"><img src="https://image.until.blog/sin0105/article/1723825032685" alt="until-1245">이렇게 이번엔 퍼즐게임 만들어 보았고, 긴 글 읽어주셔서 감사합니다!

퍼즐 버블 스타일 게임 제작 - 2

퍼즐 게임 제작 - 2

안녕하세요! 이런저런 게임을 구현해보기 위해 여러가지 연습해보고 있습니다. 만들어 볼 게임은 " 퍼즐 버블 " 스타일의 게임입니다.여러가지 로직이 생각나는데, 가장 중요한 핵심 로직들은 생각해보니 복잡하지 않았고, 몇가지 이론들만 알면 금방 뚝딱 만들어 낼 것 같아요.이와 비슷한 게임은 많은 것 같은데, 가장 대표적인건 역시 퍼즐 보블인 것 같습니다.<ul><li>장르 : 퍼즐, 전략, 슈팅</li><li>소요 시간 : 약 31시간<ol><li>1일차 8시간</li><li>2일차 12시간</li><li>3일차 11시간</li></ol></li><li>핵심 로직<ol><li>마우스,터치 포인터 각도로 발사</li><li>벽에 튕긴 후 궤적을 표현 ( 게임엔 1번 까지만 표현 )</li><li>구슬을 6각으로 구분하여 충돌 포인트 계산 ( 클론 생성 )</li><li>인접 구슬 파괴 로직 구현</li><li>위에 연결된 구슬이 없을 경우, 이하 아래 모든 구슬 파괴로직 구현 ( 중력 )</li></ol></li></ul>이 정도 5가지만 구현하면 될 것 같습니다. 1,2,3번은 금방 구할것 같고, 4번 로직이 BFS &amp; DFS, 그래프 이론 등으로 구할 수 있을 것 같네요. 5번은, 블럭단위로 섹션을 나눠서 구할 수 있는지 한번 체크해 봐야 할 것 같아요. 이번 아티클 에서는 1,2,3 까지 해볼 것 같습니다.<h3>마우스, 터치 포인터 각도로 발사</h3>마우스 클릭 지점을 기준 방향으로 구슬을 보내기 전 플로우를 설정했습니다. 1. 마우스 클릭 지점 중, 시작, 도착 지점을 자료구조로 가지고 있는다. 2. 방향벡터를 구해서 발사 한다.여기서 2가지로 구현 방식이 나뉜다고 생각합니다. 1. 구슬을 발사하여 충돌 시, Y 기준으로 반전하여 이동할 수 있게 버블에 기능을 준다. 2. 구슬이 이동할 라인을 모두 생성하고, 구슬을 정해진 라인으로 이동할 수 있게 한다.여기서 저는 버블은 단순히 날아가는 역할만 했으면 좋겠다고 생각해서, 2번으로 구현할 예정입니다. 그렇기 위해, IPointerDownHandler, IDragHandler,IPointerUpHandler 을 터치 패널에 모두 사용해서 구현할 것입니다. IPointerDownHandler : 입력의 시작점, 이때부터 라인은 계산 IDragHandler: 이미 입력은 되어 있지만 조금이라도 이동 시, 라인 갱신 IPointerUpHandler : 버블을 발사하는 입력, 터치 패널 클릭 ( 마우스 클릭 ) 을 떼면 호출됩니다.화면을 터치한 좌표를 월드행렬로 변환하여 Ray를 발사해서 TouchArea 에 맞은 지점을 계산 한 후, 버블의 시작점과 맞은 지점의 방향 벡터를 구해서 그 방향으로 발사해줍니다.<img src="https://image.until.blog/sin0105/article/1723749163115" alt="until-1230"><img src="https://image.until.blog/sin0105/article/1723749167959" alt="until-1231"><img src="https://image.until.blog/sin0105/article/1723750798991" alt="until-1234"><h3>벽에 튕긴 후 궤적을 표현</h3>벽에 튕긴 후 궤적을 표현하는 부분은 직선의 방정식으로 구할 수 있는데, ( Y = AX + B ) 사각형의 모든 직선의 방정식을 구하고, 설정한 방향 벡터로 나아가는 벡터의 직선의 방정식을 구합니다. 방향벡터 d = (dx,dy) 로 가정 (x,y) = (x0 + t*dx, y0 + t*dy) 로 설정합니다. t는 매개변수, t값이 증가할 수록 점이 벡터를 따라 변경.방향 벡터에 따른 직선의 방정식을 변의 직선 방정식으로 대입, t 산출 t 를 이용해 x,y 계산. 교점 좌표를 구합니다. 각 교점 좌표들이 사각형 위에 존재하는지, 끝점들 사이에 존재하는지 확인한 후 , t &gt; 0 인 좌표를 구한 후, 가장 작은 t 값을 가지는 교점을 선택, 이 값이 가장 마지막까지 사각형 위에 있는 점 ( 즉, 외부로 나가는 첫번째 좌표 ) 입니다.<img src="https://image.until.blog/sin0105/article/1723750851023" alt="until-1235"><h3>구슬을 6각으로 구분하여 충돌 포인트 계산 ( 클론 생성 )</h3>보통 이런 퍼즐 버블 스타일의 게임에선 구슬의 예상 도착 지점을 찍어줍니다. 그것을 구현하기 위해서는 대략적인 삼각함수 개념이 필요한데, 크게 어렵지는 않고, 저는 초기에 아래 그림처럼 생각해서 구현했습니다.<img src="https://image.until.blog/sin0105/article/1723751045475" alt="until-1236">좌측, 우측에 방향레이가 도달했을때는 각각 좌,우 만큼 띄운 뒤 클론 생성, 좌하, 우하 일때는 좌측 아래, 오른쪽 아래에 생성합니다. Right 벡터를 기준으로 -315 ~ 45 우측 45 ~ 135 위( 필터, 필요 X ) 135 ~ 225 (좌측) 225 ~ 270 (좌하) 270 ~ 315 (우하) 로 각도를 설정했습니다. 구하는 방법은 아래와 같습니다. 1. 발사대의 좌표와, 레이를 맞은 지점의 좌표의 방향 벡터를 구하고, 버블의 회전은 변경되지 않는다는 가정하에, Right 벡터를 기준으로 잡고 내적합니다. 2. 내적의 공식은 a · b = |a||b| Cosθ 입니다. |a||b|를 넘겨주면 아래와 같은 공식이 나옵니다. Cosθ = a · b / |a||b|, 여기에서 각도를 구하기 위해, ArcCosθ(cosTheta) 값을 넣으면 각도를 받습니다. 3. ArcCos의 값 표현 범위는 0 ~ 180 도 이기 때문에, 전체 360를 표현하기엔 무리가 있습니다. 그렇기 때문에, 외적을 사용하여, 플레이어 기준 좌우측을 판단하는 것 처럼 Vector3.Cross(Right,dir) 로 새롭게 생성되는 벡터가 Y 양수일지, Y 음수일지 체크하여 360 - Degree 를 할지 Degree를 볼지 결정하여 정확한 각도를 받을 수 있습니다. 4. 그렇게 각도를 결정하면 미리 지정해둔 크기와 위치좌표를 연산하여 클론의 자리를 잡아줍니다.<img src="https://image.until.blog/sin0105/article/1723752097842" alt="until-1237">나머지는 아티클 2부에서 작성하겠습니다. 1부 개념만 사용하는데에도 생각한것보단 상당수 수학적 개념이 들어가네요. 2부 개념은 수학적 개념보단 인접 구슬 파괴 로직 구현, 위에 연결된 구슬이 없을 경우, 이하 아래 모든 구슬 파괴로직 구현 ( 중력 ) 을 구현하기 때문에, 알고리즘적 요소를 많이 설명할 것 같습니다.

퍼즐 게임 제작

<a target="_blank" rel="noopener noreferrer nofollow" href="https://2023.stateofjs.com/">https://2023.stateofjs.com/</a> State of JS 2023 Survey&nbsp;발표가 나왔습니다.State of JS/ CSS 는,매년 전 세계의 개발자들에게 직접 설문 조사를 받아서 이를 취합, 발표하는 공신력 있는 조사에요.1년 단위 조사이고 발표는 이듬해 봄, 여름에 하는데...&nbsp;발표가 좀 늦는게 단점이지만, 개발 쪽 트랜드는 가장 뚜렷하게 볼 수 있는 조사입니다.이번 발표는 그제? 쯤 나온 것 같습니다.이번 발표에서는 Vite 와 Bun 이 가장 많은 항목들에서 높은 스코어를 받았군요 .그런데, 제게 는 Jest 가 가장 눈에 뜨였네요.생각보다 많은 사람들이 테스트 코드를 쓰고 있다는 사실에 놀랐고,,&nbsp;음.. 분발해야겠다는 생각이 들었습니다.Vercel 의 약진도 눈에 뜨입니다. 음...&nbsp;그리고 올해 처음 추가된 설문항목 인 것 같은데... AI assistant 항목도 흥미롭습니다.AI 는 1개월 단위로 판도가 바뀌는데 1년만의 발표라니, 좀 박물관 기록같은 느낌도 있네요.ㅎㅎ시간 될 때 한번 들러 보시는 것도 좋겠습니다.관심 있으신 분들에겐 재밌는 시간이 될 것 같네요 .-Fin-

https://2023.stateofjs.com/State of JS 2023 Survey&nbsp;발표가 나왔습니다.State of JS/ CSS 는,매년 전 세계의 개발자들에게 직접 설문 조사를 받아서 이를 취합, 발표하는 공신력 있는 조사에요.1년 단위 조사이고 발표는 이듬해 봄, 여름에 하는데...&nbsp;발표가 좀 늦는게 단점이지만, 개발 쪽 트

State of JS 2023 Survey

<h3>1. <code spellcheck="false">npm run dev</code>를 하는 이유</h3><ul class="tight" data-tight="true"><li><code spellcheck="false">npm run dev</code>는 개발 환경에서 프로젝트를 실행하는 명령어입니다.</li><li>이 명령어를 실행하면 개발 서버가 실행되며, 소스 코드 변경 시 실시간으로 페이지가 새로고침되는 핫 모듈 교체(Hot Module Replacement) 기능이 활성화됩니다.</li><li>이를 통해 개발자는 빠르게 코드를 작성하고 테스트할 수 있습니다.</li></ul><h3>2. <code spellcheck="false">npm run build</code>와의 차이</h3><ul class="tight" data-tight="true"><li><code spellcheck="false">npm run build</code>는 프로덕션 환경을 위한 최적화된 빌드를 생성하는 명령어입니다.</li><li>이 명령어를 실행하면 JavaScript, CSS 등의 자산 파일이 압축되고 최적화되어 프로덕션 환경에 배포할 수 있는 버전이 생성됩니다.</li><li>반면 <code spellcheck="false">npm run dev</code>는 개발 환경에 최적화되어 있어 소스 맵 생성, 핫 모듈 교체 등의 기능이 활성화됩니다.</li></ul><h3>3. <code spellcheck="false">npm run dev</code>를 하지 않으면 Laravel 페이지가 이상하게 보이는 이유</h3><ul class="tight" data-tight="true"><li>Laravel 프로젝트에서 Vite를 사용하는 경우, <code spellcheck="false">npm run dev</code> 명령어는 Vite 개발 서버를 실행하여 자산 파일(CSS, JavaScript 등)을 실시간으로 컴파일하고 제공합니다.</li><li><code spellcheck="false">npm run dev</code>를 실행하지 않으면 Vite가 자산 파일을 컴파일하지 않아 페이지에 스타일이나 동작이 제대로 적용되지 않습니다.</li><li>따라서 Laravel 프로젝트에서 Vite를 사용하는 경우, <code spellcheck="false">npm run dev</code> 명령어를 실행하여 개발 서버를 실행해야 합니다.</li></ul>요약하면, <code spellcheck="false">npm run dev</code>는 개발 환경에서 프로젝트를 실행하고 실시간 변경 사항을 반영하는 데 사용되며, <code spellcheck="false">npm run build</code>는 프로덕션 환경을 위한 최적화된 빌드를 생성하는 데 사용됩니다. Laravel 프로젝트에서 Vite를 사용하는 경우, <code spellcheck="false">npm run dev</code>를 실행하지 않으면 자산 파일이 제대로 컴파일되지 않아 페이지가 이상하게 보일 수 있습니다.

1. npm run dev를 하는 이유npm run dev는 개발 환경에서 프로젝트를 실행하는 명령어입니다.이 명령어를 실행하면 개발 서버가 실행되며, 소스 코드 변경 시 실시간으로 페이지가 새로고침되는 핫 모듈 교체(Hot Module Replacement) 기능이 활성화됩니다.이를 통해 개발자는 빠르게 코드를 작성하고 테스트할 수 있습니다.2. npm 

`npm run dev`와 `npm run build`

State of React 2023 Survey 결과가 발표되었습니다.<a target="_blank" rel="noopener noreferrer nofollow" href="https://2023.stateofreact.com/en-US/">https://2023.stateofreact.com/en-US/</a>지난 달에 발표됐던 State of JS 를 진행한 기관과 같은 곳에서 진행하는 Survey 죠.형제 격인 Survey 들이 몇가지 있습니다. JS/ CSS/ HTML/ React/ ...React 개발자들이 이 조사 발표를 기다리는 건, 기술동향에 대한 궁금함도 있겠지만,"어떤" 기술을 사용할 것인지를 결정하는데 중요한 자료가 된다는 것이죠.러닝커브가 도사리고 있는 기술인데, 애써 배워놨더니 쓸모 없어지는 경험은 누구에게나 악몽이 될 수 있으니까요..그런 의미에서, 제 채널에서 진행하고 있는 강좌에서 선택한 기술들이 대체로 높은 스코어를 받고 있다는 건 흡족한 일이네요.개인적으로는 Zustand 가 급상승하기를 기대했지만 이번 결과에서는 그렇지 못했습니다. Zustand 가 관심을 받기 시작한 건 얼마 안됐으니까요.. 그리고 이 조사 발표는 정말 늦습니다.그리고 ' 가장 고통스러웠던 API' 설문에서는 forwardRef 와 memo 가 나란히 선두에 뽑혔군요.React 19 에서는 forwardRef 가 없어질 것이라는 이야기도 돌았죠. 컴파일러가 도입되면 memo 도 설 자리를 잃게 될 테고... 이제 HOC 는 서서히 소멸되어가는 기술이 될 것 같습니다.관심있는 분들에게는 매우 의미있는 시간이 될 것입니다.

State of React 2023 Survey 결과가 발표되었습니다.https://2023.stateofreact.com/en-US/지난 달에 발표됐던 State of JS 를 진행한 기관과 같은 곳에서 진행하는 Survey 죠.형제 격인 Survey 들이 몇가지 있습니다. JS/ CSS/ HTML/ React/ ...React 개발자들이 이 조사 발표를