슬라이드쇼 개발중.. on redgoose note

슬라이드쇼 개발중..

Nest: Blog Category: Diary 2021-04-26

슬라이드쇼를 라이브러리 사용하지 않고 순수하게 vue3로 개발작업 하고 있는데 크롬에서 이상하게 끊겨서 퍼포먼스 문제인가 싶어서 최적화 삽질을 하고 있었는데 webgl을 끄고 있었다. ㅋㅋㅋㅋ
켜니깐 무척 빨라짐 ;;;

그리고 슬라이드를 다른 라이브러리를 사용하지 않고 자체적으로 개발하고 있는것은 잘하는 짓이었다.
퍼포먼스면에서 대단히 민감한 부분이라서 몇시간 돌리는것도 염두해 둬야한다.

-2021-04-26-3-57-32-.png

UI를 완성된 형태로 항상 개발하다보니 보이지 않는 부분은 체크할 수 없기 때문에 감으로 예측해야한다.
이번에 약간의 css로 transform: scale(.2); 정도로 축소시키니 이렇게 좀더 넓은 부분을 확인할 수 있었다. 이 부분을 조절한 덕분에 어제 못끝냈던 부분을 수월하게 해결할 수 있었다.


vue3composition-api를 활용하면서 setup()메서드 속에서 컴포넌트의 코드가 다 돌아가게 된다.
이렇게 사용함으로써 타입스크립트를 제대로 사용할 수 있겠지만 처음 만드는 일에 방해말 되어서 타입스크립트를 또 지워버렸다. ;;
지금은 끈기있게 타입스크립트 이슈를 해결하면서 개발하는것보다 빠르게 코드를 작성할 수 있어야지 로직에 더 집중할 수 있었다. 타입스크립트에서 뭔가 문제가 일어나면 검색해보는데 100% 전부 해결되지도 않고, 해결하느라 걸리는 시간도 만만쟎고, 가장 스크레스를 받는것은 오늘은 잘 굴러가다가 다음날에 작업 시작할까 하면 타입에러가 왕창 떠버린다.

변수나 메서드를 사용하지 않는다고 경고가 아닌 오류가 발생해버리니 너무 가혹하다.(설정으로 끌 수 있겠지만 또 구글링하고 난리쳐야하는데 지쳐 버렸다.)

다시 setup()메서드 주제로 돌아가자면 state, computed, methods, lifecycles 개념을 동일하게 사용할 수 있지만 구조를 재조립할 수 있고, 같은 영역에서 자원들이 공유되어 사용하기 때문에 구조를 직접 설계할 수 있는 자유로움이 좋았다. 좀더 react같은 느낌을 받았다고 할 수 있다.

두번째 vue3 프로그램을 만들어보다보니 일단 안되는것이 없어 보이고, 좀더 익숙하게 사용할 수 있으니 전보다 코드가 더 정리되는 인상을 느낀다.

계속 사용해봐야 알겠지만..

