안녕하세요 좋은 강의 잘 듣고 있습니다 undo 기능을 따라 구현하던 중 이슈가 있어 질문 드립니다 pen mode로 그린 뒤 eraser mode에서 일부 지움 -> undo 실행 -> 화면이 모두 지워집니다 원인은 eraser mode에서 mousedown 시 ctx.globalCompositeOperation = 'destination-out' 로 바뀐 상태가 유지된 채 restore() 내부에서 drawImage() 가 실행되기 때문인 것 같은데요, 제로초님이라면 eraser mode 종료 시점 ( mouseup )에서 source-over 로 되돌리는 방식이랑 restore 에서 source-over 로 바꾼 뒤 drawImage() 하는 것 또는 제 3의 장소?? 어떤 곳에 작업하실지 여쭙고 싶습니다
안녕하세요, 제로초님. 프론트엔드 문서화 관련하여 질문을 드릴 게 있습니다. 저희 회사에서 단기간에 규모가 큰 프로젝트를 진행하다보니 AI의 도움을 빌려 만들기는 만들었는데 문서화가 제대로 되지 않은 상태입니다. 최근 한 명의 백엔드 개발자가 프론트엔드도 함께 개발을 하게 되어 문서화의 필요성을 느끼고 있는데, 문서화에 대한 경험이 없어 제로초님께 여쭤봅니다. 현재 폴더 구조는 FSD를 채택하여 개발 중입니다. 구상중인 것은 Slice 단마다 문서를 만드려고 하는데, 해당 Slice에 포함된 파일의 사용 방식(API input값, output 값 등)에 대해 작성하고, store(zustand)에 저장된 값을 적고, ui에서 필요한 정보값들에 대해서도 적어보려고 합니다. 이렇게 모든 폴더에 정리하게 된다면 못해도 50개가 넘는 문서가 만들어지게 될텐데, 괜찮은 방법인지 확신하지 못하겠네요.(현재 회사에 있는 개발자분들은 딱히 관심이 없어보이십니다ㅠ) 제로초님이라면 해당 문서에 어떤 내용을 담으실지 궁금합니다. 그리고 프로젝트 전체를 소개하는 문서에는 Tech Stack, 프로젝트 구조 이외에 어떤 항목을 넣는 것이 좋을지도 궁금합니다. 이 수업에서 배운 디자인패턴에 대해서도 작성하는 것이 좋을까요?
디자인 패턴을 공부하면서 실제 구현중인 서비스에 적용해보려고 노력중인데(위 이미지는 예시 코드) 예시 처럼 작성했을 때의 실효성이 invoker에서 audit log 같은 공통 코드 추출하는것 이외에 잘 느껴지지 않는데, 적절하지 않은 부분에 적용하려해서 그런것일까요? -> 단축키 예시처럼 해당 커맨드를 다른곳에서'도' 사용한다면 유용할것도 같네요!! 추가로 ValidateLeadFieldCommand, CreateLeadCommand 이런식으로 여러 커맨드가 순차로 실행해야하는 경우에 invoker도 커맨드마다 만들어야할까?하는 고민도 듭니다!
강의 내용과는 무관하지만 평소에 고민하던 점이 있어 문의드려 봅니다 평소에 type/interface 정의를 어디 둘지 고민하는 경우가 많은데요 d.ts를 만들어 타입끼리 묶어둠 각자 가장 관련도 높은 파일에 둠 제로초님은 강의 예제 정도 규모의 프로젝트에서 어떻게 하시는지 궁금합니다 저는 타입이 먼게 싫어서 2번을 선호하는데 '관련도 높다'는 기준이 주관적이어서 위치를 명확히 잡기 어렵고, 개발이 진행되며 관련도가 바뀌는 경우도 생기더라고요
예제에서 팩토리 메서드를 굳이 왜 써야 하는지 이해를 하지 못했습니다 심플 팩토리 예제에서 grimpanFactory라는 함수의 존재 이유가 서로 다른 생성자들을 묶어주려는 요구사항이 있기 때문으로 이해했는데요 이 요구사항에 따르면 AbstractFactory들을 만들어주더라도 결국 이들을 묶어주는 로직이 필요하고 여전히 if else가 불가피한게 아닌가 생각됩니다 정리하면 애초에 grimpanFactory라는 함수를 만든게 type만으로 서로 다른 클래스 인스턴스를 편리하게 생성하는게 요구사항이 있어서가 아닌지 (1번이 맞다면) AbstractFactory를 만들더라도 이 요구사항을 만족하려면 어딘가엔 if else가 와야할 것 같은데 잘못 이해한 것인지 (1번이 틀리다면) 묶어주는게 요구사항이 아니라면 애초에 AbstractFactory 없이 생성자 바로 호출하면 되는게 아닌지
안녕하세요, React 환경에서 다음 강의를 보며 예제연습중인 수강생입니다. 먼저, 함수형 컴포넌트가 주류가 된 현대 React 생태계에서도 클래스형 디자인 패턴이 많이 활용되는지 궁금합니다. 특히 싱글톤, 팩토리, 빌더와 같은 클래스 기반 디자인 패턴들이 여전히 실무에서 많이 사용되고 있는지 알고 싶습니다. 또한 이러한 클래스 기반의 디자인 패턴 사용 시, React의 재렌더링 측면에서 성능 이슈가 발생하지는 않는지, 실제 개발 경험에서 어떤 장단점이 있는지 궁금합니다.
안녕하세요 싱글턴 강의 내용 중 매개변수로 빼거나 클래스라면 this를 사용하면 된다. 면 된다 하셨는데 this를 아래 코드처럼 운용 하는건 말하는 걸까요?? class Singleton<T> { private static instance: Singleton<any>; protected data: T; protected constructor(data: T) { this.data = data; } public static getInstance<T>(data: T): Singleton<T> { if (!this.instance) { this.instance = new this(data); } return this.instance; } public getData(): T { return this.data; } } export default Singleton; 감사합니다!!
git commit 으로 공유된 State 패턴 완성본 커밋 에서 강의 마지막 부분 (23:50) 과 달라서 해당 부분을 사용하시는 분들은 정상으로 동작하지 않을 수 있습니다. 그래서 해당 공유합니다. 강의 시작 부분 23:50 코드 export class ChromeGrimpanMenu extends GrimpanMenu { onClickPen() { const command = new PenSelectCommand(this.grimpan); this.executeCommand(command); // { name: 'pen' }; // this.grimpan.setMode('pen'); // 변경, 해당 부분은 강의에도 나와있지는 않지만 pen 모드일때 변경이안되어서 자체적으로 추가함 this.grimpan.history.stack.push(command); } onClickEraser() { // this.executeCommand(new EraserSelectCommand(this.grimpan)); // { name: 'eraser' }; // 기존 this.grimpan.setMode('eraser'); // 변경 } onClickCircle() { // this.executeCommand(new CircleSelectCommand(this.grimpan)); // { name: 'eraser' }; this.grimpan.setMode('circle'); // 변경 } onClickRectangle() { // this.executeCommand(new RectangleSelectCommand(this.grimpan)); // { name: 'eraser' }; this.grimpan.setMode('rectangle'); // 변경 } onClickPipette() { // this.executeCommand(new PipetteSelectCommand(this.grimpan)); // { name: 'eraser' }; this.grimpan.setMode('pipette'); // 변경 }
심플 팩토리에서 chrome, safari 등등 if문을 통해서 브라우저환경에 맞는 그림판 인스턴스를 가져올 수 있도록 한 코드가 있었는데, 팩토리 메서드가 그 역할을 대신한다고 이해했습니다. 궁금한점은 결국 크롬이든 사파리든 브라우저환경을 알아내서 main함수에 넘겨줄 수 있어야하는데 그 분기는 어디서 해야하는걸까요? function clientCode(creator: Creator) { creator.someOperation() } clientCode(new ConcreteCreator1()) 아래의 코드라면 new ConcreteCreator1()를 판단할 수 있는 조건 분기를 결국 어디서는 해야하지 않는가에 대한 고민입니다!
class Parents { // 좁은 파라미터 method(name: string, test: string) { // 넓은 반환 타입 return { key: "" }; } } class Child extends Parents { // 넓은 파라미터 override method(name: string) { // 좁은 반환 타입 return { key: "", name: "" }; } } 안녕하세요, 리스코프 치환원칙을 보니 반,공변성의 원칙과 같이 매개변수는 반공변성을 리턴은 공변성을 가지는 것 같은데, T<child> -> T<parents> 개념이 되는 타입의 정의 원칙을 리스코프 치환 원칙이라 하는 것일까요?
안녕하세요! 강의 열심히 따라가고 있습니다 :) 제가 중간에 놓친 부분이 있는지, canvas.context.transform 으로 scrollHeight에 따라서 canvas 사이즈 조절 시에 일분이가 커지면서 뒤에 글씨를 가리고 있는데, 어떤 부분을 놓쳤을까요 ? 뭔가 css 일 것 같은데, css를 잘 몰라서 어떤 부분을 봐야할지모르겠습니다 ㅠㅠ ps. 사용중인 디스플레이가 지금 높이 1440px 인데요, 1080px보다 작은 화면에서는 정상적으로 표시되는것을 보아하니.. canvasScaleRatio가 1보다 클 경우에 문제가 되는 것 같아보입니다 :) transform 적용해제 (개발자도구로 제거) transform 적용후
