Persistence

Java는 설치가 필요하고, Javascript는 설치가 필요하지 않은 이유

Alledy — Fri, 6 Oct 2023 23:08:30 +0900

Q. 왜 자바는 JDK, JRE와 같은 것을 설치해야 하고, 자바스크립트는 설치가 필요없는걸까?

이것에 대해 이해하려면 일단 Java와 Javascript의 언어 차이를 이해해야 한다.

자바스크립트는 인터프리터 언어이고 자바는 컴파일 언어이다.
- 인터프리터 언어와 컴파일 언어의 차이는 무엇일까? "인터프리트"는 사전에 머신코드나 바이트코드로 변경하는 일 없이 "line by line"으로 읽고 실행한다는 뜻이다. "컴파일"은 런타임 전에 머신코드나 바이트코드로 변경하는 중간 스텝이 한번 더 추가되고, 이 컴파일된 코드를 머신이나 가상 머신이 실행한다.
자바스크립트의 런타임 환경은 웹 브라우저이다. 그리고 웹 브라우저 내에는 JS engine (e.g. 크롬 V8)이 내장되어 있다. 이 엔진이 자바스크립트 코드를 해석, 실행하므로 웹 브라우저가 있다면 별도로 자바스크립트를 다운로드할 필요가 없다.
컴파일 언어인 자바는 일단 프로그램을 실행하기 위해서는 사전에 컴파일을 해야하고, 이 컴파일을 해줄 컴파일러(javac)가 필요하다. JDK(Java Development Kit)은 컴파일러를 포함하고 있다. 또한 컴파일된 바이트코드를 JVM이라는 가상 머신 위에서 실행시키는데, 이 JVM을 포함하고 있는 것이 JRE(Java Runtime Environment)이다. 이 JVM이 os나 device에 맞게 해석, 실행하므로 java는 플랫폼 중립적으로 사용할 수 있다는 장점이 있다.
- 그래서 자바는 JDK, JRE 다운로드가 필요하다.

Caveats

보통 자바는 컴파일 언어, 자바스크립트는 인터프리터 언어라고 하기 때문에 그러면 자바스크립트는 컴파일을 안하고 자바는 인터프리트를 안하나? 이분법적으로 생각할 수도 있다. 하지만 그것은 전통적인 구분이고 현대에 와서는 자바스크립트도 자바도 JIT(Just in time) 컴파일러(런타임 컴파일러)를 사용한다. 자바는 jvm에서 바이트코드를 실행할 때 JIT compiler를 사용하거나 인터프리트하여 코드를 실행한다. JIT를 사용하는 이유는 그냥 인터프리트 하는 것보다 성능을 향상시킬 수 있기 때문이다.
그러므로 인터프리터 언어와 컴파일 언어 구분이 있다고 해서 이분법적으로 해석해서는 안되고, 그 둘의 메인 차이점은 런타임 전에 코드를 컴파일 하는 단계가 있느냐 없느냐 로 봐야한다.

[React Navigation] Nested Navigator

Alledy — Wed, 17 May 2023 21:05:28 +0900

Nested Navigator

네비게이터는 own 히스토리를 갖는다.
- 뒤로가기를 하면 parent 네비게이터가 있더라도 nested stack 내부의 전 스크린으로 이동한다.
네비게이터는 own 옵션을 갖는다. title 옵션을 child navigator에서 지정하더라도 parent에게는 영향을 주지 않는다.
네비게이터는 own param을 갖는다.
- nested 네비게이터 안의 스크린에 패스된 파라미터는 parent나 child 네비게이터의 라우트 파라미터에 접근이 불가능하다.
네비게이터 액션은 현재 네비게이터에 의해 핸들링되고 만약 핸들링 불가능한 경우 버블링된다.
- 예를 들어 nested 네비게이터의 첫번째 페이지에 있는 경우 뒤로가기를 하면 부모 네비게이터로 이동한다.
- 예를 들어 아래 구조에서 Feed 스크린에서 Messages로 네비게이트를 시도했을 때는 nested 내에서 핸들링이 가능하지만 Settings로 네비게이팅은 핸들링을 못해서 parent 네비게이터가 실행한다.
  - Home (Tab.Navigator)
    - Feed (Screen)
    - Messages (Screen)
  - Profile (Screen)
  - Settings (Screen)
