반응형

일단 팝업 검색창을 띄울 레이어를 생성합니다.
간단하게 div 태그로 구역을 지정하고, style 을 설정하였습니다.

<div id="SearchLayer" style="position:absolute;z-index:999;display:none; width:100%; height:90%;
background: none rgba(0, 0, 0, 0.9);
filter: progid:DXImageTransform.Microsoft.Gradient(startColorstr='#80000000', endColorstr='#80000000');
" align='center'>
<table valign="middle" height=100%><tr><td >
<input type='text'><input type='submit'><br>
...
<br><br>
<font size='3' color='white' onclick='CloseSearch()'>Close</font>
</td></tr></table>
</div>

블로그에 적용하기 전에 테스트 코드로 짜서 테스트하느라, 실제 적용된거랑은 약간 차이가 있겠지요.
여기서 처음 접속시에는 보이지 않게하기 위해서 display:none; 을 지정하였습니다.

그다음 매번 클릭 시 나타났다, 없어졌다를 반복하기 위해서 해당 div를 제어하는 js를 작성합니다.

 

<script type="text/javascript">
function ViewSearch(){
        document.getElementById("SearchLayer").style.display='inline'
    }
function CloseSearch(){
        document.getElementById("SearchLayer").style.display='none'
    }
</script>

getElementById로 div 의 id를 찾은 후 style로 노출 유무를 지정해주시면 됩니다.
마지막으로 방금 만든 ViewSearch() 함수와 CloseSearch() 함수를 실행하는 부분을 작성해주시면 됩니다.
테스트할때는 그냥 a 태그로 했었고, 실제 적용에는 메뉴바에서 해당 함수를 호출하도록 해놨습니다.

<a href="javascript:ViewSearch();">HAHWUL_TEST</a>

실제 이런식으로 적용이 되었지요.



테스트 진행하며 만들었던 html 전체 코드입니다.

 

<html>
<head>
<title></title>
</head>
<body>
<script type="text/javascript">
function ViewSearch(){
        document.getElementById("SearchLayer").style.display='inline'
    }
function CloseSearch(){
        document.getElementById("SearchLayer").style.display='none'
    }
</script>

<div id="SearchLayer" style="position:absolute;z-index:999;display:none; width:100%; height:90%;
background: none rgba(0, 0, 0, 0.9);
filter: progid:DXImageTransform.Microsoft.Gradient(startColorstr='#80000000', endColorstr='#80000000');
" align='center'>
<table valign="middle" height=100%><tr><td >
<input type='text'><input type='submit'><br>
...
<br><br>
<font size='3' color='white' onclick='CloseSearch()'>Close</font>
</td></tr></table>
</div>
<a href="javascript:ViewSearch();">HAHWUL_TEST</a>
</body>
</html>

출처 : https://www.hahwul.com/2015/12/coding-htmljavascript-code-for-popup.html

반응형
반응형

Vuejs 로 작업중일때 router를 통해 화면을 다른 vue로 바꾸면서 Get/Post로 데이터를  보내고 싶을때가 있다.

이럴때 사용하면된다.

 

Send.vue ===> Receive.vue 로 이동하는 경우를 가정하자.

 

router.js

import Vue from "vue";
import VueRouter from "vue-router";

//vue router
Vue.use(VueRouter);

const routes = [
  { path: "/Send", component: require("./pages/Send.vue").default },
  { path: "/Receive", component: require("./pages/Receive.vue").default, name:"ReceiveTest" }
];

const router = new VueRouter({
  mode: "history", //removes # (hashtag) from url
  base: "/",
  fallback: true, //router should fallback to hash (#) mode when the browser does not support history.pushState
  routes, // short for `routes: routes`
});

export default router;

Post를 사용하기 위해서는 꼭 router에 name 값을 지정해줘야한다. 이유는 하단에.

 

Send.vue 의 script단

=> 데이터를 보내는 vue

//router.vue의 경로로 설정해주세요.
import router from "../../router";

export default {

//methods 부분만 기입하겠습니다. 필요한 곳에 click이든 event로든 사용하시면됩니다.
  methods: {
      GetTest(item) {
      //라우터에서 지정한 path 값
        router.push({ path: "/Receive", query: { id: "Get 확인" } });
      },
      PostTest(item) {
      //라우터에서 지정해준 name 값
        router.push({ name: "ReceiveTest", params: { id: "Post 확인" } });
      }
    }
}

 