Comments

  • 요즘 하루에 7,8시간 정도 슬라이드쇼 작업을 하고 있는데 진행 속도는 확실히 더디다.
    작은 부분들도 하나씩 만드는것도 있지만 지금 주요한 부분을 만들고 있다보니 코드를 작성했다 지웠다 반복하는것이 좀 많긴하다. ㅎㅎ

    구입한 게임도 있어서 게임에도 시간을 할애하고 싶었지만 여기에 열중하고 있다보니 어찌보면 게임보다 더 재미있는 상태에 빠져있다. --;

    매일 채굴 돌리면서 코인차트나 잠깐씩 구경하면서 몸이 못버틸때까지 프로그램 작성에 매달려 있는 기분이다. ;

    Written on 2021-04-26
  • 설정과 슬라이드 리셋 기능도 필요해 보인다.

    Written on 2021-05-03
  • 오토플레이 그래프가 있으면 어떨까..
    대기시간의 모습이 보이질 않으니 이게 제대로 돌아가고 있는지 확인이 안된다.

    꼭 필요한것은 아니지만 구현해두면 유용하지 않을까...

    화면에 요소가 계속 추가되는것이 부담스럽지만 맨 아래쪽 아니면 위쪽끝에 얇은 선을 넣어서 시간이 다되면 100% 사이즈로 나오게 하면 될거같다.

    Written on 2021-05-04
  • 슬라이드까지 구현모습인데 얼추 하는데까진 했다.

    Written on 2021-05-05
  • 가이드 페이지가 필요해 보인다. 도움말 용도로 사용할 수 있다. 슬라이드쇼 단축키나 환경설정 사용법이나 슬라이드 데이터를 삽입하는 방법을 알려주는데 사용할 수 있을것이다.

    가이드 버튼을 누르면 github에서 만든 별도의 페이지로 띄울 수 있겠지만 새로운 창을 열어서 사용하는건 이슈의 변수가 만들어질거라고 느껴져서 창을 띄어서 보여주는것이 좋을거 같다.

    Written on 2021-05-11
  • 슬라이드 데이터를 카테고리 방식으로 변경했다.
    하지만 환경설정에서 UI를 어떻게 짜야할지 아직 결정하지 못했다.

    기존 방식은 배열데이터 하나뿐이어서 배열 하나만 집중하면 그만이지만 이번에는 카테고리를 바탕으로 API주소와 배열이 복합적으로 사용될 수 있다.
    그래서 이에대하여 데이터 구조를 조정할 필요가 있다.

    Written on 2021-05-19
  • 데이터 설정화면의 고민

    카테고리에 따른 슬라이드 목록을 여러개를 둔 방식으로 슬라이드 트리가 변했다.
    슬라이드 데이터에 따른 기준은 key 값이다. 선택된 key의 이름은 category로 사용하고 있는데 이 부분을 중심으로 UI가 짜여져야 한다.

    중요한 점은 카테고리에 따라 슬라이드 배열 데이터일 수 있고, restAPI 주소일 수 있다.
    카테고리 목록이 상당히 많은 비중을 차지하고 있는데(갯수가 많아질수록..) 슬라이드 목록도 많아질수록 비중이 더 커진다.
    이걸 한 화면에 전부 담으려다 조작만 더 불편해질거 같아 보인다.

    창을 하나 더 띄우면 구조와 데이터의 모습을 분리할 수 있을거 같아 보이는데 작업이 많아질거 같고, 2중첩으로 창을 띄우는 모습이 되어버려서 좀 꺼리게 된다.

    소스편집의 위치

    소스편집 부분은 가장 마지막에 배치하는게 좋을거 같다.
    왜냐하면 데이터의 양에따라 크기가 유동적으로 변하기 때문이다.

    데이터 가져오기 부분 최소화

    데이터를 json 파일과 restAPI 주소를 통하여 트리 데이터를 가져올 수 있다. 그런데 이 부분의 공간을 많이 차지하는게 좀 부담스럽다. 그래서 최대한 숨겨놓고 사용하려면 툴바 형태로 만들어야 할거같다.

    그러면 툴바 형태로 만들어야 할것이다.
    툴바로 UI편집, 소스코드편집모드를 바꾸는 네비게이션과 데이터를 가져오는 폼을여는 버튼을 배치할 수 있을것이다.

    이러면 필연적으로 트리 데이터를 가져오는 폼은 새로운 창을 띄워야 할것이다. 이건 어쩔수 없어 보인다.

    Written on 2021-05-19
  • 데이터 편집모드

    아마 두가지 편집방식으로 나뉠 것이다.

    • advanced: 소스코드를 직접 편집할 수 있는 방식
    • basic: UI에서 직접 편집할 수 있는 방식

    이렇게 되는데 UI로 편집하는 방식은 빠르게 만들 순 없지만 라이트 유저를 위하여 언젠가는 꼭 만들어야 할거 같다.
    뭔가 뾰족한 수를 발견하지 못했는데 좋은 레이아웃을 찾아야 할것이다.

    Written on 2021-05-19
  • tree 데이터 구조 변경

    key 부분으로 그대로 사용하고 있었는데 좀더 확장을 할 수 있도록 조취해야겠다.

    {
      default: []
    }

    이런 형태였는데

    {
      default: {
        name,
        description,
        slides: [],
      }
    }

    형식으로 변경해야겠다고 생각된다.

    이런 형태로 두면 좀더 확장시킬 수 있다고 보인다.
    그런데 검증작업이 더 힘들어져서 이렇게까지 하고싶지 않았다..

    일이 더 커지는듯한 기분이..

    Written on 2021-05-22