20210221のvue.jsに関する記事は6件です。

初心者がRailsとVue.jsでポートフォリオを作成してみた

こんばんは
アロハな男、やすのりです!

私は、自身のポートフォリオとして『Vue.js』と『Rails』を使用した、SPAアプリを作成しました。

この記事ではポートフォリオの内容や、実際に様々な機能実装をする上で『工夫したこと・苦労したこと』や、Webアプリ開発を通しての感想等をお伝えしていきたいと思います!

アプリ概要

一言で説明すると、ハワイに特化した『じゃらん』や『一休.com』 です。

Image from Gyazo

今のご時世では気軽に旅行することも難しいのですが、私自身や周りに旅行することが好きで、特にハワイが好きな方々がおり、実際に旅行した際の思い出やおすすめのお店等を共有し合うことがありました。

そこで、自身の思い出の場所やおすすめ店等を共有したいと思い、様々なサイトを探してみましたが、『管理人のおすすめ店をランキング形式で紹介』というものが多く、おすすめの場所が複数ある場合は、その分複数のサイトを共有しながら話し合うという様な形でした。

そういった経験から『もし、ハワイのお店やアクティビティ等がまとめられ、口コミ等でユーザーの評価がわかる様なサイトがあればお気に入りの場所もおすすめしやすくていいな』という想いから、このアプリを作成することにしました。

また、アプリ作成をする上で『説明がなくてもユーザーが使える見た目』であることや『ユーザーとしてアプリを使用する上で欲しい機能』を常に考え、『ユーザーが使いやすいアプリ』をコンセプトにアプリを作成しました。

下記ページにて公開中ですので、よろしければ実際に触ってみてください!
https://www.lets-enjoy-hawaii.com

使用技術等

  • フロントエンド
    • Vue.js 2.6.12
    • Vue Router
    • axios
    • JavaScript
    • HTML / CSS
    • Haml / SCSS※Vue.jsの導入に伴い使用中止
    • jQuery※Vue.jsの導入に伴い使用中止
  • バックエンド
    • Ruby 2.6.5
    • Rails 6.1.2.1
  • テスト
    • Rspec
    • FactoryBot
    • faker
    • rubocop
  • インフラ
    • AWS (VPC, EC2, S3, RDS, Route53)
    • https化
    • Nginx / Unicorn
  • ソースコード管理
    • GitHub

機能一覧

以降では、主要機能の詳細や工夫点等について紹介させていただきます!

入力フォームの入力不備表示機能

機能詳細
入力フォームの各項目に対して、モデルのバリデーション設定に反した入力がされるとエラーメッセージが表示され、入力欄の表示が変更されます。
※バリデーション設定に沿った入力がされた段階で、エラーメッセージや入力欄の表示が元に戻ります。

Image from Gyazo

工夫点

①入力不備の場所を判断できる様にする

入力項目が複数あるため、エラーメッセージを表示しただけでは、どの入力欄で入力不備が起こっているのか判断がつけづらいと考え、入力欄自体の表示も変更することにより、どの入力欄で不備が発生しているのかがすぐ判断できる様にしました。

②入力不備が解消されたかどうか一目でわかる配色にする

ページに使用している配色とは異なった色で入力不備の表示をすることにより、入力不備が解消されているかが一目でわかる様にしました。

会員登録済みメールアドレスお知らせ機能

機能詳細
会員登録時に入力されたメールアドレスが既に登録済みか判定し、登録済みであればエラーメッセージを表示させ、別のアドレスを入力するか、ログインを試すかを促す様にしています。

Image from Gyazo

懸念点

ユーザー登録数が増えてきた場合の処理速度問題

メールアドレスの入力がされ入力欄からフォーカスが外れた際に、axiosを使用した非同期通信を行い、メールアドレス判定用メソッドへリクエストを飛ばします。
現在は登録数が少なくレスポンスも早いですが、登録数が膨大になった際は時間がかかってしまうことが考えられますので、判定中なことをアイコンで表示させる等の処理が必要そうです。

詳しいコード解説等は別記事にて紹介しています。
RailsとVue.jsでメールアドレスが登録済みか判定する方法

登録済みのお気に入り・訪問記録へのメモ書き機能

機能詳細
登録済みのお気に入り訪問履歴に対して『〜が美味しかった!』や『次は〜動物をメインに見たい』等のコメントを、メモ書き感覚で保存することができます。

Image from Gyazo

工夫点

保存ボタンを押すことにより、コメント保存がされる様に設定

最初は各お店等へコメントでのメモ書きをする際に、『保存ボタン』をクリックしなくても、入力欄のフォーカスが外れた段階で保存処理をかければ、ユーザーの手間が1つ減るのではないかと考えていました。
しかしその仕様にした場合、『入力したけど、元々残していたメモ書きの方がやっぱりいい』や『誤ってメモ書きを削除してしまった』等といった場合に対応できないと考えを改め、『保存ボタン』も一緒に実装しました。

地図検索時、選択場所の表示変更機能

機能詳細
トップページの『地図から探す欄』と『島名から探す欄』にて島名等をホバーすると、対応した地図上の島の表示が変更されます。

Image from Gyazo

工夫点

①選択している島を視覚的にわかる様に設定

最初は地図上をホバーしても、マウスの表示が変わって地図を選択していることをお知らせしているだけでした。
しかし、地図上の表示も合わせて変更することによって、実際にユーザーが選択している箇所を把握することも容易になるのではないかと考え、地図上の表示変更機能を実装しました。

②島名にどこの島が対応しているのかわかる様に設定

島名検索をする際に、『オアフ島やハワイ島は聞いたことがあるけど、実際地図上ではどこになるんだろう』という声をいただき、実際に島名選択時にどの島と対応しているのかを地図表示を変更することでわかる様に設定しました。
これによって、『今回はオアフ島へ旅行に行くから、その横の島も時間があれば観光をする予定を立てよう』等の新たな計画を立てることもできるのではないかと思っています。

検索結果の並び替え機能

機能詳細
並び替え欄にある口コミランク順等をクリックすることで、表示されているお店等の検索結果一覧の並び替えをすることができます。

Image from Gyazo

工夫点

①初期状態の並び順をお気に入り数の多い順に設定

ユーザーが目的の場所を検索する際に評価の高い場所を優先的に見ていくと考え、口コミランク順かお気に入り数の多い順のどちらかを初期状態にしようと考えました。
その際に、『口コミ投稿をするより、お気に入りボタンを押す方が簡単でユーザーが使用する割合が高い』と考え、口コミ投稿に影響される『口コミランク順』ではなく、お気に入り数順を初期状態とすることにしました。