child 네비게이터는 parent 네비게이터의 메서드를 사용할 수 있다.
nested 네비게이터는 parent의 이벤트를 받지 않는다.
- 예를 들어 stack 네비게이터가 tab 네비게이터 안에 있다고 할 때, tab 네비게이터가 tabPress 이벤트를 emit해도 stack 네비게이터는 이 이벤트를 listen할 수 없다.
- parent로 부터 이벤트를 받으려면 navigation.getParent 를 명시적으로 사용해야 한다.
parent 네비게이터의 UI는 child 네비게이터 UI의 상위에 그려진다.

네비게이팅

parent 네비게이터에서 child 네비게이터로 이동하면 해당 네비게이터의 initial 스크린이 보여지게 된다.
만약 child 네비게이터의 initial 스크린이 아닌 특정 스크린으로 이동하고 싶다면 두번째 파라미터로 스크린을 지정해줘야 한다.
navigate('Root', { screen: 'Profile', params: { user: 'JANE' } })
네비게이터에 지정된 이니셜 라우트 렌더링하기
- 네비게이터 내의 스크린으로 이동할 때 이 스크린이 initial 스크린으로 사용되고 네비게이터에 지정된 이니셜 라우트는 무시된다.
- 만약 이 이니셜 라우트를 살리고 싶으면 initial 옵션을 false로 주면 된다. 그러면 뒤로 가기를 할 때 이니셜 스크린이 있다면 그리로 이동하게 된다.
```
navigate('Root', { screen: 'Profile', initial: false })
```

Ref

https://reactnavigation.org/docs/nesting-navigators

[React Native] ScrollView keyboardShouldPersistTaps

Alledy — Wed, 12 Apr 2023 13:21:50 +0900

키보드가 올라와있을 때는 원래는 버튼을 클릭할 수 없다. 키보드가 올라와있을 때 화면을 터치하면 키보드를 dismiss하는 것만 가능하다.
다만 키보드가 올라와있는 상태에서 버튼을 클릭하게끔 하고 싶다면 ScrollView로 해당 컴포넌트를 감싼 다음, keyboardShouldPersistTaps를 handled로 주면 된다.
handled는 ScrollView의 children에서 tap이 있을 때는 키보드를 dismiss시키지 않고 tap을 허용한다.
다만 ScrollView가 nested돼 있다면 parent ScrollView에도 해당 prop이 동일하게 적용돼있어야 정상 작동한다.

[http-proxy-middleware] path rewrite, target

Alledy — Mon, 27 Mar 2023 21:33:33 +0900

const proxy = require('http-proxy-middleware'); 

module.exports = function(app) { 
    app.use( proxy('/posts', { 
        target:'https://target.domain.com', 
        changeOrigin: true 
        }) 
    ); 
};

흔히 cors 문제를 해결하기 위해 프록시를 사용할 수 있는데, http-proxy-middleware를 사용해서 위처럼 설정하면 /posts로 시작하는 API는 target 필드에 설정한 서버로 호출하게 된다. 즉 /posts/1 을 호출하면, https://target.domain.com/posts/1 을 호출하게 된다.

const proxy = require('http-proxy-middleware'); 

module.exports = function(app) { 
    app.use( proxy('/old-posts', { 
          pathRewrite: {
            '^/old-posts': '/new-posts'
        },
        target:'https://target.domain.com', 
        changeOrigin: true 
        }) 
    ); 
};

pathRewrite 객체는 key에 매핑된 api path를 value로 치환해준다. 위의 경우에는 /old-posts를 호출하면 https://target.domain.com/new-posts 를 호출하게 된다.

Ref

https://github.com/chimurai/http-proxy-middleware#tldr-

[React] re-render가 일어나는 경우와 불필요한 리렌더를 줄이는 법

Alledy — Sat, 18 Mar 2023 00:19:34 +0900

리렌더: 이미 스크린에 그려진 컴포넌트가 다시 렌더링되는 것

리렌더링은 언제 일어나는가?

컴포넌트의 state이 변했을 때, 해당 컴포넌트가 리렌더링됨
부모가 리렌더링됐을 때, 자식 컴포넌트도 리렌더링됨 (엣지 케이스가 있으나 일반적으로 그러함)
Context Provider 값이 바뀌었을 때 그 컨텍스트를 사용하는 모든 컴포넌트가 리렌더링됨.
훅 내부에서 state 변동이 있거나 context 값 변동이 있으면 그 훅을 소비하는 컴포넌트가 리렌더링 됨.