Receive.vue 의 script단

==> 데이터를 받는 vue

export default {
  name: "Receive",
  data() {
    return {
    //Get으로 받았을 경우
     id: this.$route.query.id,
    //Post로 받았을 경우
     id: this.$route.params.id,
    };
  },
  created() {
  	//Get으로 받았을 경우
     console.log(this.$route.query.id);
    //Post로 받았을 경우
     console.log(this.$route.params.id);
  },
};

 

created 에서 받아 axios등으로 데이터를 불러와 세팅을해도되고

data 에 담아 필요한곳에 사용하면된다.

반응형
반응형

10 년마다 JavaScript에서 보호 기능이 변경됩니다. 나는 우리가 자바 스크립트  제 3의 시대 로 간주 될 수있는 가속화 된 변화의 기간을 막 시작했다고 생각한다 .

지금까지의 이야기 

1997 년부터 2007 년까지 JS의 첫 번째 나이 는 강타로 시작하여 m 소리로 끝났습니다. 여러분은 모두 Brendan Eich의 이야기를 알고있을 것입니다. Flash / Actionscript와 같은 폐쇄 된 생태계와의 강력한 경쟁 속에서 ES4 노력이 어떻게 왜곡되었는지는 잘 알려져 있지 않습니다. JS의 주요 이야기는 주요 저자 인 Brendan Eich와 Allen Wirfs-Brock의 JavaScript : The First 20 Years에서 더 잘 알 수 있습니다.

2009 년부터 2019 년까지 JS의 두 번째 나이는 2009 년  annus mirabilis 에서 시작하여 npm, Node.js 및 ES5가 탄생했습니다. Doug Crockford가 우리에게 좋은 부분을 보여 주면서 사용자는 JS 빌드 도구 및 라이브러리를 구축 하고 데스크톱 및 새로운 스마트 폰으로 JS의 범위를 확장했습니다. 2019 년에는 Facebook의 Hermes  같은 전화기  Svelte 3 과 같은 컴파일러의 첫 번째 프론트 엔드 프레임 워크 에서 JS를위한 특수 런타임이 등장했습니다 .

세번째 시대 

2020 년은 새로운 시대의 시작과 같은 느낌입니다. 1 세가 언어를 개발하는 것과 2 세가 사용자가 언어를 탐색하고 확장하는 것에 관한 것이라면, 3 세는 레거시 가정을 지우고 툴링 계층을 붕괴시키는 것입니다.

참고 : 전에 축소 레이어 논문을 발표했습니다!

해결되는 주요 레거시 가정은 일련의 타협으로 발전한 CommonJS에 대한 JS 에코 시스템의 의존성입니다. 그 대체품 인 ES Modules는 한동안 기다려 왔지만 기존 툴링은 느리지 만 "충분히"뛰어 나기 때문에 진정으로 도약 할 모멘텀이 부족했습니다. 프론트 엔드에는 최신 브라우저가이를 소량 처리 할 수있는 기능을 갖추고 있지만 중요한 세부 사항은 아직 해결되지 않았습니다 . 새앙 토끼 / 스노우 팩의 프로젝트는 ES 모듈 밖으로 흥분으로 사라질 수있는 외관을 제공함으로써 미래를 가속화하기 위해 배치됩니다. 최종 보너스로서, IE11은 올해부터 시작하여 2029 년  끝날 때까지 느린 행진을 시작할 것 입니다.

또 다른 가정은 JavaScript 도구가 JavaScript로 작성되어야한다는 것입니다. 핫 패스에서 타입 안전 및 10x-100x 성능 속도 의 가능성은 무시하기에는 너무 큽니다. "JS의 JS를위한"이상은 TypeScript가 JavaScript를 거의 완전히 인수함으로써 없어졌고 이제 Deno와 Relay는 사람들이 Rust를 배우고 핵심 JS 도구에 기여할 수 있음을 입증하고 있습니다. Brandon Dail 은이 변환이 2023 년까지 완료 될 것으로 예상 합니다. 접근성이 성능을 능가하는 대부분의 주변 툴링에 대해 JavaScript 및 TypeScript를 계속 작성합니다. " 기능적 코어, 명령형 쉘 " 에 대해 생각하던 곳에서 이제 " 시스템 코어, 스크립팅 쉘 "로 이동하고 있습니다.

