일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 |
- nGinder
- LPOS
- 티스토리챌린지
- 논블록킹 성능
- jar 배포
- 노드간 통신
- pinpoint 2.5.3
- 오블완
- 개발 어렵당.ㅠ
- Loki 로그
- hbase 저장공간 설정
- 월급루팡 일지
- 애자일 싫타
- pinpoint
- Ingress Controller Fake
- RedirectService
- 플루터
- ㅉ때
- jsonMarshaller
- R2DBC Paging
- OIDC
- Armeria
- formik
- reids
- fake jwt
- 7879
- save/update
- UnsupportedOperationException
- intellij
- 핀포인트
- Today
- Total
목록개발이야기/프론트 (11)
대머리개발자

진정...손이 많이 가고 노가다에 가까운 작업이다. 진정 내가 못하고 거지만... 하는 것마다 찾아보고 하니깐 지친다. 진정 리스펙한다. 진정 옛날 개발자라서 jsp에...제이쿼리로 난장판하던 시절이 생각나서 자꾸 돔으로 접근하려고 하는 습관이..... 단순 게시글 가져오기 위한 내부로직은 1. 게시글 본문 2. 게시글 카테고리 3. 게시글 댓글(최대 100개) 4. 게시글의 좋아요/조회수 카운팅 5. 나는 댓글에 좋아요까지.... 6. 해당 사용자 조회수 카운팅 했는지 체크하구 조회수 Insert 댓글을 작성한다고... 게시글 전부를 다시 태우지 않는다. 저 6가지 로직을 또 태운다고?? ajax의 장기가 드러나는 부분이다. 10년전 봤던 최범균님의 쓴책이 아직 책상 한구석에 있다. 뭐 암튼 나는 댓글..
새로고침하거나 Path(주소)를 브라우저에서 치고 접속을 하면 리덕스는 매번 "새 옷"을 입는다. 그래서 새 옷을 입지 않도록 [Redux-Persist] 도움을 받어 영속성을 유지 시켜 준다. (브라우저의 생존과 함께 한다.) 사실 SPA 특성상 새 옷을 입는게 맞다고 생각이 든다. 어째거나 두 가지 방식이 있다고 한다. 1. 위에서 언급 한 Redux-Persist 이용하거나 2. 리덕스 상태가 초기화 되었을 때 다시 설정을 해주거나.. 1번이 깔끔s하겠다. 관련내용은 https://velog.io/@nemo/redux-persist
생각보다 어렵다. 많이..이것저것 그냥 하다보면서 얻어 걸려서 진행하고 있지만 사실 deep한 이해가 있어야 한다... 모든 딥해야지..딥딥! f(values.email && values.code){ /// 서브 밋 !! loginAction(values).then(resultData => { const token = resultData as Oauth2Token if(token.access_token){ tokenSet(token.access_token, token.refresh_token) dispatch(fetchUserInfo( {'type':'token', 'targetID': token.access_token})) navigate( "/",{ replace: true }) }else{ setP..

기술검토를 해보고 바로 적용한다!. 수 많은 블로그에서 이미 샘플들이 넘쳐난다!! 그 만큼 인지도 있는 인기 있는 친구를 사용하면 좋은점이다. 래퍼랜스가 많다는 것은. But 반대로 잘못된 정보도 제법 많기 때문에 그대로 이해 하면 안 된다. ^^. 돌아가는 코드는 어쨋거나 문제는 없으나ㅎㅎ 많은 블로그에서 같은 내용으로 설명하고 있는데.. 진짜 목적은 부모&자식간의 데이터를 원활하게 통신할 수 있게 해주는 단순교통 수단입니다. Context값이 바뀐다고 해도 리렌더링 되지 않았습니다!!!!!!!! 리얼스?? 아몰랑!! 리렌더링을 하게 되는 이유는 진짜는 이유는 Context Value가!! state 로 설정하기 때문입니다. 따라서 state 값이 아닌 다른 값을 Context로 설정하면 리랜더링 되지..
프런트가 생각보다 고민할 포인트가 많다. 정답이 없는 것을 고민하는 것은 어렵다. 정답은 없지만 Why라는 측면에서 개똥철학이 있어야 할 것 같아서 정리해 본다. 나의 기본적인 전제는 각각의 페이지로 구현하는 것이 좋을 것 같다. 동일한 페이지로 쓰게 될 경우 차이점에 대한 모든 분기를 태워야 하기 때문에 수정 시 "side effect"이 발생할 경우가 다분하다. 물론 간단한 페이지 같은 경우는 동일한 페이지로 구현하는 것이 좋을 것 같지만 기본 전제는 서로가 디펜더시하게 만들어야 좋지 않을까 한다. 두벌 작업 할 필요 없도록 최대한 컴포넌트화를 해서 진행하면 나이쓰 할 듯하다!!. 근데 리액트는 state 관리가 생각보다 쉽지 않네.. 한 페이지로??..아오

low레벨에서 매번 호출하면.. 동일한 설정을 계속적으로 복사&붙여넣기를 하게 되는 불편함이 있데이!! 우린 보통의 개발자니. 깔끔s하게 처리 하자. 아래와 같은 공통의 코드를 매번 복사&붙여넣기를 해야 한다. 1.access_token 만료가 되면 401이 발생한다. 2.refresh_token을 가지고access_token을 갱신한다. 3.refresh_token 까지 만료되면 로그인 페이지로 이동s 해야한다. 만약 공통으로 사용하지 않느다면?? 생각만 해도...아니 생각하지도 말지어다.!! const cookie = new Cookies(); const baseURL = process.env.REACT_APP_SERVER_URL; const setHeader =()=>{ return { 'Conte..

https://formik.org/docs/examples formik lib의 문제는 아니였다.. 리액트에 익숙하지 않는 나의 문제였지. ㅠ 프로세스 [클라이언트 등록] -> [클라이언트 뷰] -> [클라이언트 등록] 클라이언트 등록 페이지를 다시 open 하는 과정에서 useEffect(() => { formik.handleReset(initForm) // resetForm() }, [context.editOpen]); 체크 박스가 Rest이 안 된다. ㅠ 근데 실제 내부 값들은 Reset이 진행됬는데.... 체크박스의 체크가 남아 있던 부분이였다. 아오!!! "Checkbox" 의 속성 checked을 능동적으로 설정해 주면 된다. 애초에 설정을 하지 않았던 부분이라.... 아오.. 리액트 ......
리액트는 state 변경에 따른 페이지를 다시 그린다. AS - IS는 데이터를 가져와서 제이쿼리 할아버지에게 처리를 부탁했다. (돔 직접 접근) 리액트는 데이터를 랜더링하는 부분에서 state를 통해서 진행하기 때문에 DOM에 직접 접근이 거의 필요 없다. 이벤트 캐취하는 상황에서 필요한 상황이 있긴 하다. state 관리하는 있어 몇 가지 알고 있으면 좋을듯 하여 정리s 상태 관리는 비동기 때문에 바로 변경되지 않고 한방에 몰아서 처리 된다고 한다. 따라서 별개로 관리하는것이 아니라 객체로!! 관리s const [viewOpen, setViewOpen ] = useState(false) const [editOpen, setEditOpen ] = useState(false) .... // 추천 cons..