②並び替えボタンに使用頻度が高そうなものを用意

ユーザーが実際に並び替えをしたい項目にどういったものがあるかと考えました。
その際に『口コミランク順』と『お気に入り数順』は①でも説明した様に、ユーザーは評価の高いところを知りたいのではないかと思い、追加しました。
そして更に『口コミ数が多く、その場所に対しての感想が多い方が、よりその場所へのイメージがしやすい』のではないかと考え、『口コミ数順ボタン』を実装しました。

お店等への画像投稿機能(複数枚投稿可能)

機能詳細
お店等への口コミと一緒に、写真を投稿することもできます。
1回の投稿につき複数枚選択していただくことができ、現在どんな写真を選択しているのかをプレビューすることもできます。
そして、写真削除ボタンをクリックすることで、クリックした画像を選択画像から除外することができます。

Image from Gyazo

工夫点

写真削除ボタンをホバーした際に、ホバーした写真削除ボタンの表示を変更する。

写真を複数枚プレビューさせるためにVue.js上で繰り返し処理を行い各要素を表示させているため、そのままmouseoverイベントを発火させてしまうと、全ての写真削除ボタンの表示が変更されてしまう状態になっていました。
なので、削除ボタンにref属性を付与して、繰り返し処理のindex番号を与え、そのref属性とindex番号でホバーした要素を判断し表示を変更させることができました。

棒グラフ表示機能

機能詳細
お店等へ投稿された口コミの評価点の分布を、棒グラフで表示させています。
また、口コミが投稿されるとパーセントも更新され、グラフの表示も変動します。

Image from Gyazo

工夫点

パーセント表記に小数点を使用しない

各評価点のパーセンテージを計算した際に、どうしても割り切れず小数点が発生してしまいましたが、表示上はすっきりさせている方が見た際にわかりやすいと考え、小数点以下は四捨五入し表示をさせています。

Google APIを使用したお店等の画像取得機能

機能詳細
今のご時世ですので、実際に現地に行かなくても、お店の画像を取得し使用することができる『Google Street View API』を使用しました。

Image from Gyazo

問題点

①全ての場所は対応していない

画像自体はGoogle Streetにあれば取得することができますが、そもそもショッピングモールの中のお店等は表示されなかったりするので、画像が取得できずに掲載できないお店等も存在します。

②データベースに保存するカラムが増える

『Google Street View API』を使用するために、該当場所の座標等の情報をデータベースに保存しなければならないため、1つのレコードに使用される容量が増えてしまう。

以上のことから、可能であれば少しずつでも実際に現地で撮影した写真等を入手する必要があると考えています。

追加実装予定

GithubのIssuesに、実装内容と目的をまとめています。
https://github.com/Yasunori-aloha/lets-enjoy-hawaii/issues

ポートフォリオ開発で苦労したこと

特に苦労したことは、フロント部分とバック部分との連携でした。

当初はRailsだけで開発しており、フロント部分もRailsのビューを使用し実装していました。
しかし、現在主流なのは『フロント部分はVue.jsやReact等のJavaScriptフレームワークを使用してバック部分と切り分けて実装されるアプリケーション』であることや『フロントとバック両方の知識・技術があれば、実務に入った際のフロントとバック両チームのコミュニケーションの架け橋になれるのではないか』と考え、フロントをVue.jsへ切り替えを決心しました。

しかし、1度完成させていたものを新たに『APIモード』として作り替えるために、

  • APIモードでの必要情報の取り出し方
  • ビューをVue componentsとして移行

等々を新たに学習し直して、実装する必要がありました。

参考文献も少なく、スクール等では学べない内容でしたので、自分自身の成長により繋がったのではないかと思います。

ポートフォリオ開発を通しての得たもの

  • 自走力
    Railsだけでポートフォリオ完成させた段階では、どうやってVue.jsを連携させればいいのか全く知識がなかった状態からのスタートでしたので、導入の部分から実装部分に至るまで様々なエラー・不具合に遭遇してきました。
    しかし、Udemyの教材等を活用し、基礎的な内容から実践的なものまで学習を続けたことで、学習開始からポートフォリオへの導入まで約1ヶ月でVue.jsを実装することができました。
    そして、そのほとんど全てのタスクを自力で実装することができるまでになっていました。

  • デバック力
    ポートフォリオを作成する中で、様々なエラーに何度も遭遇してきました。
    ですが、その度にbinding.pryやdebugger等のデバックツールを使用して、『どこまで自身の想定内の動作をしているのか?』を明確にし、エラーの原因を絞り込み特定し解決、というサイクルを何度も経験し乗り越えてきました。
    今では、エラーに遭遇しても『今回はどういった理由でエラーが出てるのかな?』と、原因特定するこのサイクル自体を楽しんでいる自分がいました。

  • とにかく楽しむこと
    このポートフォリオを作成する中で、実装したい機能を実現するための方法を考えたり、考えたロジックをコードに落とし込んだり、エラーが発生した箇所はデバックをすることで原因を追及し解決する。
    こういった開発の流れ全てを楽しみながら開発を続けることができました。
    RailsだけでなくVue.jsも取り入れることで『フロント側ではこの情報が必要だからレスポンスで渡せる様にしよう』と考えたり、『バック側の処理でこの値が必要だからリクエストで送ってあげよう』と考えながら実装していくことでお互いの知識・技術も向上され、更にお互いのことを考えるための思考も養われたのではないかと思います。

最後に

ポートフォリオ開発を通して1番はじめに思い返されるのが『楽しくすることができた』ことです。
特に新たに実装したい機能が浮かんできて、その機能を実装するための方法を考えて、様々な教材で学習し実際に機能を実装できた時はとても大きな感動と達成感があったことを覚えています。

開発を始めたばかりの頃は、わからないことも多くエラーや実装方法で苦労することも多々ありましたが、実際に当初自身で実装したいと思っていた機能が実装することができて本当に良かったと思います。

まだまだ、開発過程で実装したいと思った機能がありますので、これからもアップデートを続けて、よりユーザーの使いやすいアプリケーションにできる様、そして自身の知識・技術が向上できる様に学習を続けていきたいと思います!

長い記事となってしまいましたが、ここまでご覧くださりありがとうございました!
もし、この記事ひいては開発したアプリケーションが皆様のお役に立つことができたのなら幸いです。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

JavaScriptでcsvダウンロードを実装する方法

はじめに

フロント(React)でcsvダウンロードを実装する機会があったため、備忘録です。
どうぞご活用ください。