참고- 이것은 논쟁의 여지 가 있으며 Python의 PyPy는 이것이 확실한 결론이 아니라는 것을 나타냅니다 .

레이어는 흥미로운 방식으로 무너지고 있습니다. Deno는 완전히 새로운 런타임을 작성하는 급진적 인 접근 방식을 취하여 테스트, 서식 지정, 보푸라기 및 하나의 바이너리로 묶기, TypeScript 말하기 및 표준 lib 포함과 같은 작업을 수행하는 일반적인 도구 모음을 접습니다 . 로마는 다른 압정을 취해 Node.js 위에있는 모든 레이어를 무너 뜨립니다 (내가 아는 한 너무 가까이 있지는 않습니다).

10 년 전에 존재하지 않았고 지금은 삶의 사실은 퍼블릭 클라우드 (AWS, Azure, GCP 등)입니다. 자바 스크립트는 클라우드와 흥미로운 관계를 맺고 있습니다. 클라우드 플랫폼 개발자는 10 피트 폴로 JS를 건드리지 않지만 JS는 가장 큰 소비자입니다. AWS Lambda가 먼저 JS와 함께 시작되었습니다. 또한 IDE와 클라우드 사이에서 계층을 축소하고 그 사이에서 성가신 랩톱을 제거하는 명확한 이동이 있습니다. Glitch, Repl.it, Codesandbox, GitHub Codespaces , Stackblitz 등은 JS를 활용하여이 공간을 탐색하는 모든 Cloud Distros 입니다.

프론트 엔드 프레임 워크에서도 진행중인 활동은 흥미 롭습니다. Svelte 는 애니메이션에서 상태 관리에 이르는 모든 것을 컴파일러로 축소했습니다 . React는 메타 프레임 워크  클라이언트-서버 통합을 탐색 하고 있습니다. 그리고 Vue는 Vite라는 "unbundler"dev 서버 프로젝트를 진행하고 있습니다.

요약 : Third Age JS 도구는

  • 더 빠른
  • ESM 우선
  • 접힌 레이어 (한 가지 일을 잘하는 것보다 많은 일을 잘하는 것)
  • Typesafe-er (핵심에 강력한 형식의 언어로 구축되고 구성이 0 인 사용자 코드에서 TS 지원)
  • 보안 성 (종속성 공격 또는 느슨한 권한)
  • 폴리 글롯
  • Neo-Isomorphic (대부분은 아니지만 대부분의 경우 JS가 빌드 타임 또는 서버 측에서 클라이언트에 도달하기 전에 먼저 실행되어야 함을 인식)

이 모든 작업의 ​​결과는 더 나은 개발자 경험 (빠른 빌드, 업계 표준 툴링) 및 사용자 경험 (더 작은 번들, 더 빠른 기능 전달)입니다. 사이트 스크립팅 토이 언어에서 전체 애플리케이션 플랫폼에 이르기까지 JavaScript의 최종 변형입니다.

자바 스크립트의 죽음? 

경우 게리 베르나르의 예측이 성립 , 세 번째 시대는 자바 스크립트의 마지막 (자신의 타임 라인 2035까지 JS를 제공) 할 수있다. 브랜든 아이 히 (Brendan Eich)조차도 "JS와 WASM에 항상 배팅하라"는 그의 유명한 말을 피봇했다. 그는 원래 JS가 "범용 가상 머신" 이라고 생각 했지만 WASM이 이제 그 아이디어의 궁극적 인 성취 라고 한 번 말했습니다 .

 

 

원문 : https://www.swyx.io/writing/js-third-age/

반응형
반응형

v-for을 사용하다보면 생각보다 요놈이 문제 많은 녀석이라는걸 느낄 때가 있다.

그런데 국내나 해외나 이 v-for에 대해서 제대로 적어놓은 녀석이 별로 없는거 같다.

그냥 불편해도 사용하는건지...

사용시 주의를 요하는 녀석인데 그 이유에 대해서 논해보도록 하자.

 

 

