걱정이 가득했던, 부담이 가득했던 2번째 미니프로젝트가 끝이 났다.
다같이 섞였던 첫 주의 미니프로젝트와 다르게 각자의 자리에서 각자의 것을 했다.
🐱💻Note
공만 따라다니던 우루루 축구에서 공격수와 수비수로
뷰를 짜며 Flask로 api를 만들어 붙이던 때 보다 체계적으로 진행되었다.
협업 해보기
아이디어. 기획. 설계. 디자인. 코딩. 공유. 설명. 격려. 으쌰으쌰.
하루의 이야기를 받고 저녁에 나의 이야기를 작성해서 저장하는 서비스.
새벽에도 근무를 해왔기에 하루 초기화는 새벽 5시에 일어날 수 있도록 양해를 구했다.
한 주 돌이켜본다는 마음으로 진행했다.
심화 주차에서 잠깐 사용했던 typed.js를 메인 페이지에 담아냈다.
미니 프로젝트 보러가기 서버가 꺼져있다
깃허브 보러가기
🐱💻Note
말하지 않으면 몰라
안전을 위해서 발전해온 CRM이지만 어디서나 소통보다 중요한 것은 없다.
API 설계할 땐 분명 변수명... 서버 꺼진줄도 모르고 붙잡고 있었잖아요...
혹시 데이터베이스 초기화 했어요..? 첫 협업은 어려웠다.
모자랐던 부분..
#0. 소통, 주장, 설득
- 로컬 환경에선 잘 되던 것들이 배포 후 크고 작은 문제가 많았다.
- 이유는 명확했다. 로그인 정보를 서버 세션에서 참조할 수 없다는 것.
- 근데 설명할 지혜가 없었다. 주장도 설득도 할 수 없었다.
TODO
- 대화와 이해를 위해서 백엔드 공부도 병행해보자.
➡다음 기회엔 제대로 이야기 나눠보기. 더 나은 나로.
#1. 이게 정말 리엑트?
- 반복되는 선언, 반복되는 컴포넌트 작성.
- 코드 복사해서 가져와서 사용하기.
- 모듈화를 위해 리엑트를 시작했는데 이게 맞나? 회의감이 들었다.
TODO
- 핵심적인 컴포넌트(레고 블록들) 정리 후 import해서 사용하기.
- 폴더 인덱싱 더 잘 설계하기. (1주차보다는 5672만배 나아짐)
➡다음 기회엔 제대로 적용해보기. 더 나은 나로.
#2. 도르마무!
JWT
를 사용하지 못했던 이번 미니 프로젝트.- 로그인시 서버로부터 회원정보를 받아서
Session
에 저장.- 페이지 분기 설정을 위해 일기 작성 여부를
true false
로 추가 저장.false
로 저장한 값이 불러올 땐"false"
로 반환."false"==true
- 분기오류에 1시간 고생 후 확인해서야..... 오잉..?
Session
은 문자열로만 저장한다.해결방안
0-1.
- 반사적인 콘솔찍기
➡ 컴퓨터에게 명령하기 전에 대화를 나눠볼 필요가 있다.0-2.
- 👍 Session에 담을 데이터 JSON화 해서 담은 후 해제하여 사용하기.
➡ 자료형이 유지되어 사용할 수 있다.
➡다음 기회엔 제대로 적용해보기. 더 나은 나로.
회원가입시 기입한 생일로부터 데이터베이스에 starposition이라는 값을 등록.
로그인 시 유저 정보로 받아와 세션에 저장.
각 띠와 별자리에 맞는 화면을 제공하는 부분이다.
쥐띠 물병자리 유저에겐 아래와같이 제공한다. 마우스를 올리면 강조된다.
별자리 12개 12지신 12마리, 총 24개의 이미지 파일을 public
폴더에 지니고 있었다.
세션에서 가져온 starposition
에 따라 보여주는 이미지를 설정해준다.
React.useEffect(() => {
setTimeout(() => {
try {
switch (starposition) {
case "AQUARIUS": {
botImage.current.src =
process.env.PUBLIC_URL + "/imges/stella_01.png";
return;
}
case "PISCES": {
botImage.current.src =
process.env.PUBLIC_URL + "/imges/stella_02.png";
return;
}
case "ARIES": {
botImage.current.src =
process.env.PUBLIC_URL + "/imges/stella_03.png";
return;
}
case "TAURUS": {
botImage.current.src =
process.env.PUBLIC_URL + "/imges/stella_04.png";
return;
}
case "GEMINI": {
botImage.current.src =
process.env.PUBLIC_URL + "/imges/stella_05.png";
return;
}
case "CANOER": {
botImage.current.src =
process.env.PUBLIC_URL + "/imges/stella_06.png";
return;
}
case "LEO": {
botImage.current.src =
process.env.PUBLIC_URL + "/imges/stella_07.png";
return;
}
case "VIRGO": {
botImage.current.src =
process.env.PUBLIC_URL + "/imges/stella_08.png";
return;
}
case "LIBRA": {
botImage.current.src =
process.env.PUBLIC_URL + "/imges/stella_09.png";
return;
}
case "SCORPIUS": {
botImage.current.src =
process.env.PUBLIC_URL + "/imges/stella_10.png";
return;
}
case "SAGITTARIUS": {
botImage.current.src =
process.env.PUBLIC_URL + "/imges/stella_11.png";
return;
}
case "CAPRICORNUS": {
botImage.current.src =
process.env.PUBLIC_URL + "/imges/stella_12.png";
return;
}
default:
return;
}
} catch {}
}, 200);
}, []);
하지만 사실 코드 길이의 문제가 아니었다.
바로 public으로 배포된 이미지가 사용된다는 점이었다.
총 24개 + @의 사진으로 3MB의 양이었다.
index.html
에 접속 하는 유저들은 3MB를 다운 받아야 하는 셈이다.
리엑트는 HTML파일이 하나밖에 없으니 그 악효과가 배가 되었다.
이미 일기를 작성하여 /select
페이지에 접근하지 않아도 받아야만 했다.
그래서? Firebase Storage에 올렸다.
const stars = [
"AQUARIUS", "PISCES", "ARIES", "TAURUS",
"GEMINI", "CANOER", "LEO", "VIRGO",
"LIBRA", "SCORPIUS", "SAGITTARIUS", "CAPRICORNUS",
];
stars.map( async(val, idx) => {
idx = idx + 1 + "";
idx = idx.split("").length == 1 ? 0 + idx : idx;
console.log(idx);
let tmpPost= {
imageURL: '',
imageName: `stars/stella_${idx}`,
imageTitle: val,
}
let ImagesRef = ref(storage, `stars/stella_${idx}.png`);
await getDownloadURL(ImagesRef).then((url) => {
tmpPost.imageURL = url;
});
console.log(tmpPost)
await setDoc(doc(db, "stars", val), tmpPost);
});
그렇게 스토리지에는 24개의 이미지 파일이.
파이어스토어 db에는 24개의 url 주소가 담겨졌다.
세션에서 가져온 starposition
에 따라 db에서 url을 가져와 보여주는 이미지를 설정해준다.
단 두줄로 해결되었다.
try {
let ImgInfo = await getDoc(doc(db, "stars", starposition));
botImage.current.src = ImgInfo.data().imageURL
} catch {}
뿌듯함 반, 의아함 반.
최초 로딩은 별로 체감되지 않았다.
하지만 /select
페이지에서 사진을 db로부터 불러오느라 느려진게 확실해졌다.
이렇게 하는게 맞나? 과연 잘 한게 맞을까?
3MB가 그렇게 큰가?
처음엔 자연을 생각했지만 오히려 db가 유지되는데 발생하는 이산화탄소는?
어려웠다. 지혜가 부족했다.
파일 정리가 많이 부족하다.
컴포넌트명 작명도 부족하다.
함수 작명은 그나마 늘었다.
스타일 정리도 개판이다.
리팩토링을 할 감이 잡히질 않는다.
🐱💻Note
남아있는 하루의 즐거움을 찾자
너와의 즐거움.
저희가 뭘 하냐면요...
미쳤다. 왜 집단지성은 이런걸 골랐지. 배울게 없다..
그렇게 생각했다.
둘러보면 둘러 볼 수록 마음에 안들었다.
메인페이지는 반응형도 이상하고. 회원가입 페이지는 무슨 2004년 같고.
백엔드에서 구현 안되는 버튼을 빼고 빼고, 휑 해졌다.
그렇게 생각했다.
하지만 그동안 그렇게 꿍시렁 거리지 않았나.
한국어 다음으로 CSS가 가장 어렵다고.
이 참에 연습하기로 했다. CSS 정렬부터 차례대로.
이 참에 연습하기로 했다. 컴포넌트 재사용도.
이 참에 연습하기로 했다. 파일정리까지.
어찌되었든 성장은 찾으면 된다.
이번 주는 글쓰기 페이지를 상상하고 반응형 구도를 상상해야 한다.
문제는 내가 디자인 감각이 없다는 것이다.
🐱👤TODO
찾아서 성장하기
즐거움을 찾아가듯 그 과정에서 배울것들을 하나하나 모두 찾아보자.