React를 사용하여 개인 블로그 만들기

8361 단어
프로젝트 주소:github.com/zaleGZL/zal…
만약 당신이 프로젝트가 괜찮다고 생각한다면 오른쪽 상단'star'를 클릭하여 지지해 주셔서 대단히 감사합니다!(≧▽≦)/~
온라인 주소:guozeling.cn/blogs
전언
예전에 저는 Hexo+next로 블로그를 만들었지만 최근에 React를 배운 후에 구성 요소화 개발 사상에 깊이 빠져들었습니다. 마침 겨울방학에 시간이 생겨서 React로 블로그를 만들었습니다.React는 실제적으로 MVC의 시각층에 대응할 뿐이다. 완전한 응용을 구축하려면 React만으로는 부족하다. 우리는 데이터를 관리하는 Redux, 전방 루트를 실현하는 React-router 등 다른 라이브러리나 프레임워크가 필요하다.
기술 창고
프런트엔드
  • react
  • axios: 비동기 요청
  • react-router-dom: 전방 루트
  • redux: 전체 응용 데이터 관리
  • redux-thunk:redux의 중간부품으로 비동기적인 액션을 처리하는 데 많이 사용
  • styled-components: CSS in JS의 일종으로 JS에 원생 CSS를 쓸 수 있다
  • 주석: 블로그 전단 페이지는 다른 React 기반 CSS 프레임워크를 사용하지 않았고 주로 자신이 CSS를 쓰는 능력을 강화하고자 한다.
    백엔드
  • koa

  • 블로그의 백엔드는 Node를 사용합니다.js가 개발한 것은 koa를 바탕으로 Restful API 구조를 이용하여 이루어진 것으로 전후단의 분리를 완벽하게 실현했다. 후단은 데이터 제공만 책임지고 루트의 이동, 데이터 렌더링은 모두 전단에서 이루어진다.
    프로젝트 주소:github.com/zaleGZL/zal…
    실현 가능한 기능
  • [x] 블로그 첫 페이지 목록 전시
  • [x] 블로그 콘텐츠markdown
  • [x] 블로그 내용의 디렉터리
  • [x] 블로그의 분류와 라벨
  • [x]귀환
  • [x] 응답식
  • [x] 관련 페이지(현재 이력서 제출, 본인 대학 3학년, 실습 중...)

  • TODO
  • [] 분류 페이지
  • [] 탭 페이지
  • [] markdown 코드 강조
  • [] 미화 페이지의 양식
  • 블로그 미리 보기
    첫 페이지
    블로그 상세 정보 페이지
    프로젝트 요약
    이어서 나는 내가 블로그 프로젝트를 할 때의 체험과 깨달음을 대체적으로 소개한다.
    React는 하나의 뷰 레이어에 불과합니다.
    React를 사용한 후에 저는 React 자체가 하는 일이 매우 간단하다는 것을 알게 되었습니다. 이것은 단지 하나의 시각층의 구조일 뿐입니다. 이것은 JSX 문법으로 HTML을 쓸 수 있고 구성 요소를 바탕으로 하는 개발 방식이 매우 참신하여 구성 요소가 높은 복용성을 가지도록 합니다.여러 사람이 협동하여 응용을 구축할 때 우리 모두는 하나의 작은 구성 요소만 책임질 수 있다. 이 동시에 우리는 구성 요소와 구성 요소의 결합성을 최대한 낮추고 구성 요소의 내중성을 증대시켜야 한다. 최종적으로 이 구성 요소들은 하나의 대형 응용을 구축할 수 있다.
    프런트엔드 라우팅
    전단의 발전이 매우 빠르고 항상 새로운 것이 나타난다. 예전에express를 이용하여 백엔드 응용 프로그램을 구축했다. 그때 나는 백엔드 루트가 있다는 것을 알았다. 즉, 요청한 URL 경로로 서로 다른 내용을 되돌려주고 서로 다른 페이지를 되돌려주는 것이다.내가 처음 앞의 경로를 들었을 때, 나는 처음에 그것이 새로운 물건이라고 생각했는데, 사실은 그렇지 않았다. 그것은 단지 뒷부분의 그 방법을 옮겨왔을 뿐이었다.페이지의 URL이 새로 고쳐질 때 이 URL 요청을 하지 않고 서로 다른 URL에 따라 다른 구성 요소를 렌더링할 수 있도록 프런트에서 루트를 구현했습니다.
    
      
      
      
      
      
      
      
    
    

    위의 코드는 바로 제 블로그에서 가장 윗부분의 루트 구성 요소를 응용하는 부분 코드입니다. 여기는react-router를 사용하고 서로 다른 루트에 따라 서로 다른 구성 요소를 렌더링합니다.
    응용 데이터 관리 방법
    React의 state는 사실 응용 데이터를 저장하고 서브 구성 요소에 전달할 수 있는 것이다. 소형 응용 프로그램을 구축할 때state는 확실히 충분하지만 대형 응용 프로그램을 구축할 때 응용 데이터를 어떻게 관리하는지 잘 고려해야 한다.state 다음과 같은 문제점이 있습니다.
  • 부모 구성 요소가 손자 구성 요소나 후대 구성 요소에 데이터를 전달하려면 모든 중간 구성 요소의 도움을 받아야 한다. 그렇지 않으면 React의 context API로 전체 구성 요소에서 데이터를 전달해야 한다.
  • 서브어셈블리의 데이터는 상위 어셈블리나 상위 어셈블리에 전달되지 않습니다.
  • 응용된 데이터 저장소가 너무 분산되어 있다.

  • Redux의 등장은 상기 문제를 해결했다. Redux에는 유일한 전역store만 존재하고 전체 응용 프로그램의 데이터는 여기에 저장된다. 모든 구성 요소는 store에서 자신의 구성 요소에 필요한 데이터를 얻을 수 있고 발송action을 통해 변경할 수 있다store. store의 변경으로 해당 구성 요소가 업데이트된다.구성 요소도 업데이트된 데이터를 받을 수 있습니다.사실 Redux는 Context API로 이루어진 것이고,
    const mapStateToProps = state => ({
      blogCount: state.profile.blogCount,
      tagCount: state.profile.tagCount,
      categoryCount: state.profile.categoryCount
    })
    
    const mapDispatchToProps = dispatch =>
      bindActionCreators(
        {
          requestGetProfileInfo
        },
        dispatch
      )
    
    export default connect(mapStateToProps, mapDispatchToProps)(ProfileCard)
    

    코드를 보면 ProfileCardstore에서 profile 대상의 blogCount,tagCount,categoryCount와 하나requestGetProfileInfo 함수를 얻었는데 requestGetProfileInfo는 사실 바꾸는 데 쓰인다store.connect 함수는react-redux의 한 방법으로react와redux를 연결하는 데 사용되며, 이 함수를 호출하면 실제적으로 고급 구성 요소를 되돌려주고 내부는 많은 성능 최적화를 했다(주로shouldcomponentupdate 함수에 있다).
    CSS
    전단이 발전한 초기에 모두들 내용과 양식의 분리를 제창했다. 사실은 HTML과 CSS를 분리해서 쓰고 HTML에서 CSS 자원을 인용하는 것이다.
    그러나 전단이 발전함에 따라 부품화 개발이 점점 인정받는 것은 하나의 추세인 것 같다.그러나 전통적인 내용과 양식의 분리와는 어긋난다.구성 요소화 개발 방식에서 우리는 구성 요소의 내집성을 제창하고 이 구성 요소와 관련된 HTML, CSS, 자바스크립트를 함께 쓴다. 내가 보기에 이것은 구성 요소화 개발에 가장 적합한 문법이다.
    React에서 CSS를 쓰는 것은 사실 여러 가지 선택이 있다. 각각의 장점이 있겠지. 무와 채소는 각자 좋아하는 것이 있잖아. 하지만 내 눈앞에 보이는 것은 스타일드-components라는 라이브러리야. 그것도 CSS in JS의 일종이야.
    어셈블리의 내부 스타일
    const divStyle = {
      color: 'blue',
      backgroundImage: 'url(' + imgUrl + ')',
    };
    
    function HelloWorldComponent() {
      return <div style={divStyle}>Hello World!div>;
    }
    

    이것은 사실 HTML에서 내연 스타일을 쓸 때와 같다. 만약 구성 요소가 몇 가지 스타일만 수정하면 충분히 이 문법을 사용할 수 있지만, 많은 스타일을 쓰려면 사실 적합하지 않다고 생각한다.
    외부 스타일
    reboot.css
    *,
    *::before,
    *::after {
        box-sizing: border-box;
    }
    
    body {
        margin: 0 0 100px;
        padding-top: 50px;
    }
    
    a {
        text-decoration: none;
        cursor: pointer;
    }
    

    index.js
    import './reboot.css'
    

    페이지를 불러올 때, 바깥 스타일시트에서 찾을 수 있습니다.
    그러나 이렇게 쓰면 많은 문제가 존재한다.
  • 명칭이 충돌하기 쉽다
  • 구성 요소의 독립성이 떨어진다
  • 주문형 로드 불가
  • CSS in JS
    저는 개인적으로 스타일드-components를 좋아해요. 먼저 공식적인 예를 봅시다.
    //     Title         h1   ,         
    const Title = styled.h1`
      font-size: 1.5em;
      text-align: center;
      color: palevioletred;
    `;
    
    //     Wrapper         section   ,        
    const Wrapper = styled.section`
      padding: 4em;
      background: papayawhip;
    `;
    
    //     
    render(
      <Wrapper>
        <Title>
          Hello World, this is my first styled component!
        Title>
      Wrapper>
    );
    
    styled-components의 핵심 사상은 양식과 상응하는 구성 요소를 연결하여 CSS 양식 내용을 계산하여 내용 해시 값을 생성하고 이 값을 이 구성 요소className의 값으로 삼는 것이다. 이로써 명칭 충돌 문제를 완벽하게 해결했다.
    물론 styled-components의 강점은 여기에 그치지 않고 CSS 규칙의 계승, 확장, 부모 구성 요소에 따라 전달되는props 동적 계산 양식 등을 실현할 수 있다.
    CSS in JS는 새로운 선택인 것 같습니다. 저는 개인적으로 이런 문법을 매우 좋아합니다.

    좋은 웹페이지 즐겨찾기