Svelte 운영 웹 응용 프로그램에서 IPFS 기능 구현

이 글은 js-ipfs에 대한 설명이 충분하지 않습니다.상세한 상황은 아래의 보도를 참고할 수 있다.
지난 9월 시선을 움직이지 않고 쉽게 읽을 수 있는 오픈소스 도구'Svelte Shield(전신: Riot Shield)가 공개됐다.
아래와 같이 텍스트를 입력하고 재생 버튼을 누르면 상자 안에 분할된 텍스트가 재생됩니다.

이 응용 프로그램의 한 기능으로 분포식 파일 시스템의 IPFS와 연합하여 다른 사람과 공유할 수 있는 본 기능, IPFS 본 모델을 추가했다.
지금까지는 매번 읽을 텍스트를 붙여야 했지만 이를 통해 URL을 공유하면 다른 사람들도 같은 글을 읽을 수 있다.
다음은 위키백과'수면'글을 라이센스에 따라 옮겨 싣는 페이지입니다.

※ 페이지를 열어도 데이터가 있는 Peer를 찾는 데 시간이 걸리거나 찾을 수 없습니다.양해해 주십시오.🙇‍♀🙇
등록서에서 공유까지의 구체적인 데이터는 대체로 다음과 같다.
* アプリの初期化時に IPFS node を立ち上げる
* アプリ画面から入力した本のデータを、上記 IPFS node に追加する
* ページを開いている間は、本データが共有可能になる
* 返ってきた hash を URL の一部に入れ、本詳細ページを開く
* 上記 URL を他者に共有する
* 画面を開くと、 IPFS ネットワーク上で該当の hash を持っている Peer を探索する
* Peer が見つかればダウンロードを開始し、本を表示する
IPFS 또는 JS IPFS 에서 더 자세한 문서를 읽을 수 있습니다.
또 탭#IPFS 본에서'트위터'버튼에서 공유된 책의 일람을 볼 수 있다.
오프닝은 여기까지 하고 Svelte로 넘어가겠습니다.

Svelte에서 가장 공을 들이는 곳.


