パーティーbid_coreまとめ

本文:
初回使用テスト、party_bid_coreはステップテストを通して、三つのデータ構造の保存を比較して、その利点と不便さを導き出す.一.三つのデータ構造の前に、まずgithubに自分のブランチを作る.1.gitのフォルダを作成する.パーティーって名前をつけましたbid_coree 2.githubに登録し、右下側のNew repositoryをクリックします.3.ポップアップページにRepository nameを記入し、左下のCreate repositoryボタンをクリックします.(後で指導的な操作があります.)//最良の分岐名はparty_bid_coreは、4.terminalからgitのファイルディレクトリに入り、3.
 
 
二.三種類の構造のまとめ
      最初のデータ構造: 
 

activities = [
    {
        name: "first activity",
        sign_ups: [],
        bids: []
    },
    {
        name: "first activity",
        sign_ups: [
            {
                name: "  ",
                phone: "13600000000"
            },
        ],
        bids: [
            {
                name: "  1",
                biddings: [
                    {
                        name: "  ",
                        phone: "13600000000",
                        price: "12"
                    }
                ]
            },
            {
                name: "  2",
                biddings: [                   
                ]
            }
        ]
    }
];

 
すべての活動はactivitiesの中にあります.各活動には自分の活動名があります.有名人の情報を提供し、価格競争者の情報を提供します.構造ははっきりしています.しかし、記憶する時は毎回毎回毎回毎回毎回毎回毎回繰り返し探します.ちょっと煩わしいです.
 

Bidding.save_all = function (biddings) {
    var current_bid = Bid.get_current_bid();
    var activities = Activity.get_activities();
    var current_activity = Activity.get_this_activity(activities);
    var current_activity = _.map(current_activity.bids, function (the_bid) {
        return the_bid['name'] == current_bid ? the_bid['biddings'] = biddings : '';
    });
    localStorage.setItem('activities', JSON.stringify(activities));
};

 
 
       第二のデータ構造:
 

activities = {
    "0": {
        name: "first activity",
        sign_ups: [],
        bids: [],
        biddings: {}
    },
    "1": {
        name: "second activity",
        sign_ups: [
            {
                name: "  ",
                phone: "13600000000"
            }            
        ],
        bids: ["  1", "  2"],
        biddings: {
            "  1": [
                {
                    phone: "13600000000",
                    price: "12"

                }               
            ],
            "  2": [                
            ]
        }
    }
};

 
 
         各活動には自分のkeyとvalueがあります.valueには活動名があります.活動申込情報、入札名、競争価格応募情報、biddingsにはkeyは入札価格の名前、valueは入札価格の申請の詳細があります.構造もはっきりしています.例えば、入札価格情報を保存する時はkeyで保存場所を確定します.しかし、keyを定義する時は多めに考えてください.それぞれのvalueの長さで成長していく必要があります.例えば、価格を格納することです. 
      

Bidding.create_new_bid = function (activity_id) {
    var activities = Activity.get_activities();
    var current_activity = Activity.get_the_activity(activity_id)
    var counter = current_activity.bids.length + 1;
    var bid_name = "  " + counter;
    _.map(activities, function (value, key) {
        if (key == activity_id) {
            value.bids.push(bid_name);
            value.biddings[bid_name] = [];
        }
    });
    localStorage.setItem("activities", JSON.stringify(activities))
};

 
      第三のデータ構造:
 

activities = [
    {
        id: "0",
        name: "first activity"

    },
];

sign_ups = [
    {
        name: "  ",
        phone: "13600000000",
        activity_id: "0"
    },
    {
        name: "  ",
        phone: "15600000000",
        activity_id: "0"
    },
    
    {
        name: " ",
        phone: "13800000000",
        activity_id: "1"
    }
]

bids = [
    {
        name: "  1",
        activity_name: "0",
        biddings: [
            {
                phone: "13600000000",
                price: "9"

            }
        ]
    },
    {
        name: "  1",
        activity_id: "1",
        biddings: [
            {
                phone: "13600000000",
                price: "12"

            },
        ]
    },
    {
        name: "  2",
        activity_id: "1",
        biddings: [
            {
                phone: "13600000000",
                price: "10"

            },
        ]
    }
];

 
 
 
      イベント名、イベント申し込み、入札価格は全部別々に保管しています.そして、三人ともactivityがあります.IDは、現在の申し込みや入札価格の情報を取得する際に入れ子の層数が少ないので便利ですが、構造がはっきりしていないので、全体的には強くないです.入札価格を格納する際に、イベントの申し込みかどうかを判断する必要があります.また、sign_を取ります.upのデータは、対応するIDを見つけるのが面倒くさいです.      3つのデータ構造にはそれぞれ優劣があります.どちらが便利かというと、どちらを使ってもいいですが、効率面と入れ子を減らす点で、個人的には設定IDを使うほうが便利だと思います.パーティーをしています.bidの時に使ったのは第一の方法と似ています.bidsだけが単独で記憶しています.第三のデータ構造のbidsも使いやすいです.注意事項1.テストの意味:テストは既知の条件を与えられた場合、すべての結果を検証できる方法を書くことによって、expectと同じ結果が得られます.(条件が限定されていますので、結果は期待されている結果でなければテストに合格できません.しかし、書いた方法は必ずすべての結果を検証する方法があります.一つ書いたら、現在のテストを通過するためだけにテストは意味がありません.)2.各テストの前に、それぞれのデータを与えます.すなわち、前提条件です.テストが終わったら、それらのデータをクリアします.つまり、テストは機能に影響しない条件で行います.各テストは小さいモジュールをテストします.
 

beforeEach(function () {
        init_activity_database()
    });

    afterEach(function () {
        localStorage.clear();
    })