코딩을 하다보면 v-for은 안쓸래야 안쓸 수가 없다.

굉장히 좋은녀석이지만 몇가지 문제점이 존재한다.

 

일단. v-for은 해당 데이터의 길이가 0이면 그리지 않는다.

그래서 굳이 v-if를 달 필요가 없다는건 장점이다.

 

하지만 문제는 길이가 가변할 경우이다.

 

대부분 v-for의 문제는 가변하는 길이에서 오는 것이다.

v-for에서 데이터를 처리하는 방식은 아래와 같다.(완벽하게 같지는 않고 얼추 맞음)

 

1. data의 길이가 0(혹은 초기화)에서 n의 길이가 되었을 경우 n개의 컴포넌트를 만들고 dom으로 바꾼다.

2. 1번 이후 당연히 컴포넌트는 새로 만들어졌으므로(dom으로 인스턴스화 됬으므로) created와 mounted 이벤트가 발생

3. data의 길이가 n개에서 m개로 증가 되었다.(m은 n보다 크다)

4. 3번 이후 컴포넌트가 추가되었지만 기존의 dom자체를 파기하지는 않고 적절히 순서를 유지한다.(새 데이터가 앞일지 뒤일지 중간일지 모르므로)

5. 데이터가 당연히 추가되야하므로 m-n개 만큼 추가로 dom을 생성한다 당연히 추가로 생성된 컴포넌트는 created와 mounted가 발생한다. 

 

여기서 눈여겨 볼것은 데이터가 추가되었을 때 기존의 dom을 파기하지 않는다는것, 이말은 기존의 컴포넌트를 파기하지 않는다는 말과 동의어다.

 

그렇기 때문에 데이터가 늘어나서 추가로 돔이 생겨도 기존의 dom이 파기되지는 않았으므로 이벤트는 발생하지 않는다.

싹 재 렌더링을 하지 않기 때문에 당연히 성능이 상승하게 된다.

 

여기서 문제점이 발생하는 경우가 많다.

 

이 때 발생하는 문제점

 

일단 이 문제점 보다 이번에는 key에 초점을 맞춰보도록 하자.

 

이 때까지 위의 이야기는 다 key의 역활을 말하기 위해서 한것이다.

4번에 dom자체를 파기하지 않고 적절한 순서를 유지하는것은 바로 key때문에 가능하다.

데이터가 다시 업데이트 될 때 가상돔과 돔의 key를 비교한다.

key가 지정되어있다면 이 key를 통해서 특정 녀석을 "재 렌더링 할지"정하게 된다.

key가 없다고 반드시 재 랜더링을 하는것은 아닌거 같다.(필자의 테스트결과)

하지만 key가 겹치게된다면 매우 높은 확률로 재 렌더링을 한다는 것이다.

 

※아 그리고 key가 없으면 인덱스를 그냥 key로 넣는다는 주장이 있다. 주장인데 신빙성은 있는 듯.

 

이는 몇가지 테스트를 통하여 확인하였다.

 

테스트 조건은 아래와 같다.

 

데이터 앞에 신 데이터 끼워넣기

 

1. 크기와 색, 위치는 렌덤인 div에 숫자를 넣는다. 갯수는 1만개이다.

2. 3초후에 1만개의 div를 추가적으로 기존 데이터의 앞에 추가한다.(즉 배열은 2만개가 되고 앞의 1만개는 신데이터, 과거 1만개는 구데이터)

3. 그 후 과거 1만개가 생성된 직후에서 새로 1만개가 생성된 직후의 간차이를 계산한다.

4. 3개의 대조군을 만드는데 하나는 key가 없는 녀석, 하나는 key가 있지만 중복이 발생하는 녀석, 하나는 key가 있고 유니크한 녀석이다.

 

이렇개 개발자 도구 켜서 총 걸리는 시간을 확인하겠다는 뜻이다.

 

 

그럼 실험 결과를 공개하겠다. 단위는 초이다.

 

key가 없는 경우 => 3.92 3.81 3.92 3.94 4.10

key가 있지만 유니크하지 않음 => 3.68 3.77 3.63 3.66 3.72

key가 있고 유니크함 => 3.55 3.47 3.58 3.58 3.36

 

