qwef

이건 아예 랜더링 된 결과가 메모리에 캐싱된다. 이 랜더링 된 결과가 어떤 형식으로 들어가냐면, 왜 우리가 리액트 할 때 return( ) 하면서 가상의 dom 요소들을 사용하는데, 저기에 변수같은게 아니라 값이 채워져 있는 형식으로 그 가상 요소가 메모리에 저장된다. 여튼 메모리에 캐싱되는 데이터는 저거고, 그러면 새로 다시 function을 재 랜더링 하는 트리거는 뭐냐면, props다. 단 하나 props로 전달된 것의 값의 변화가 있을 시에만 얘가 재 랜더링을 한다. 사용 방법은 export default React.memo(컴포넌트); 그냥 이렇게 하면 된다. 딱 이게 끝이다. 이 상태로 있다가, 예를 들어 const TodoItems = ({message})=>{ return( {message..

리액트에서 update, 아니면 재랜더링 등 이런 부분에서 최적화를 하기 위한 기능들이 몇개 있는데, React.memo() useMemo() useCallback() 이것들임. memo는 말 그대로 메모, 기억해두겠다는 거임. memoization 이라고도 하는데, 메모리에 넣는다는 거임. 일종의 캐싱임. memoization 이거 자체를 캐싱이라고 보면 됨. 얘의 사용방법은 const 변수 = useMemo(()=>{return이 있는함수.},[의존성배열]) 이러면 변수에 첫번째 랜더링 했을 때 이 함수가 실행되면서 값을 저장하고 있다가, 의존성 배열에 있는 참조중 변화가 일어나면 이것이 다시 실행된다. 그 전까지는 캐싱해놨던 값을 준다. const analyzeTodo = useMemo(()=>{ ..

얘는 진짜 말 그대로 어떤 값에 대한 모든 행동(로직)들을 응축시키기 위해 만든 느낌이다. const [count, dispatch] = useReducer(reducer, 0); const [값, 상태변화하고싶을시쓸함수이름] = useReducer(실행할콜백, 초기값); 이게 저 값이라는 것에 대한 모든 상태변화를 저 실행할 콜백에서 관리하는 거다. { dispatch({ type:"INCREASE", data:1 }) }}>+ 1 이런 식으로. 저 dispatch 안에 값을 넣을 수 있다. 보통 저렇게 객체형식으로 넣는다. 이렇게 객체 형식으로 넣는 이유는, function reducer(state, action){ switch(action.type){ case "INCREASE": return st..

스프링 데이터 JPA에서 페이징과 정렬을 정말 간단히 지원해 준다. 스프링 데이터 JPA는 페이징과 정렬을 표준화 시켜놨다. org.springframework.data.domain.Sort 와 org.springframework.data.Pageable 이 두개로 표준화 시켜놨음. 페이징도 요새는 2가지 종류가 있는데, 추가 count 결과를 포함하는 페이징과, 추가 count 결과를 포함하지 않는, 다음 페이지가 있나 없나 확인 가능한(내부적으로 limit + 1 하나 더 조회) 왜 모바일 같은 경우 아래로 내리면 그냥 더 나오는.. org.springframework.data.Page가 총 count가 몇갠지 추가로 쿼리를 날리는 페이징이고, org.springframework.data.Slice가..

지금까지 뭐 select * from member; 이런 식으로 그냥 다 데려왔었는데, 우리가 DB에 있는 걸 사실 다 끌고 올 수는 없음. 적당한 단위로 끊어서 가지고 와야 함. 그래서 게시판 보면 페이지별로 끊어놓는 거임. 조건 나이가 10살 이름으로 내림차순 첫번째 페이지. 페이지당 보여줄 데이터는 3건 public List findByPage(int age, int offset, int limit){ return em.createQuery("select m from Member m where m.age = :age order by m.username desc", Member.class) .setParameter("age", age) .setFirstResult(offset) .setMaxResul..

스프링 데이터 JPA는 이 조회해는 것의 반환타입을 유연하게 제공함. 컬렉션으로, 아니면 단건, 아니면 단건인데 Optional로 등등.. List findListByUsername(String username); Member findMemberByUsername(String username); Optional findOptionalByUsername(String username); 굉장히 많은 반환타입이 보장된다. 컬렉션, 단건, 옵셔널 이거 외에도 많다. 컬렉션은 없으면 그냥 빈 컬렉션. 단건은 null. 이게 조금 순수 JPA와 다른 부분인데 순수 JPA는 없으면 예외를 날리는 데 스프링 데이터 JPA는 그 예외를 잡아서 null로 return함. 옵셔널은 마치 양자처럼 있거나 없거나. 이 외에도 ..

파라미터 바인딩은 위치기반이 있고 이름기반이 있음 select m from Member m where m.username = ?0 select m from Member m where m.usernmae = :name 위치기반은 사용하지 않는다고 함. 확실히 이름기반이 훨씬 명확함. @Query("select m from Member m where m.username = :username and m.age = :age") List findUser(@Param("username") String username, @Param("age") int age); 이렇게 바인딩 했었음. @Param(SQL상파라미터명) 타입 인자이름 여튼 이런거는 지금까지 많이 해왔던 거고, 컬렉션을 인자로 넣을 수 있는데 이게 무슨 ..

지금까지 그냥 엔티티 전체를 가지고 왔음. 이번엔 스프링 데이터 JPA로 Dto나 특정 값만 가져오는 걸 해 볼텐데, 이거는 메소드명으로 쿼리 자동생성으로는 못한다. 저 익명@Query를 써야 한다. @Query("select m.username from Member m") List findUsernames(); 그냥 우리가 순수 JPA에서 jpql 짜듯이 하면 된다. 그럼 다음은 Dto @Data public class MemberDto { private Long id; private String username; private String teamName; public MemberDto(Long id, String username, String teamName) { this.id = id; this...

그냥 @Query("select m from Member m where m.username = :username and m.age = :age") List findUser(@Param("username") String username, @Param("age") int age); 이렇게 곧바로 쓰는거다. 이거는 네임드쿼리를 곧바로 쓰는거라고 보면 된다. @Query("select m from Member m where m.username = :username and m.age = :age") List findUser(@Param("username") String username, @Param("age") int age); @Query("쿼리와 :파라미터") List 메소드명(@Param("쿼리상파라미터명"..

얘는 실무에서 거의 쓸 일이 없음. 네임드 쿼리는 쿼리에 이름을 부여하고 호출하는 기능 이거보다 더 상위호환이 될 수 있는 좋은 기능이 있기에 이거는 잘 안씀. 그래도 소개를 해 보자면, 사용하려면 @NamedQuery( name = "Member.findByUsername", query="select m from Member m where m.username=:username" ) public class Member { ... 이렇게 엔티티에 적어놓음( 따로 xml파일에 정의해 놓을 수도 있음. ) public List findByUsernameNameQuery(String username){ return em.createNamedQuery("Member.findByUsername",Member.cla..