function Parent() {
    const [state, setState] = useState(); // state이 변하면 Parent 컴포넌트 리렌더링됨
    // Parent 컴포넌트가 리렌더링되면 Child 컴포넌트도 리렌더링됨
    return <Child /> 
}

반대로 리렌더링을 유발하지 않는 것은?

props 변동 (메모이제이션된 컴포넌트는 예외임)
- props가 변동하기 위해서는 부모 컴포넌트의 값이 업데이트되어야 하고 이것이 리렌더링을 유발하고 부모 컴포넌트가 리렌더링되면 자식 컴포넌트도 리렌더링되지만 이것은 props 변동이 원인인 것이 아님.
- 값의 업데이트가 일어나면서 리렌더링과 props변동 둘 다 일어나는 것뿐.

컴포넌트 합성으로 리렌더링 방지하기

안티패턴

컴포넌트 안에서 새로운 컴포넌트를 생성해서 리턴하기
```
function Component() {
  // 컴포넌트 안에서 컴포넌트 생성 후 리턴
  function SlowComponent() {
      return <Something />
  }
  return <SlowComponent />
}
```
위 케이스는 Component가 리렌더링 될 때마다 SlowComponent가 re-mount되기 때문에 단순한 리렌더링보다 더 느리다. 하지만 굳이 이렇게 코딩하는 경우는 크게 없을 듯.

state를 밑으로 내리기

state가 변동하면 해당 컴포넌트가 리렌더링되고 모든 Child가 또 리렌더링되기 때문에, state를 국한지을 수 있다면 가급적 부모보다는 낮은 위계에 분리시키는 것이 불필요한 리렌더링을 줄일 수 있다.

// 이 경우 state가 변경되면 children인 VerySlowComponent도 리렌더링된다. 
function Component {
    const [open, setOpen] = useState(false);
    return (
        <Container>
            <Button onClick={() => {setOpen(true)}} />
            {isOpen && <ModalDialog />}
            <VerySlowComponent />
        </Container>
    )
}

// children의 리렌더링은 parent에게 영향을 주지 않으므로, 이 케이스에서는 VerySlowComponent가 영향받지 않는다. 
function ModalOpenButton() {
    const [open, setOpen] = useState(false);

    return (
        <>
            <Button onClick={() => {setOpen(true)}} />
            {isOpen && <ModalDialog />}
        </>
    )
}

function Component {
    return (
        <Container>
            <ModalOpenButton />
            <VerySlowComponent />
        </Container>
    )
}

Children as prop

이것도 state를 내리는 기법과 비슷하다. state를 보다 작은 부분에 캡슐화해서 분리하는 방법이기 때문이다.
그리고 props가 리렌더링이랑 관련없다는 사실도 기억해야 한다.

function Component() {
    const [state, setState] = useState()

    return (
        <div onScroll={(e) => setState(e)}>
            <VerySlowComponent />
        </div>
    )
}

function Scroll({ children }) {
    const [state, setState] = useState()
    return (
        <div onScroll={(e) => setState(e)}>
            {children}
        </div>
    )
}

// 리렌더링은 Scroll에서만 일어난다. 이 리렌더링은 props.children인 VerySlowComponent에는 영향을 주지 않는다. 
function Component() {
    return (
        <Scroll>
            <VerySlowComponent />
        </Scroll>
    )
}

Component as props

위에와 아주 비슷한 패턴이다. 다만 children이 아닌 props일 뿐.

function Component() {
    const [state, setState] = useState()

    return (
        <div onScroll={(e) => setState(e)}>
            <VerySlowComponentOne />
            <Something />
            <VerySlowComponentTwo />
        </div>
    )
}

function Scroll({ left, right }) {
    const [state, setState] = useState()
    return (
        <div onScroll={(e) => setState(e)}>
            {left}
            <Something />
            {right}
        </div>
    )
}

// 리렌더링은 Scroll에서만 일어난다. 이 리렌더링은 props.left, props.right인 VerySlowComponent들에는 영향을 주지 않는다. 
function Component() {
    return (
        <Scroll 
            left={<VerySlowComponentOne />}
            right={<VerySlowComponentTwo />}
        />
    )
}

props가 리렌더링에 영향을 주는 예외 케이스는 메모이제이션된 컴포넌트일 경우다. 이 케이스는 다음 편에 마저 작성할 예정.

Ref

https://www.developerway.com/posts/react-re-renders-guide

[React Query] Tracked Query

Alledy — Thu, 16 Mar 2023 17:30:48 +0900

