오늘 생각했던 부분도 axios 부분이다. cors는 http 통신에 있어서 다른 origin을 체크하는 방법으로 2티어 아키텍처 이상으로 사용자가 접속해야하는 origin이 많아지면 허락한 origin이 아니면 접속을 허가하지 않는 브라우저 보안 방법이 cors다. 오늘 cors에러가 나왔는데 예전부터 cors 에러가 났을 때 다른 부분을 고치다가 에러가 없어지는 경우를 더러 있었다. 그래서 cors 에러를 보면 우선 요청 메소드와 api를 체크해보면서 연결부분의 코드 에러를 먼저 찾아보곤 한다. 오늘도 axios로 메세지를 보내면서 응답을 체크한는데 에러가 났다. cors에러도 있었고 promise 도 보였다. 어제 에러를 다루면서 배운 부분이 요청응답에서 에러가 나면 포스트 맨으로 어디가 문제인지 범위를 줄이는 방법을 사용하는 것이다. 포스트맨에서 에러가 가면 서버의 문제이고 에러가 안나면 클라이언트의 문제로 범위를 줄여나갈 수 있었다. 오늘 그 방법을 사용해서 포스트맨으로 요청을 보내보니 500에러가 응답되었다. 서버의 코드를 살펴봐야 했다. 그렇게 찾아보니 mysql 데이터를 orm으로 쿼리를 하고 있었는데 쿼리문에서 오타를 발견했다. 이 부분을 수정하고 다시 시도해보니 정상적으로 작동할 줄 알았는데 제대로 작동하지 않았다. 어제 봤떤 부분을 참고해서 요청을 보내니 성공적으로 응답이 오는 것을 확인했다.
응답을 받고나서
const handler = async () => {
axios.post('url', {
username:'aaaa'
},{
withCredentials: true
}).then(result => {
setState(result.data.data);
});
}
이 부분에서 result로 받을 때 data.data로 받지 않아서 배열 값이 제대로 불려지지 않았다. 당연히 배열로 올거라고 생각했는데 그렇지 않았다. 역시 결과는 항상 확인하고 찍어보고 확인하는 작업을 하는 것이 원인 분석도 빠르게 정확한 해결을 하는데 도움이 된다. 생각으로만 해결하려면 어디가 문제인지 하나하나 생각으로 찾아야하는데 나는 찍어보고 확인하는게 더 좋은 것 같았다. 오늘은 또 생각으로 하려다가 에러가 나서 찾는데 시간이 걸렸다. 더 신중하게 생각하면서 필요한 곳에 console로 확인하면서 에러를 수정해 나가야겠다.
옛날에는 error이 정말 큰일나는 줄 알았다. 큰일이 아니라기보다 나오면 안된다고 생각했다. 그렇지만 개발공부를 하면서 error은 정말 힘들게 하지만 그래도 문제가 있는 부분을 알려준다는 것만해도 정말 필요한 부분이라고 생각을 하게 되었다. 사람이 통증을 느껴야 병원에 가듯이 컴퓨터도 에러가 나야 우리가 그 부분을 수정해 줄 수 있는 것처럼 까다롭긴 하지만 error은 꼭 필요하다는 생각이 들었다. 얼마전까지만 해도 에러가 나오면 철렁했었다. 지금도 안그렇다기 보다는 조금 더 침착하게 에러가 무슨 말을 하고 있는지 살펴보면서 찾아가야겠다고 생각했다. 오히려 에러 메세지로 문제를 찾기도 했다. 당연히 많은 에러는 힘들고 어려운 수정 작업을 해야하지만 그래도 유연하게 당연하다고 생각해야 문제를 찾을 때 더 잘 보일것 같다. 팀원 중에서 에러를 유심히 보고 원인을 찾아가는 과정들을 같이 겪어보면서 많이 배웠다. 나도 그렇게 에러를 잘 핸들링 할 수 있게 익숙해져야겟다.