평균을 내보면

 

key(없음) = 3.93

key(중복) = 3.69

key(유니크) = 3.5

 

키가 없는것 보다는 중복되더라도 있는게 빨랐고 중복된것보단 유니크한게 빨랐다.

하지만 여기서 함정이 있는데 위의 경우에는 데이터의 순서가 유지가 됬기 때문에 중복이 되어도 재 렌더링이 거의(혹은 전혀)일어나지 않는다.

아마 vue에서 과거데이터와의 대조를 통하여 key가 없어도 어느정도 캐싱효과를 보장해주는것 같다.

일반적인 경우에는 중복된다면 없는게 더 나은데 그 이유는 아래를 보면 알 수 있다.

실험 방식을 약간 바꿔보자.

 

과거 데이터와 신 데이터를 교차로 섞기

 

1. 크기와 색, 위치는 렌덤인 div에 숫자를 넣는다. 갯수는 1만개이다.

2. 3초후에 1만개의 div를 추가적으로 기존 데이터와 셔플하듯이 사이에 교차로 추가한다.(즉 배열은 2만개가 되고 앞의 1만개는 신데이터, 과거 1만개는 구데이터)

3. 그 후 과거 1만개가 생성된 직후에서 새로 1만개가 생성된 직후의 간차이를 계산한다.

 

4. 3개의 대조군을 만드는데 하나는 key가 없는 녀석하나는 key가 있지만 중복이 발생하는 녀석하나는 key가 있고 유니크한 녀석이다.

 

이 경우 어떻게 될까?

놀랍게도 결과는 이상하게 전개된다.

 

key가 없는 경우 => 3.99 4.00 3.88 4.01 4.04

key가 있지만 유니크하지 않음 => 5.7 5.53 5.10 5.23 5.29

key가 있고 유니크함 => 3.60 3.58 3.63 3.56 3.63

 

평균을 내보면

 

key(없음) = 3.98

key(중복) = 5.37

key(유니크) = 3.6

 

오히려 키가 중복될 때 성능이 눈에 띄게 하락하는 것을 확인할 수 있다.

그 이유는 제랜더링이 눈에 띄게 많이 일어나는데 이는 아래의 그림을 보면 알 수 있다.

 

사진속 마우스 커서가 새로 고침을 누른 시점에서 확인하라!

 

key가 없는 경우이다.

 

key가 있고 중복되지 않는 경우이다.

 

key가 있는데 중복되는 경우이다.

 

뭔가 차이가 느껴지는가?

위의 둘은 기존 컴포넌트(돔)이 사라지지 않고 추가만 됬지만 key중복이 있는 경우 몇개는 없어지고 재 렌더링이 된다.

일종의 캐싱 효과를 못 받는걸로 해석된다.

 

애당초 key가 중복된다는 것은 일종의 버그이다. "특정 상황에서 key가 있을 때 없을 때"의 성능이 다르긴하지만

그걸 논하는건 무의미하며 정의된 스펙이 아니다. 따라서 그냥 key는 유니크하게 만들어야한다.

 

결론

 

1. key는 성능에 영향을 확실하게 미친다.

2. key가 없는 경우 데이터가 삽입 정도와 정렬정도에 따라서 캐싱효과를 보고 못보고가 결정된다.

3. key가 중복되는데 캐싱을 못볼경우 그냥 재 렌더링 해버리는데 그 사이드 이펙트가 클 수도 있다.

4. key를 쓸꺼면 아예 중복안되게 key를 만들고 안 쓸거면 그냥 쓰지 않는게 낫다.

 

결론 중의 결론

 

그냥 key쓰세요. 아 그리고 무조건 유니크하게

 

key가 없을 때는 사실 필자가 테스트할 땐 제 랜더링이 일어난 적이 없는데 더 뚜렷하게 아시는 분이 알려주시면 감사하겠다.

 

출처: https://kamang-it.tistory.com/entry/WebPerformanceVue-vfor%EA%B3%BC-key-%EA%B7%B8%EB%A6%AC%EA%B3%A0-%EC%84%B1%EB%8A%A5%EC%82%AC%EC%9D%B4%EC%9D%98-%EA%B4%80%EA%B3%84

반응형

+ Recent posts