export const useTodosQuery = (select) =>
  useQuery({ queryKey: ['todos'], queryFn: fetchTodos, select })
export const useTodosCount = () => useTodosQuery((data) => data.length)

function TodosCount() {
  const todosCount = useTodosCount()

  return <div>{todosCount.data}</div>
}

위 쿼리는 백그라운드에서 refetch할 때마다 두번씩 컴포넌트 리렌더링을 트리거한다.

{ status: 'success', data: 2, isFetching: true }
{ status: 'success', data: 2, isFetching: false }

isFetching의 상태값이 바뀌기 때문이다.

위와 같은 리렌더링을 피하고 싶다면 notifyOnChangeProps 를 사용할 수 있다.
이름에서 알 수 있듯이, 이것이 바뀔 때에만 옵저버에게 inform 하라는 것이다

export const useTodosQuery = (select, notifyOnChangeProps) =>
  useQuery({
    queryKey: ['todos'],
    queryFn: fetchTodos,
    select,
    notifyOnChangeProps,
  })
export const useTodosCount = () =>
  useTodosQuery((data) => data.length, ['data'])

하지만 위 방식의 단점은 화이트리스트로 관리된다는 점이다.
만약 에러가 일어났을 때 리렌더링을 하고 싶으면 'error' 도 넣어줘야 하고, isLoading도 사용하고 싶으면 그것도 넣어줘야 한다. 누락됐을 때 문제가 생길 수 있다. 이게 불필요한 리렌더보다 더 최악이다.

이것을 해결할 수 있는 것이 있다.

const queryClient = new QueryClient({
  defaultOptions: {
    queries: {
      notifyOnChangeProps: 'tracked',
    },
  },
})
function App() {
  return (
    <QueryClientProvider client={queryClient}>
      <Example />
    </QueryClientProvider>
  )
}

쿼리 클라이언트 설정에서 위처럼 tracked 값을 설정하면 우리가 사용하는 필드에 대해서만 tracking하게 되며, array에 일일이 리스트한 것과 동일한 효과를 낸다.

[React] usePrevious hook

Alledy — Mon, 13 Feb 2023 13:42:10 +0900

usePrevious

const usePrevious = value => {
    const ref = useRef();
    useEffect(() => {
        ref.current = value;
    })
    return ref.current;
}

react docs에 보면 이런 코드에 대한 힌트를 얻을 수 있다. 이 훅은 전(Previous) state나 props의 값을 저장한다. 하지만 이 코드가 어떻게 전 value를 저장하는 결과를 가져오는 것일까?

첫 번째 포인트는 ref 값의 변화는 re-render를 트리거하지 않는다는 점이다. 반면 state의 변화는 re-render를 일으킨다. 예를 들어

const Counter = () => {
    const ref = useRef(0);
    const [counter, setCounter] = useState(0);

    return (
        <>
            <button onClick={() => setCounter(counter + 1)}>state counter</button>
            <button onClick={() => { ref.current ref.current + 1 }}>ref counter</button>
            state couter value: {counter}
            ref counter value: {ref.current}
        </>
    )
}

이런 코드에서 아무리 ref counter의 버튼을 눌러서 값을 증가시켜도 ref value의 변화는 리렌더링을 일으키지 않으므로 화면에 보이는 값은 갱신되지 않는다. 만약 그 상태에서 state counter를 증가시키면 리렌더링이 일어나면서 ref counter 값 또한 갱신된다.

두 번째 포인트는, useEffect는 렌더링이 끝나면 트리거된다는 점이다.

즉, 초기값이 0인 카운터를 가정했을 때 이런 플로우로 실행된다.

컴포넌트가 처음 마운트하면 렌더링이 끝나고 useEffect는 실행되고(2번째 포인트) 그 콜백에 의해서 ref.current는 초기값 0을 저장할 것이다.
만약 state가 1로 증가하면, 다시 리렌더링이 되면서 변화된 상태값 1이 화면에 표시된다. 이 리렌더링이 될 당시 ref.current에 저장된 값은 아직 0 이다. 리렌더링이 끝나고 useEffect가 실행되면서 콜백에 의해 변화된 상태값 1을 저장한다. ref 값의 변화는 리렌더링을 일으키지 않으므로 ref.current가 1로 갱신돼도 화면에서는 아무런 변화가 나타나지 않는다.
즉 state 변화 -> 화면에 리렌더링 (이때 ref value는 여전히 이 전값을 가리킴) -> 리렌더링 후 useEffect가 실행되며 ref.current값을 최신으로 갱신 -> 하지만 이는 리렌더링을 일으키지 않음 -> 반복...

