admin header grid로 인한 컨텐츠 정렬 오류

[baaaam771]

export default function Writer() {
  return (
    <div>
      <AdminHeader />
      <Editor />
    </div>
  );
}

간략하게 이러한 구조로 admin header 적용시켜 봤는데요

이런식으로 헤더 아래 에디터가 들어가게 되더라고요 grid로 2, 10 이렇게 나눠서 적용시켜주신것 같은데 그래서 오른쪽 부분도 공간을 차지하게 된 것 같습니다

[suinj8]

혹시 위쪽 사진도 보여주실 수 있을까요?

직접 브랜치로 가서 확인했고 수정이 필요하겠네요.. 고민해보겠습니다.

[baaaam771]

혹시 위쪽 사진도 보여주실 수 있을까요?

직접 브랜치로 가서 확인했고 수정이 필요하겠네요.. 고민해보겠습니다.

넵 같이 고민해봅시다!

[suinj8]

넵 같이 고민해봅시다!

몇가지 고민해 보았습니다. 어느게 나을까요? 혹은 더 나은 방법이 있을까요? 제가 생각한 것은 이렇습니다.

1. 제가 구현한 헤더를 메인페이지로 생각하고 헤더를 따로 컴포넌트화 하는것이 아닌 각 세부 컨텐츠를 갖는 페이지를 컴포넌트화 하여 메인으로 바꾼 파일에 조건에 따라 랜더링한다. 간단하게 빨간색 부분에 조건에 따른 랜더링을 한다고 생각하시면 됩니다.

2. 아래 사진에서 빨간색, 하늘색 부분을 컴포넌트화 해놓고 각 세부페이지를 구현할 때 디자인 요소에 컴포넌트를 집어넣기.

   ex) 
   <위쪽 헤더 선언> - 빨간색
   <Box sx={{display : flex}}> - 녹색에 flex속성을 주어 하늘색(왼쪽헤더)과 주황색 부분(컨텐츠 - 예상)을 나란히 배치
   <왼쪽 헤더 선언 /> - 하늘색
   <실제 컨텐츠 /> - 주황색

   

제가 생각한 방법은 위 두가지 입니다. 의견 부탁드립니다. @baaaam771 @euny0ung @LimEunSang

[LimEunSang]

2번으로 진행할 시 코드의 중복을 피할 수 없어 2번보다 1번으로 하자에 한 표 하겠습니다.

여기서 코드의 중복이란, 예를 들면,

<Header/>
<Grid>
  <Grid>
    <Menu/>
  </Grid>
  <Grid>
     // 실제 액기스 코드
  </Grid>
</Grid>

모든 페이지에 이런식으로 코드 형식을 맞춰줘야 하는 것을 의미합니다.

하지만, 1번으로 했을 시 처음 해보는 구현 방식이기 때문에 발견하기 힘든 구현의 문제가 있을 수 있습니다.

그 중 한 가지는 중첩 route 문제인데요, react 에서는

<Route path="/admin/researchfield" element={<ResearchField/>} />

위와 같은 코드 작성이 불가능합니다. (이 문제에 대해서는 해결법이 있긴 합니다: https://mygumi.tistory.com/414) 이런식으로, 생각하지 못한 문제가 발생할 수 있다는 점입니다.

그렇지만, 공부의 목적으로다가 새로운 방식으로 구현해 보는 것도 나쁘지 않다고 생각합니다.

결론은 전 1번입니다.

[baaaam771]

저는 처음에 보편적으로 생각할 때 2번 방식만 떠올렸습니다. 하나의 문서 안에서 페이지를 구성하는 컴포넌트들이 다 보이는 것이 좋은 방식이라고 생각했습니다 header SideMenu로 나눠서

<Header />
  <Grid container>
      <Grid item xs={2}>
          <SideMenu />
      </Grid>
      <Grid item xs={10}>
          Contents
          ...
      </Grid>
  </Grid>

이 정도로 생각하고 있었습니다

1번 방식은 우리가 컴포넌트 호출하듯이 페이지의 세부요소를 렌더링 한다는 이야기 같은데

사실 둘다 구현하는 것에는 커다란 어려움이 많지는 않을 것 같고 둘다 중복 문제도 비슷할 것 같습니다.

그래서 제 생각은 page라는 폴더에서 article.js라는 문서를 보았을 때 어떤방식이 전반적인 페이지의 구성을 한눈에 보기 쉬운지 그리고 어떤방식이 재활용해서 사용하는 컴포넌트의 의미를 잘 적용한 방식인지 고민해보면 좋을 것 같습니다!

[suinj8]

현재 이문제가 빨리 해결되어야 페이지 세부요소를 구현이 가능하게 됩니다. 각자 한번씩 생각해 보시고 의견 남겨주시면 통합해서 빠른 시일내에 구현해서 올리도록 하겠습니다.

범기님이 말씀해 주신대로 생각해보면 재활용의 의미에서는 1번이 더 맞는 방법이지 않을까 생각합니다. 간단하게 생각하면 2번은 클릭시 전체가 다시 불러와지는 방식이고 1번은 컨텐츠만 바뀌면 되는 부분이니까요.

결론적으로는 저는 1번이 맞는거 같다고 생각합니다. 하지만 저희가 api를 사용해야하고 따라서 URL이 필수로 필요한데 1번방식은 랜더링 방식이라 그부분이 걸리기는 합니다. 은상님이 공유해주신 방법이 있긴 하지만 처음 적용해보는거라 시간이 더 걸릴것이기도 하구요.

일단은 방법을 선택을 해주시면 구현은 해보도록 하겠습니다. 빠른 답변 부탁드립니다.

@baaaam771 @LimEunSang @euny0ung

[euny0ung]

알람이 안 와서 지금 봤네요 죄송합니다. 은상님이 공유해주신 글 확인했습니다. 중첩 라우터라는걸 처음 알았어요..

저도 수인님 말대로 효율적인 면에서는 1번이 더 낫다고 생각합니다. 중첩 라우터로 작성한 코드를 여러개 읽어봤는데 많이 달라지는건 없어서 적응하는데엔 문제 없을것 같네요. 그런데 api를 사용함과 동시에 1번 방식을 쓰면 문제되는게 있나요?? 이 부분에 대해 정확히 이해를 못했습니다.

[suinj8]

알람이 안 와서 지금 봤네요 죄송합니다. 은상님이 공유해주신 글 확인했습니다. 중첩 라우터라는걸 처음 알았어요..

저도 수인님 말대로 효율적인 면에서는 1번이 더 낫다고 생각합니다. 중첩 라우터로 작성한 코드를 여러개 읽어봤는데 많이 달라지는건 없어서 적응하는데엔 문제 없을것 같네요. 그런데 api를 사용함과 동시에 1번 방식을 쓰면 문제되는게 있나요?? 이 부분에 대해 정확히 이해를 못했습니다.

제가 알기로는 API를 통하여 DB에서 데이터를 받아올 때 정해진 url에서 호출을 해야 올바르게 받아올 수 있는것으로 알고 있습니다. 1번을 사용하게 되면 내부에서 state를 통하여 컨텐츠를 관리하기 때문에 url이 바뀌지 않습니다. 마치 연구분야 페이지에서 다른 연구분야를 클릭해도 url자체는 field인것처럼요. 따라서 위에서 은상님이 말씀해주신대로 해결을 해나아가야 하지 않을까 생각합니다.