이번에는 구성 요소의 폴더 구조에 공을 들였다.원본src/components/ 산하, 아래 구성으로 제작
  • containers/ - 레이아웃 상태만 관리하는 구성 요소 그룹
  • parts/ - 모양새만 담당하는 어셈블리 그룹
  • routes/ - 페이지당 입구점
  • App.svelte - Svelte 포털 지점
  • 이번부터 페이지도 추가되었고 다음과 같은 구성으로 containers/ 넣은 구성 요소의 종류를 다시 만들었습니다
  • !Common/ -> 페이지 전체에 공통된 구성 요소 그룹
  • Home/ -> 홈 페이지에서만 사용되는 구성 요소 그룹
  • Books/ -> 이 요약 페이지에만 사용되는 구성 요소 그룹
  • Book/ -> 이 세부 정보 페이지에서만 사용되는 구성 요소 그룹
  • containers/ 속은 캐릭터, 그룹 이름에 따라 폴더를 만들지만 "이 Component는 아무리 생각해도 이 페이지에서만 사용"하는 경우가 늘어나면서 크로스 페이지에서 사용하는 물건, 그 페이지에서만 사용하는 물건을 분리하고 공동 폴더와나는 모든 페이지 폴더를 준비했다.공용 폴더에 ! 를 넣는 이유는 파일을 배열할 때 가장 먼저 나타나는 문자와 공용 폴더를 강조하고 싶은 두 가지 의미를 포함하고 있기 때문이다.
    또한router 등 Component 상부에서 복잡한 코드를 사용하지 않고 평탄하게 배열하여 utils 함수 폴더와 하위 구성 요소에서 필요한 처리를 하도록 노력합니다.이 일람 페이지의 루트 파일 같은 것은 평탄화되어 예비 지식이 없어도 직관적으로 쉽게 읽을 수 있다.
    https://github.com/ampcpmgp/svelte-shield/tree/master/src/components/routes/Books.svelte

    Svelte에서 가장 고전하는 점.


    이번에는 환경 설정 주변, 특히 Svelte 파일의 자동 형식에 가장 열중합니다.이 개발을 진행하기 전에 lint-staged에commit를 걸 때 lint&format을 걸었지만 이렇게 하면 체감상 제출이 느리고 좋은 방법이 없다는 느낌이 뚜렷하다.VScode 확장 기능Svelte for VS Code에서 하고 싶은 일을 하고 싶은데 공식 문서에 따라 자동 형식을 설정해 봤는데 도저히 못하겠어요.
    VScode 사용자 설정에는 다음과 같은 설정이 필요합니다.
    {
        "eslint.validate": [
            "javascript",
            "svelte"
        ],
    }
    
    다양한 issue를 탐색하고 잘못된 설정을 반복했기 때문에 이것에 도착하는 데 많은 시간이 걸렸다.경쟁적인 Svelte 확장 기능을 포함하여 문제를 해결하는 데 시간이 걸리는 주요 원인이 될 수 있습니다.

    Svelte 재사용


    아무튼 편하게 썼어요.이번에는 비교적 큰 증강이기 때문에 전체적인 구조를 재검토하면서 재구성을 했지만 Svelte의 코드 전망이 매우 좋아서 신선한 공기를 자주 마시는 것 같다.
    그리고 내가 Svelte를 과소평가한 것 같아.즉, 저는 Svelte & JavaScript가 유지보수성에서React & TypeScript보다 훨씬 나쁘다고 생각합니다. 업무 중에도 이런 건의를 여러 번 했습니다.
    Svelte는 대량의 관련 라이브러리가 없지만 라우터 등 최소한의 물건은 모두 갖추어져 있다.그리고bind:thissvelte:window 등은 브라우저 API를 쉽게 터치할 수 있다.대량의 프로그램 라이브러리를 사용하면 대부분 어떤 문제가 생기거나 Stack Overflow에서 issue를 찾거나 Stack Overflow에서 문제를 찾지만 프로그램 라이브러리의 사용을 최대한 줄여야 한다. 특별한 일을 하고 싶을 때 브라우저 API를 사용하면 브라우저의 규격에 직면할 수 있다wrap을 사용하는 라이브러리에 비해 브라우저에 대한 이해도 깊어져 근본적인 해결 방안을 향해 움직이기 쉬워졌다.
    또 유형 정보가 없어도 어느 정도 상쇄할 수 있는 장점을 느낄 수 있다.
    금형을 사용하면 안전성이 틀림없이 높아질 것이다.현재 Svelte & JavaScript 개발에서 실행할 때까지 형식을 잘못 지정한 적이 몇 번 있습니다.실행하기 전에 아는 것이 즐겁기 때문에 분명히 단점이다.다만, 금형을 만들기 전에 간결하고 알기 쉽게 코드를 쓰는 중요성을 느꼈고, Svelte는 그것을 더욱 쉽게 달성할 수 있도록 했다.편집기와 묶음 도구의 유형 검사도 간소화되고 저장에서 반영까지의 시간 체감도 빨라진다.
    유행이냐 안 유행이냐가 아니라 좋은 것을 보면 새로운 안건에서 채용의 가치를 충분히 고려한 것 중 하나라고 다시 한 번 생각합니다.

    전체 개발 검토


    이곳에서는 깊은 접촉을 할 수 없지만 필요조건 정의에 고전하고 있다.IPFS처럼 지금까지 사용한 적이 없고 설치에 미치는 영향이 큰 물건은 여러 차례 필요 연구와 기술 조사를 오가며 애초의 필요 조건을 근본적으로 바꿨다.
    설치 과정에서도 미세한 변경과 예상치 못한 불일치를 볼 수 있어 다시 섞는 작업은 힘들지만 Svelte는 따라가기 쉽다는 느낌이 든다.요구의 변경에 대해 지금까지도 강렬한 인상을 가지고 있다.
    앞으로도 대규모 개발에 도전하고 싶다.

    끝날 때


    이 IPFS 책은 학문과 교양의 공공재산화를 목표로 다양한 용도에 대응하고자 합니다.다음은 IPNS와 협력하여 업데이트할 수 있는 책꽂이 기능도 연구하고자 합니다.
    질문과 기능 요구가 있으시면 여기 댓글과 Github Issue 등으로부터 꼭 연락 주세요.🙇‍♀🙇
  • Repository - https://github.com/ampcpmgp/svelte-shield
  • Twitter - https://twitter.com/am_nimitz3
  • 끝까지 읽어줘서 고마워요.

    좋은 웹페이지 즐겨찾기