Ref

https://www.developerway.com/posts/implementing-advanced-use-previous-hook

[React Query] active하고 stale한 쿼리의 refetch

Alledy — Wed, 11 Jan 2023 23:55:41 +0900

상황

React Native에서 react navigation 스택을 사용함
퍼널 앞에서 호출한 쿼리를 퍼널 뒤에 새로운 화면에서 호출했는데 refetch하지 않고 기존 데이터를 재사용함.
캐시타임 내에 호출이 되어서 그런 줄 알고 cacheTime을 0으로 주고 했는데 동일한 현상 발생.

이유

일단 cacheTime은 inactive한 쿼리에 대해서만 의미가 있는데, 그 쿼리는 계속해서 active한 쿼리였다. 왜냐하면 스택 네비게이션에서는 계속해서 컴포넌트가 마운트된 상태로 쌓이기 때문이다.
챰고로 inactive 쿼리는 옵저버가 없는 쿼리를 의미하며, devtool로도 확인할 수 있고 Query Cache를 조회해서 옵저버 필드를 확인해볼 수도 있다.
stale time은 디폴트가 0이므로 그 쿼리의 상태는 stale하고 active한 상태였다. devtool을 사용하면 확인하기 쉬웠겠지만 현재 react-native-debugger를 사용해서 react query devtool을 사용할 수 없었던 상태였다.
즉 cacheTime을 0으로 준 것은 어차피 active 쿼리니까 상관이 없었다.
그리고 프로젝트에서 사용하는 리액트 쿼리의 디폴트 옵션이 refetchOnMount: false 였다.
그래서 최초 쿼리한 스크린이 계속 마운트되어 있는 한 캐시타임과 관계 없이 refetch되지 않았다.
뒤로 가기를 눌러 최초 쿼리한 스크린을 언마운트 시킨 뒤 다시 마운트 시키면 이 때는 캐시타임이 지났는지에 따라 refetch를 한다.

Ref

refetching 조건
https://velog.io/@apro_xo/react-query-%EC%BA%90%EC%8B%B1feat.-refetch

important default
https://tanstack.com/query/latest/docs/react/guides/important-defaults

동일한 렌더링 주기에서는 같은 요청을 중복해서 보내지 않음 (active and stale query 케이스)
https://github.com/TanStack/query/discussions/2018#discussioncomment-645456

react navigation 라이프 사이클
https://reactnavigation.org/docs/3.x/navigation-lifecycle

옵저버가 없는 쿼리가 inactive 쿼리다
https://tkdodo.eu/blog/inside-react-query

ISR (Incremental Static Regeneration)

Alledy — Mon, 28 Nov 2022 18:13:31 +0900

ISR을 알기 전 Next.js 선수지식

렌더링

CSR, SSR, SSG
렌더링이란 UI를 HTML로 나타내는 과정이다. 렌더링은 클라이언트에서 일어날 수도 있고 서버에서 일어날 수도 있다.
클라이언트에서 렌더링이 일어나는 것을 Client Side Rendering이라고 한다. 서버로부터 빈 HTML과 UI를 구성하기 위한 정보가 담긴 javascript 파일을 받아서 유저 디바이스에서 렌더링 작업을 시작한다.
이것과 대비되는 개념으로 서버에서 렌더링이 일어나는 것을 Pre-rendering이라고 한다. 클라이언트에 전송되기 전에 미리(Pre) HTML을 만들어서 전송한다는 의미이다. CSR을 사용하려면 useEffect나 useSWR을 사용해서 클라이언트에서 data fetching을 한다.
Pre-rendering에는 Static Site Generation과 Server Side Rendering이 있다. Nextjs의 디폴트 동작은 Pre rendering이다.
둘 다 HTML을 미리 만든 뒤 클라이언트에 전송한다는 점에서 공통점이 있지만, 차이점은 런타임에 만드느냐 빌드타임에 만드느냐이다.
Static Site Generation은 빌드타임에 HTML을 만들어놓고 배포된 뒤 유저 요청이 올때마다 CDN에서 저장된 HTML을 서빙한다. 즉 런타임에는 서버가 없다. SSG를 사용하려면 getStaticProps를 사용한다.
Server Side Rendering은 SSG와 달리 런타임에 유저 요청이 있을 때마다 서버에서 HTML을 만들어서 보내준다. HTML과 javascript instruction, json data를 보내서 HTML을 먼저 보여주고 거기에 이벤트 핸들러를 붙여서 interactive하게 만드는 hydration 과정을 거친다. SSR을 사용하려면 getServersideProps를 사용한다.
ref: https://nextjs.org/learn/foundations/how-nextjs-works/rendering