実装

  const handleDLcsv = async () => {
    //アイテムの定義
    const download_items = [
            {'id': 1, 'name': 'apple', 'price': 100},
            {'id': 2, 'name': 'orange', 'price': 120},
            {'id': 3, 'name': 'melon', 'price': 800}
    ];
    //csvヘッダー
    const array_data = [['id', 'name', 'price']];

    //文字コード
    const bom = new Uint8Array([0xEF, 0xBB, 0xBF]);

    //csv用データ作成
    download_items.map((item) => {
      const item_data = [item.id, item.name, item.price];
      array_data.push(item_data);
    })
    let csv_data = array_data.map(function(l){return l.join(',')}).join('\r\n');

    //BLOB生成してダウンロード実行
    const blob = new Blob([bom, csv_data], { type: 'text/csv' });
    const url = URL.createObjectURL(blob);
    const a = document.createElement('a');
    a.href = url;
    a.download = 'csv_file.csv';
    const clickHandler = () => {
      setTimeout(() => {
        URL.revokeObjectURL(url);
        a.removeEventListener('click', clickHandler);
      }, 150);
    };
    a.addEventListener('click', clickHandler, false);
    a.click();
  }

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

vueでドラッグ可能なカルーセルを作成

過去にカルーセルを自作したことはあったものの、ドラッグできるものにするには時間がかかると判断し、諦めたが、今回時間があったため、挑戦してみた。

DraggableCarousel.vue
<template>
    <!--mouseupは指を左クリックから話した瞬間発火する。mouseleaveはこのdivタグの外側にカーソルが離れた時に発火。mousemoveは枠内でカーソルが動くたびに発火-->
    <div @mouseup="dragEnd" @mouseleave="dragEnd" @mousemove="dragging($event)">
        <div class="content-container">
            <div class="d-flex align-items-center">
                <div class="d-flex justify-content-center" style="width: 10%;">
                    <!--currentPosition==0にすることで、永遠に左へずれていかないようにする-->
                    <button @click="previous" :disabled="currentPosition==0">Back</button>
                </div>
                <!--mousedownは左クリックを押した瞬間に発火-->
                <div id="card-cover" class="rel" @mousedown="dragStart($event)">
                    <!--カード1枚1枚動かすわけでなく、widthの長いrelativeの要素にcardをabsoluteで張り付けて、その要素をtranslateXで動かす>
                    <div ref="frame" class="d-flex rel" :style="translateX"><!--この要素をcardの枚数に応じてwidthをセットする-->
                        <div class="abs" ref="card" v-for="(style, i) in styles" :key="i"><!--absoluteなのでleftでcardの間隔を調整-->
                            <!-- mouseup時にrouter-linkの影響でページ遷移するのでcardにtag="button"を追加し、buttonにすることでdisabledを反映させる-->
                            <v-card tag="button" class="mx-auto my-12" max-width="280" :to="{name: 'blog-bid', params: {bid: style.id}}" :disabled="disabled">
                                <template slot="progress">
                                    <v-progress-linear color="deep-purple" height="10" indeterminate></v-progress-linear>
                                </template>

                                <v-img height="250" :src="style.src">
                                    <v-badge class="px-1" content="NEW" value="NEW" color="green"></v-badge>
                                </v-img>
                                <v-card-title>{{ style.title }}
                                </v-card-title>
                                <v-card-text>
                                    <div v-html="str(style.description)"></div>
                                </v-card-text>
                                <v-card-subtitle>
                                    <b>{{ style.date }}</b>
                                </v-card-subtitle>
                            </v-card>
                        </div>
                    </div>
                </div>
                <div class="d-flex justify-content-center" style="width: 10%;">
                    <!--currentPosition<=-(this.styles.length-3)*340にすることで、永遠に右へずれていかないようにする-->
                    <button @click="next" :disabled="currentPosition<=-(this.styles.length-3)*340">Next</button>
                </div>
            </div>
        </div>
    </div>