ISR

static page generation은 빌드 타임에 모든 페이지를 미리 생성한다.
isr은 모든 페이지를 생성하지 않고 페이지 단위로 갱신을 가능하게 한다.

적용 방법

적용하는 방법은 getStaticProps 함수 리턴문 내에 revalidate 필드를 포함시키면 된다.

export async function getStaticProps() {
    const res = await fetch('https://.../posts')
    const posts = await res.json()

    return {
        props: {
            posts,
        },
        revalidate: 10 // 초 단위
    }
}

revalidate에 매핑되는 시간 동안 페이지는 캐싱되고, 그 시간이 지난 이후 접속한 유저가 있으면 새로운 페이지를 뒷단에서 생성한다. 이 생성이 성공적이면 캐시를 무효화하고 새로 갱신한 페이지를 보여준다.

revalidate을 추가하면 x-nextjs-cache 필드가 response 헤더에 추가된다. 이 값은 MISS, STALE, HIT 3가지 중 하나이다.

MISS: 캐시에 이 path가 없다. 처음 방문 시 최대 한 번 발생.
STALE: 캐시에 있으며, revalidate 타임이 지나서 stale한 상태이므로 백그라운드에서 갱신이 진행될 것이다.
HIT: 캐시에 있으며, revalidate 타임을 초과하지 않았다.

export async function getStaticPaths() {
    const res = await fetch('https://.../posts')
    const posts = await res.json()

    return { paths: posts.map(x => ({ params: id: x.id }), fallback: 'blocking' }
}

getStaticPaths에 정의된 path들만 빌드 타임에 pre render를 진행하고 fallback 필드에 정의된 값에 따라 서버 렌더링을 해서 페이지를 갱신한다.

fallback 값으로 올 수 있는 값은 true, false, 'blocking' 이다.

false: getStaticPaths로부터 리턴되지 않은 path는 404 페이지를 보여준다.
true: getStatisPaths로부터 리턴되지 않은 path는 404를 보여주는 게 아니라 fallback 페이지를 보여주다가 백그라운드에서 html을 생성한 다음 유저에게 보이는 페이지를 갈아낀다. 이 새로운 페이지로 pre render 리스트에 추가한다.
blocking: getStatisPaths로부터 리턴되지 않은 path는 유저 리퀘스트가 왔을 때 페이지를 만든 다음에 완성되면 클라이언트에 표시한다. true랑의 차이는 fallback이 보여지느냐 아니냐이다.

next.js module not found (module resolve 에러)

Alledy — Thu, 27 Oct 2022 17:49:28 +0900

상황

../../.yarn/cache/keen-slider-npm-6.8.3-1dae0bc90d-b798545bd6.zip/node_modules/keen-slider/react.js:1:74
Module not found: Can't resolve 'react'
Did you mean './react'?
Requests that should resolve in the current directory need to start with './'.
Requests that start with a name are treated as module requests and resolve within module directories (node_modules, /Users/dayoung.kang/toss/frontend/services/homepage/src).
If changing the source code is not an option there is also a resolve options called 'preferRelative' which tries to resolve these kind of requests in the current directory too.

Import trace for requested module:
./src/pages/main/components/review-section/ReviewSection.tsx
./src/pages/main/Main.tsx
./pages/index.ts

https://nextjs.org/docs/messages/module-not-found

error - Error: keen-slider tried to access react, but it isn't declared in its dependencies; this makes the require call ambiguous and unsound.

keen-slider라는 패키지를 설치하고 keen-slider/react에서 모듈을 임포트했는데 react를 resolve할 수 없다고 나옴. 해당 패키지의 package.json 을 보니 react가 devDependency로만 설치되어 있고 peerDependency 정의가 없음.

해결방법

yarn의 인터널 설정 파일인 .yarnrc.yml 에 아래처럼 추가해준다.

packageExtensions:
  keen-slider@*:
    peerDependencies:
      react: "*"
      react-dom: "*"

Ref

https://yarnpkg.com/configuration/yarnrc