</template>
<script>
export default {
    data() {
        return {
            startX: 0,
            isMouse: false,
            disabled: false,
            currentPosition: 0,
            distance: 0,
            styles: [
                {id: 1, title: 'やっぱり', date: '2021.01.07', src: require('@/assets/images/blog01.jpg'),description: 'いつも本当に有難う御座いますm(_ _)m<br>仕上がりはこちらです耳のところを短くすることで襟足と顔周りの長さを際立たせてます(`_´)ゞここまで読んで頂いてありがとうございました!'},
                {id: 2, title: '夏は', date: '2021.01.07', src: require('@/assets/images/blog01.jpg'),description: 'いつも本当に有難う御座いますm(_ _)m<br>仕上がりはこちらです耳のところを短くすることで襟足と顔周りの長さを際立たせてます(`_´)ゞここまで読んで頂いてありがとうございました!'},
                {id: 3, title: 'ショート', date: '2021.01.07', src: require('@/assets/images/blog01.jpg'),description: 'いつも本当に有難う御座いますm(_ _)m<br>仕上がりはこちらです耳のところを短くすることで襟足と顔周りの長さを際立たせてます(`_´)ゞここまで読んで頂いてありがとうございました!'},
                {id: 4, title: 'ですか', date: '2021.01.07', src: require('@/assets/images/blog01.jpg'),description: 'いつも本当に有難う御座いますm(_ _)m<br>仕上がりはこちらです耳のところを短くすることで襟足と顔周りの長さを際立たせてます(`_´)ゞここまで読んで頂いてありがとうございました!'},
                {id: 5, title: '', date: '2021.01.07', src: require('@/assets/images/blog01.jpg'),description: 'いつも本当に有難う御座いますm(_ _)m<br>仕上がりはこちらです耳のところを短くすることで襟足と顔周りの長さを際立たせてます(`_´)ゞここまで読んで頂いてありがとうございました!'},
                {id: 6, title: 'やっぱり夏は', date: '2021.01.07', src: require('@/assets/images/blog01.jpg'),description: 'いつも本当に有難う御座いますm(_ _)m<br>仕上がりはこちらです耳のところを短くすることで襟足と顔周りの長さを際立たせてます(`_´)ゞここまで読んで頂いてありがとうございました!'},
                {id: 7, title: 'ショート', date: '2021.01.07', src: require('@/assets/images/blog01.jpg'),description: 'いつも本当に有難う御座いますm(_ _)m<br>仕上がりはこちらです耳のところを短くすることで襟足と顔周りの長さを際立たせてます(`_´)ゞここまで読んで頂いてありがとうございました!'},
                {id: 8, title: 'です', date: '2021.01.07', src: require('@/assets/images/blog01.jpg'),description: 'いつも本当に有難う御座いますm(_ _)m<br>仕上がりはこちらです耳のところを短くすることで襟足と顔周りの長さを際立たせてます(`_´)ゞここまで読んで頂いてありがとうございました!'}
            ],
        }
    },
    mounted(){
        this.$refs.frame.style.width = (this.styles.length*340) + 10 +'px';//frameの長さを確定させる
        this.cardInterval()//カード同士の間隔を設定
    },
    computed:{
        translateX() {
            return {'transform': `translateX(${this.currentPosition+this.distance}px)`}
        }
    },
    methods: {
        cardInterval(){
            this.$refs.card.forEach((card, index)=>{
              card.style.left = `${340*index}px`
          })
        },
        dragStart(e){
            this.startX = e.clientX//クリックした場所を取得。後にこの値を利用する

            //ここが重要で、もしisMouseがない場合、mousemoveが常に作動し、
            //クリックしなくてもcardがカーソルを追うのでクリックしたらtrueにし、指を話すとfalseにして制御する。
            this.isMouse = true;
            this.$refs.frame.style.transition= '';//常にtransitionを設定しているとmousemove時に動きがおかしくなるのでいったん解除
        },
        dragging(e){
            if (this.isMouse) {//trueのときに発火
                //mousemoveが発火された瞬間にrouter-linkをdisabledにする。こうすることでクリック時はページ遷移する。
                this.disabled = true;
                const movedDistance = e.clientX - this.startX//クリックした位置から動いた距離を算出
                const distance = this.currentPosition + movedDistance;//現在のframeの位置
                //最初のカードと最後のカードよりも先に行かないようにif文で制御
                //170を設定することでゆとりをもってUIが綺麗になる
                if(170>distance && distance > -((this.styles.length-3)*340)-170){
                    this.distance = movedDistance;//movedDistanceではなくdistanceを入れると動く距離が加速するので注意
                }
            }
        },
        dragEnd(){
            this.disabled = false;
            this.isMouse = false;
            //ここでtransitionを追加し、
            this.$refs.frame.style.transition= 'all .5s';
            //以下の式で、自動的にきれいに位置を整えてくれる
            this.currentPosition = Math.round((this.currentPosition + this.distance)/340)*340;
            //説明できないが、0にしないと計算が狂う
            this.distance = 0;
        },
        next(){
            this.currentPosition -=340//ボタンでframeを進める
        },
        previous(){
            this.currentPosition +=340//ボタンでframeを戻す
        },
        str(str){
            return str.length>50 ? str.slice(0, 50) + '...' : str;
        }
    }
}
</script>
<style scoped>
    .align-items-center{
        align-items: center;
    }
    .justify-content-center{
        justify-content: center;
    }
    .rel{position: relative;}
    .abs{position: absolute;}
    .content-container{
        max-width: 1200px;
        width: 100%;
        margin: auto;
        height: 550px;
        position: relative;
    }
    #card-cover{
        overflow: hidden;//これがないとcardが見えたままになる
        width: 80%;
        height: 550px;
        z-index:0
    }

</style>

自称バックエンドだがやっていることは明らかにフロントエンド。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Vue.js概要? # Vue.jsを推す理由

はじめに

本文はこちら

Vue.jsを推す理由

AngularJS(1.x)の設計の古さ

Angular(JS) はクライアントサイドにサーバーサイドの設計を
そのまま持ってきている感があります。

データをグローバルな変数で扱うスコープ($scope)がその証左
の一つだと考えています。

AngularJS(1.x)のCotroller駆動よりVue.jsのModel駆動のほうが
クライアントサイド(UIアプリ)では理に適っています。

AngularJS(1.x)は中・大規模開発には適さないと思っています、
大規模開発を指向してはいるものの中・大規模開発に向いていない
のです。

AngularJS(1.x)は2009年に発表され、発表時の設計で2012年に
1.0.0がリリースされたFWです、2009年当時とは2012年にあった
WebComponents仕様のW3Cでの策定開始でもわかるようにWEB開発
の世界的な潮流が変化しています、AngularJS(1.x)の設計は既に
現在のニーズとは乖離しているのです。

AngularJSがRailsに例えられることへの疑問

AngularJSはRailsによく例えられますが自分はそうは
思いません。

似ているのは、フルスタック・フレームワークである点、
そのぶん勉強が大変な点だけです。

Railsは初期学習コストはそれなりに大きいですが、それを乗り越え
レールにのってしまえば、劇的?に開発時間を短縮できます。

対して、AngularJS はそうではありません、初期学習コストを
乗り越えてもレールが敷かれていないため、劇的な開発時間の
短縮は望めないのです。

Railsは、2.0までは、AngularJSと同様に、1から10まで開発チームが
面倒をみ、構成する各種モジュールと密接に結びついていましたが、
3.0でのDHHの英断による軽量Railsと目されていたMerbとの統合もあり、
フルスタックであることは変わらないものの、プラガブルとなり、外部で
開発されているモジュールとの柔軟な組合せ、構成するモジュールの
取捨選択が可能となっています、3.0以降、外部で開発されたライブラリが
次々とRailsに採用されてもいます。

対して、AngularJS は完全に一枚岩です、他のフレームワークや
ライブラリと柔軟に踏み合わせて、利用することは想定されていません。

Vue.jsはフル・スタックではありませんが、FWとしてのスコープを絞り、
Viewまわりにのみ特化し、Viewまわり以外については、目的に応じた
専用のライブラリと組合せて使うことを前提にしていて、組み合わせる
ライブラリを柔軟に取捨選択できます。

Angular(JS)のGoogleブランドかつコミュニティ駆動という虚像

「神様、仏様、Google様」なGoogle信者がセンスの良さよりもブランドで
持ち上げている気がしてならないです。

Angular(JS) は、デバッグ以外1から10まで開発チームというか
少数のGoogleエンジニアが面倒をみ、構成するモジュールも
基本的に少数のGoogleエンジニアが設計・開発を行っている、
Google製フレームワークといっても差し支えないモノと
なっています。

つまり、Angular(JS)はコミュニティ駆動ではなく
Google駆動なんです。

個人的にはAngular(JS)はGoogle内でGWT(Java→JS)の
後継的位置づけなのではないか?と思っています。

Google IO 2014の基調講演から考えると、Google内では
PolymerがGWTの後継的位置づけのようにもみえましたが、
そうでもありませんでした。

Angular(JS)2.0の設計資料も、1.xの課題と2.0に向けた設計指針が
示されているだけで、開発コミュニティを交えてオープンに仕様を
議論しようとしている雰囲気は感じられません。

2.x以降のバージョンでも、それは同様にみえます。

Angular(JS)の今後について1つの懸念があります。

GoogleはAngular(JS)の自社内での位置づけを下方修正している
ようにみえることです。

Angular(JS)はGoogleにとって戦略的に重要なプロダクトでは
なくなっているようにみえます。

GoogleがAngular(JS)の開発に今まで以上に開発リソースを
割くことは最早ないと思われます。

Angular(JS)はGoogle駆動であり続けているようには
みえます。

Google IO 2014の基調講演でのWeb Components仕様プッシュ
を考慮すると、Angular(JS)が2.x以降でWebComponents仕様との
高い親和性を実現できていなければ、GoogleはAngular(JS)をステて
いたかもしれません。

(Googlerが開発しているからGoogle駆動なのではありません。
Googleにより(戦略的意図のもと?)後援されOSSコミュニティ
から切り離して開発され製品がβテスト・フェーズになるまで
公開されないからGoogle駆動なのです。

Google駆動のOSSプロダクトは基本的にβテスト・フェーズに
入るまで公開されません、このフェーズでは設計は既に固まって
おり、OSSコミュニティが設計にタッチすることは、まずできません。
GoogleにとってOSSコミュニティはテスター・デバッガーにすぎない
のではないかと思っています。(GoogleはOSSに対して非常に理解が
あるように思われていますが、プロダクトをOSSとして公開している
他の企業と何ら変わりはありません。。。))

Angular2.0の開発の迷走

2.0発表時の設計資料から察せられる通り、Angular(JS)は2.0でかなり
手が入り1.xとはだいぶ変わることが確定していました。

既に大きなフルスタックフレームワークであり、2.0の開発がどうなるかは
未知数、革新でではなく下位互換に重点を置きすぎると開発が停滞する可能性も
ありました。。。

Angular2.0は、ES6+ES7の一部+α という、当時まだフル実装の存在
していないJS仕様をターゲットに開発が行なわれていたため、
Angular(JS)の開発者にとっては挑戦として面白いのかもしれません
が、リリースまでには長い時間が必要となる懸念がありました。

ES6の実行環境の実装によっては、ある程度、実装が進んだ段階で
大きな手戻りが必要になるリスクも懸念されていました。

ES6→ES5の Traceur Compiler はあったものの、ES6の実行環境が
存在しなかったこともあり、実用レベルには達しておらず、ES6 を
フル?実装した主要ブラウザが出揃うまで正式版がリリースされない
可能性を高めていました。

ES6、仕様自体はfreezeされているものの、仕様の発行がレビュー及び
実装からのフィードバックを反映するために 2015/06 に延期されたり
もしました。
(Object.oberve等ES6では入らずES7以降へ持ち越しとなっていた機能
のいくつかが前倒しになる可能性は限りなく低いですがありはしました。
その後、Object.oberve は仕様から取り下げられています。)

ECMAScript 6 実装状況
http://kangax.github.io/es5-compat-table/es6/
traceur-compiler 入門
http://yosuke-furukawa.hatenablog.com/entry/2014/07/31/093041

フルスタックでありながら、ほんの数人のエンジニアだけで開発されていることも
開発の長期化を予感させました。

2.0ではWeb Comopnents仕様対応かつ自律したUIコンポーネントが作成できることが
Googleブランドであるためには外せないであろうことも、開発期間の長期化を
予感させました。

発表時点でリリース時期未定となっていることからも、1.xとは大幅に変わるのは、ほぼ確実
ではありましたが、Angular(JS)2.0を1.xとそれほど大きく変えず、早期リリースの実現
を目指すことも考えられました。

その場合、Angular(JS)2.0は淘汰され消えていたでしょう、変化を許容できないFWは
生き残れません。

2015/03にAngular2.0の開発において大幅?な変更が入りました。

当初、Traceur Compiler ベースでの ES6→ES5 変換を利用しての
ES6ベースでの開発が予定されていましたが、Traceurが期待するほど
の変換能力を実現できていないことから、AtScriptという名前で
ES5ベースにES6の一部機能をツッコんだAltJSを開発する方向に
方針が変更されていましたが、独自に開発していては開発に時間が
掛かる上に、枯れて問題なく利用できるレベルに達するのにも、時間を
要するためか、AtScriptの開発をM$主体で開発が進められている
TypeScriptに合流することが決定されました。

Angular2.0開発における一番?の懸念材料であったES5・ES6
両対応のための足回りの問題がこれで解消に向かいました。

この開発方針の変更に合わせ、Angular2.0のリリース時期も
2015/03時点に来年と発表されました。

GoogleのAngular2はマイクロソフトのTypeScriptで開発されると発表
http://www.publickey1.jp/blog/15/googleangular_2typescripttypescript_15ecmascript_6.html

他の懸念材料は残っていましたが、GoogleがAngularに投入している人的リソース
から考えると、妥当な判断だったのではないかと思います。Angular2.0はそれまで
大風呂敷を広げすぎていて人的リソースから考えると開発期間が長期化せざるをえない
状況にありました。

Angular2.0はその時点で設計段階か初期プロトタイプ・フェーズにあったようなので、
この発表以降も予断を許さなかったのではないかと思います。

AngularJS(1.x)のように、マニアックで場当たり的な(そうみえる)設計にしてしまうと、
モタラされる恩恵に比して学習コストが非常に高くつくモノとなってしまいます。

以前書いた上記の懸念もありましたが、2016/09/14、Angular2.0が
リリースされました。

2.0の仕様案?では予定されていた?VDOM対応は早期リリースのために見送られました。

Angularの現在のロードマップでは、VDOM対応についての名言はありません。

2.0での開発の迷走が大きく影響しているのか、Angularは2.0以降、革新的な機能の
追加はないようにみえます。

Angular(JS)の学習コストの費用対効果

学習コストが高いこともAngular(JS)のネックの1つです。

Angular(JS)は囲い込み型のFWなので、学習コストを掛けても
Angular(JS)を離れるとAngular(JS)の勉強で得た知識はほとんど
役に立ちません。

Angularは2.0以降、AngularJS(1.x)と別物であり、1.xの知識や
ノウハウがほとんど役に立たない、ので、移行コストは高くついた
ことでしょう。

既にAngular(JS)で仕事してるor仕事することが決まっている
のでもなければ、今からAngular(JS)を勉強するのは時間のムダです。

これから仕事に活かすために勉強するのなら、Angular(JS)を勉強
するのではなく、別のことを勉強しておいたほうがずっと有意義のはず。

Angular(JS)は高い学習コストを掛けることに見合うほどに
魅力的では最早なくなっています。

(世の中には「学習コストが高いモノを態々選んで勉強する
(複雑な××を理解できている俺・私って偉いと思っている?)
方もいらっしゃるようですが、必要もないのに学習コストが
高いモノを選ぶのは時間のムダです。)

React.jsに潜む学習コスト

React.js、超基本的な機能を利用するだけなら、
学習コスト、Vue.js >= React.js、な感じですが、
ごく基本的な機能だけでは、SPAを作成するには不十分で、
Redux etc に手を出し始めると、途端に、学習コストが
増大し、Vue.js < React.js、になります。

React Hooksが登場してから、学習コストが改善される
方向に向かってはいるようですが、React Hooks上に構築
された(= React Hooks対応の)ライブラリを利用している
プロジェクトと、React Hooks非対応のライブラリを利用
しているプロジェクト、あるいは、React Hooks対応・非対応
のライブラリが混在しているプロジェクト、が混在している状況
なので、React Hooksあり・なしのどちらも勉強する必要がある
ようです。

(状態管理ライブラリだけ見ても、独自の?Redux、React Hooks
ベースのRecoil、etc、があります。

Vue.jsは状態をVM(View Model)が持っているので、状態管理
ライブラリを利用する必要はありません。利用したい場合には、
Vuexがあります。)

そこでVue.js

そこで、ライブラリとしてのデザインが好みであり、
AngularJSライクで、AngularJSより、開発者がコミュニティ・
フレンドリーに感じるVue.jsを応援しています。

Vue.jsの開発者であるEvan You氏は元Googlerではありますが、
Vue.jsの開発は氏の個人プロジェクトです。

(公式サイトのどこにも"Powered by Google"の文字はありません。
Polymerにもありませんが、こちらはGoogle I/Oで発表された
とおりGoogleの戦略的プロジェクトでGoogle駆動です。

Googleは秘密主義なので、Google駆動ならGoogle I/O等で
(大々的?に)発表されるまで外部に漏れることはまずありません。

Angular(JS)及びPolymer(後継?のLitElement)と機能や用途が
被っているので、Evan You氏がGoogleを去った(出戻りはありえる?)
こともあり、Vue.jsはGoogle駆動のようにはならないと思います。

Vue.jsが個人プロジェクトであることを引き合いに出して、
その将来に不安があるかのように文章を書く方もいらっしゃるよう
ですが、Linuxが、元々、個人プロジェクトであったことを知らない
のか、と思います。Evan You氏に何かがあった、としても、開発を
引き継ぐ個人なり企業なりが現れる、と思っています。

企業が主導しているOSSは安心だと思っている方がいるようですが、
企業は営利目的なので、主導していたにしても経営判断により
手を引くケースは往々にしてあり、そして、手を引かれた
OSSは開発・メンテナンスする人材がおらず、衰退・消滅していきます。)

現時点ではAngular(JS)のほうが先行かつフルスタックであるぶん、
まだ人気があるようですが、Angular(JS)は内で閉じているぶん、
2.0の開発に時間が掛かったこともあり、追い上げてきています。

Angular2.0以降は更に学習コストが高いため、Angular(JS)と比べて
欠けていた機能をプラグインで補い進化してきたVue.jsが世界での
人気でしのぐこともありうると感じています。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Vue.js概要? #Vue.jsを推す理由

はじめに

本文はこちら

Vue.jsを推す理由

vs React.js

潜む学習コスト

React.js、ごく基本的な機能を利用するだけなら、
学習コスト、Vue.js >= React.js、な感じですが、
ごく基本的な機能だけでは、SPAを作成するには不十分で、
Redux etc に手を出し始めると、途端に、学習コストが
増大し、Vue.js < React.js、Vue.js << React.js、
になっていきます。

React Hooksが登場してから、学習コストが改善される
方向に向かってはいる、ようですが、React Hooks上に構築
された(= React Hooks対応の)ライブラリを利用している
プロジェクト、React Hooks非対応のライブラリを利用
しているプロジェクト、React Hooks対応・非対応のライブラリ
が混在しているプロジェクト、が混在している状況、なので、
React Hooksあり・なしのどちらも勉強する必要がある
ようです。

React.js、周辺ライブラリが充実しているのは結構なこと、なのですが、
車輪の再発明も多く、同じ用途に複数のライブラリが存在していることもあり、
更に、そこに、React Hooks対応・非対応も絡んでくるので、
カオスな感じです。。。

(状態管理ライブラリだけ見ても、独自の?Redux、React Hooks
ベースのRecoil、etc、があります。

Vue.jsは状態をVM(View Model)が持っているので、状態管理
ライブラリを利用する必要はありません。利用したい場合には、
Vuexがあります。)

vs Angular(JS)

設計の古さ of 1.x

Angular(JS) は、クライアントサイドに、サーバーサイドの設計を
そのまま持ってきている感があります。

データをグローバルな変数で扱うスコープ($scope)がその証左
の一つだと考えています。

AngularJS(1.x)のCotroller駆動より、Vue.jsのModel駆動、のほうが
クライアントサイド(UIアプリ)では、理に適っています。

AngularJS(1.x)は中・大規模開発には、適さないと思っています、
大規模開発を指向してはいるものの、中・大規模開発に向いていない、
のです。

AngularJS(1.x)は、2009年に発表され、発表時の設計で、2012年に
1.0.0がリリースされたFWです、2009年当時とは、2012年にあった
WebComponents仕様のW3Cでの策定開始、でもわかるように、WEB開発
の世界的な潮流が変化しています、AngularJS(1.x)の設計は、既に
現在のニーズとは乖離しているのです。

Railsに例えられること への疑問

AngularJSはRailsによく例えられますが自分はそうは
思いません。

似ているのは、フルスタック・フレームワークである点、
そのぶん勉強が大変な点、だけです。

Railsは初期学習コストはそれなりに大きいです、が、それを乗り越え、
レールにのってしまえば、劇的?に開発時間を短縮できます。

対して、AngularJS はそうではありません、初期学習コストを
乗り越えてもレールが敷かれていないため、劇的な開発時間の
短縮は望めない、のです。

Railsは、2.xまでは、AngularJSと同様に、1から10まで開発チームが
面倒をみ、構成する各種モジュールと密接に結びついていましたが、
3.0での軽量Railsと目されていたMerbとのDHHの英断による統合もあり、
フルスタックであることは変わらないものの、プラガブルとなり、外部で
開発されているモジュールとの柔軟な組合せ、構成するモジュールの
取捨選択が可能、となっています、3.0以降、外部で開発されたライブラリが
次々とRailsに採用されてもいます。

対して、AngularJS は 完全に一枚岩 です、他のフレームワークや
ライブラリと柔軟に組み合わせて、利用することは想定されていません。

Vue.jsは、フル・スタックではありません、が、FWとしてのスコープを絞り、
Viewまわりにのみ、特化し、Viewまわり以外については、目的に応じた
専用のライブラリと組合せて使うことを前提にしていて、組み合わせる
ライブラリを柔軟に取捨選択できます。

Googleブランドかつコミュニティ駆動 という虚像

「神様、仏様、Google様」なGoogle信者がセンスの良さよりもブランドで
持ち上げている気がしてならないです。

Angular(JS) は、デバッグ以外1から10まで開発チームというか
少数のGoogleエンジニアが面倒をみ、構成するモジュールも
基本的に少数のGoogleエンジニアが設計・開発を行っている、
Google製フレームワークといっても差し支えないモノと
なっています。

つまり、Angular(JS)は コミュニティ駆動 ではなく
Google駆動 なんです。

個人的には、Angular(JS)はGoogle内で GWT(Java→JS) の
後継的位置づけ なのではないか?と思っています。

Google IO 2014の基調講演から考えると、Google内では、
PolymerがGWTの後継的位置づけのようにもみえましたが、
そうでもありませんでした。

Angular(JS)2.0の設計資料も、1.xの課題と2.0に向けた設計指針が
示されているだけで、開発コミュニティを交えて、オープンに仕様を
議論しようとしている雰囲気は、感じられません。

2.x以降のバージョンでも、それは同様にみえます。

Angular(JS)の今後について、1つの懸念があります。

GoogleはAngular(JS)の自社内での位置づけを下方修正している
ようにみえることです。

Angular(JS)はGoogleにとって、戦略的に重要なプロダクトでは
なくなっているようにみえます。

Googleが、Angular(JS)の開発に今まで以上に開発リソースを
割くことは最早ない、と思われます。

Angular(JS)はGoogle駆動であり続けているようには
みえます。

Google IO 2014の基調講演での Web Components仕様 プッシュ
を考慮すると、Angular(JS)が2.x以降で WebComponents仕様との
高い親和性 を実現できていなければ、GoogleはAngular(JS)をステて
いたかもしれません。

(Googlerが開発しているからGoogle駆動、なのではありません。
Googleにより(戦略的意図のもと?)後援されOSSコミュニティ
から切り離して開発され、製品がβテスト・フェーズになるまで
公開されないから、Google駆動、なのです。

Google駆動のOSSプロダクト は基本的にβテスト・フェーズに
入るまで公開されません、このフェーズでは、設計は既に固まって
おり、OSSコミュニティが設計にタッチすることは、まずできません。

Googleにとって、OSSコミュニティはテスター・デバッガーにすぎない
のではないか、と思っています。

(GoogleはOSSに対して非常に理解があるように思われていますが、
プロダクトをOSSとして公開している他の企業と何ら変わりは
ありません。。。))

比較

Vue.jsの開発者である Evan You氏 は元Googlerではありますが、
Vue.jsの開発は、最初から、氏の個人プロジェクトです。

(公式サイトのどこにも"Powered by Google"の文字はありません。
Polymerにもありませんが、こちらはGoogle I/Oで発表された
とおり、Googleの戦略的プロダクトで、Google駆動です。

Googleは秘密主義なので、Google駆動なら、Google I/O等で
(大々的?に)発表されるまで、外部に漏れることはまずありません。

Angular(JS)及びPolymer(後継?のLitElement)と機能や用途が
被っているので、Evan You氏がGoogleを去った(出戻りはありえる?)
こともあり、Vue.jsはGoogle駆動のようにはならないと思います。

Vue.jsが個人プロジェクトであることを引き合いに出して、
その将来に不安があるかのように文章を書く方もいらっしゃるよう
ですが、Linuxが、元々、個人プロジェクトであったことを知らない
のか、と思います。Evan You氏に何かがあった、としても、開発を
引き継ぐ個人なり企業なりが現れる、と思っています。

企業が主導しているOSSは安心だと思っている方がいるようですが、
企業は営利目的なので、主導していたにしても経営判断により
手を引くケースは往々にしてあり、そして、手を引かれた
OSSは開発・メンテナンスする人材がおらず、衰退・消滅していきます。)

2.0開発の迷走

2.0発表時の設計資料から察せられる通り、Angular(JS)は2.0でかなり
手が入り、1.xとはだいぶ変わること、が確定していました。

既に大きなフルスタックフレームワークであり、2.0の開発がどうなるかは
未知数、革新でではなく下位互換に重点を置きすぎる、と開発が停滞する
可能性もありました。。。

Angular2.0は、ES6+ES7の一部+α という、当時まだフル実装の存在
していないJS仕様をターゲットに開発が行なわれていたため、
Angular(JS)の開発者にとっては、挑戦として面白かったのかもしれません
が、リリースまでには長い時間が必要となる懸念 がありました。

ES6の実行環境の実装によっては、ある程度、実装が進んだ段階で
大きな手戻りが必要になるリスクも懸念されていました。

ES6→ES5の Traceur Compiler はあったものの、ES6の実行環境が
存在しなかったこともあり、実用レベルには達しておらず、ES6 を
フル?実装した主要ブラウザが出揃うまで、正式版がリリースされない
可能性を高めていました。

ES6、仕様自体はfreezeされていたものの、仕様の発行がレビュー及び
実装からのフィードバックを反映するために 2015/06 に延期されたり
もしました。
(Object.oberve等、ES6では入らずES7以降へ持ち越しとなっていた機能
のいくつかが、前倒しになる可能性は限りなく低いです、がありはしました。
その後、Object.oberve は仕様から取り下げられています。)

ECMAScript 6 実装状況
http://kangax.github.io/es5-compat-table/es6/
traceur-compiler 入門
http://yosuke-furukawa.hatenablog.com/entry/2014/07/31/093041

フルスタックでありながら、ほんの数人のエンジニアだけで開発されていることも
開発の長期化を予感させました。

2.0では、Web Comopnents仕様対応かつ自律したUIコンポーネントが作成できることが
Googleブランドであるためには外せないであろうことも、開発期間の長期化を
予感させました。

発表時点でリリース時期未定、となっていたことからも、1.xとは大幅に変わるのは、
ほぼ確実ではありましたが、Angular(JS)2.0を1.xとそれほど大きく変えず、
早期リリースの実現を目指すことも考えられました。

その場合、Angular(JS)2.0は淘汰され消えていたでしょう、変化を許容できないFWは
生き残れません。

2015/03にAngular2.0の開発において大幅?な変更が入りました。

当初、Traceur Compiler ベースでの ES6→ES5 変換を利用しての
ES6ベースでの開発が予定されていましたが、Traceurが期待するほど
の変換能力を実現できていないことから、AtScriptという名前で
ES5ベースにES6の一部機能をツッコんだAltJSを開発する方向に
方針を変更、更に、独自に開発していては開発に時間が掛かる上に、
枯れて問題なく利用できるレベルに達するのにも、時間を要するためか、
AtScriptの開発をM$主体で開発が進められている
TypeScriptに合流することが決定されました。

Traceur Compiler(Google) → AtScript(Google) ⇨ TypeScript(M$)。。。

Angular2.0開発における一番?の懸念材料であったES5・ES6
両対応のための足回りの問題がこれで解消に向かいました。

この開発方針の変更に合わせ、Angular2.0のリリース時期も
2015/03時点で来年と発表されました。

GoogleのAngular2はマイクロソフトのTypeScriptで開発されると発表
http://www.publickey1.jp/blog/15/googleangular_2typescripttypescript_15ecmascript_6.html

他の懸念材料は残っていましたが、GoogleがAngularに投入している人的リソース
から考えると、妥当な判断だったのではないかと思います。Angular2.0はそれまで
大風呂敷を広げすぎていて、人的リソースから考えると、開発期間が長期化せざるを
えない状況にありました。

Angular2.0は、この発表時点で、設計段階か初期プロトタイプ・フェーズにあった、
ようなので、この発表以降も予断を許さなかったのではないかと思います。

AngularJS(1.x)のように、マニアックで場当たり的な(そうみえる)設計にしてしまうと、
もたらされる恩恵に比べて学習コストが非常に高くつくモノ、となってしまいます。

(以前書いた)上記の懸念もありましたが、2016/09/14、Angular2.0が
リリースされました。

2.0の仕様案?では予定されていた?vDOM対応は、早期リリースのために、
見送られました。

Angularの現在のロードマップでは、vDOM対応についての明言はありません。

2.0での開発の迷走が大きく影響しているのか、Angularは2.0以降、革新的な
機能の追加はないようにみえます。

学習コストの費用対効果

学習コストが高いこともAngular(JS)のネックの1つです。

Angular(JS)は囲い込み型のFWなので、学習コストを掛けても
Angular(JS)を離れるとAngular(JS)の勉強で得た知識はほとんど
役に立ちません。

Angularは、2.0以降、AngularJS(1.x)と別物であり、1.xの知識や
ノウハウがほとんど役に立たない、ので、移行コストは高くついた
ことでしょう。

既にAngular(JS)で仕事してるor仕事することが決まっている、
のでもなければ、今からAngular(JS)を勉強するのは時間のムダです。

これから仕事に活かすために勉強するのなら、Angular(JS)を勉強
するのではなく、別のことを勉強しておいたほうがずっと有意義のはず。

Angular(JS)は高い学習コストを掛けることに見合うほどに
魅力的では最早なくなっています。

(世の中には「学習コストが高いモノを態々選んで勉強する
(複雑な×××を理解できている俺・私って偉いと思っている?)
方もいらっしゃるようですが、必要もないのに学習コストが
高いモノを選ぶのは時間のムダです。)

そこで Vue.js

現時点ではAngular(JS)のほうが先行かつフルスタックであるぶん、
まだ人気があるようですが、Angular(JS)は内で閉じているぶん、
2.0の開発に時間が掛かったこともあり、追い上げてきています。

Angular2.0以降は更に学習コストが高いため、Angular(JS)と比べて
欠けていた機能をプラグインで補い進化してきたVue.jsが世界での
人気でしのぐこともありうると感じています。

そこで Vue.js

ライブラリとしてのデザインが好みであり、
AngularJSライクで、AngularJSより、開発者がコミュニティ・
フレンドリーに感じる、
React.jsとは異なり、デザイナー・フレンドリーな、
Vue.jsを 応援しています。

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Vueインスタンスについて

はじめに

この記事は最近vueの勉強始めた僕の備忘録的な記事です。
VueインスタンスはVueアプリケーションを裏で動かしている実態のことです。
Vueインスタンスにいろいろなオプションを指定することで、アプリの機能が作れます。

Vueインスタンスを作る

sample.vue
new Vue({ Vueインスタンスの中身 })

で作成できます

Vueインスタンスの中身

sample.vue
new Vue({
 el: どのHTML要素とつなげるのか
 data: どんなデータがあるのか
 methods: どんな処理を行うのか
 computed: どのデータを使って別の計算をするのか
 watch: どのデータを監視するのか
})

上記オプションを用意できます
それぞれを見ていくと

elオプション

「どのHTML要素とつなげるのか」を指定するオプションです
HTML内の<タグ名 id="ID名">とelオプションで指定したel: "#ID名"がその要素とつながります。

dataオプション

「どんなデータがあるのか」を指定するオプションです
data: { プロパティ名: 値 }の書式でデータを指定できます。複数の場合はカンマ区切りで指定できます

methodsオプション

「どんな処理(命令)があるのか」を指定するオプションです
メソッドはmethods: { メソッド名: function() { 処理内容 } }の書式で追加できます。複数の場合はカンマ区切りで指定できます

computedオプション

computedオプション(算出プロパティ)「どのデータを使って別の計算をするのか」を指定するオプションです
javascriptの式で書くような処理を「名前」で表したものが「computedオプション(算出プロパティ)」です。
methodsとの主な違いは、公式ドキュメントに
https://jp.vuejs.org/v2/guide/computed.html

リアクティブな依存関係にもとづきキャッシュされるという違いがあります。

とありました。
つまりcomputedは、dataの値が変わらない限りはcomputedプロパティに何度アクセスしても、関数を再び実行することなく以前計算された結果を即時に返すということです。

computed: { プロパティ名: function() { 処理内容 } }という書式で追加できます。複数の場合はカンマ区切りで指定できます

watchオプション

watchオプション(監視プロパティ)は「どのデータを監視するのか」を指定するオプションです
データや変数の値が変わった時や、非同期な値など、自動的に変化する値などを監視する場合にも使います
watch: { メソッド名: funtion() { 実行する処理 } }という書式で追加できます。複数の場合はカンマ区切りで指定できます

最後に

今回はVueインスタンスについて書きました
Vueは勉強中なので、この記事で間違っている点などありましたらコメントしていただけるとありがたいです

  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む