🥦ローカル🥦 プロジェクト4日目

6815 ワード
プロジェクト WeCode バックグラウンドコミュニケーション 上のコード テキストリンク
今朝、指導者は私たちのチームを見学して会議の準備を始めました.

Standup Meeting


バックエンド

  • 昨日初设、モデル.pyの作成とマージの完了
  • API機能定義
  • apiタスクは間もなく
    • を開始します.
  • 昨日、GoogleスプレッドシートにCSVファイルを作成し、データベースデータを統合するために
    • にスタックデータを入れました.

    フロント

  • 本日よりフロントの手配をいたします
    朝の会議
    ->午後-それぞれコード
    ->夜8時以降-すべてのフロントが集まってコードし、会議をします
    -1日のほとんどのディスカッションと質疑応答
    -でももちろん必要な時に緊急会議を開いて質問してもいいですよ!!
  • ホームページは商品リストページなので、詳細リストカフェコーナー別urlを変更します
    ->query近日発売
    ->useparams/useLocation
    ->/products/:id(商品詳細ページurl計画)
  • モジュラ素子
    • が作成される.

    メンターのコメント

  • ログ後処理は良好であり、
    • さらに
  • のプリログを加えると、
    ->チームは事前ブログを考えてもいいです
    ->会議のほうが意味があり、他のチームメンバーが他のチームメンバーの話をすぐに理解できる
  • 以降のマージ機能の間に新しいブランチを作成し、接続後に
    • をマージすることが望ましい.
  • コメント->やめたほうがいいですが、TODO、TOFIX部分は
    • コメントできます

    フロントミーティング

  • common.scssで変数を一緒に作成し,分離して再プッシュした.
    引張
  • これまでscssは、汎用的な部分変数
    • に変更する必要がある.
    理由
  • :変数の変数のみを呼び出すことができます.
    common stleを含むcommonファイルをロードし続けると、cssセクションが適用され続け、後で問題が発生する可能性があります.
  • common.scssはトップインデックスです.jsに1回のみ
    • を適用
  • 8時モグンゴの場合、検討すべき点があれば、事前にモグンゴカードに記入して、他のチームメンバーに事前に見て考えてもらうことができます.

    Rest APIセッション

  • セッションをリスニングしてこそ、よりよく理解できるが、Rest APIを使用する理由と要点を理解した.
  • 明日また勉強して、ブログ
    • を書きます.
  • は月曜日からバックエンドと大量に通信する計画で、脈絡全体をよく理解しています.

    • バックエンドとURL会議

  • 詳細リスト
  • フロント:menu、category、sort値、
  • パッケージに指定されたURLを作成して送信
  • パッケージはまだweb apiを完了していません
    まず、UIが完了する前に
    コードを記述する際、バックエンドに必要なキー値とエンドポイントとしての部分を考慮すると、バックエンドはurl/apiを完了します.
    fetch部分を少し修正するだけで
    • を使用できます.
  • NAVでメニューをクリックしたときにクリックしたメニュー(変更を問い合せて送信する必要がある)
  • path部分?クエリによって値が作成され、
    • が送信されます.
  • 製品を押す場合は、製品IDを出すだけです.
  • 製品IDは完全(すべてのメニューが加算されたデータ)、唯一の
    • です.
    詳細ページデータ
  • は、
  • の製品IDのみを送信ことで受信ことができる
    • .
  • ショッピングバスケット
  • 注文した製品IDとコインを一緒に送る->カートアイテムはすべて
    • を受け取ることができます.
  • フロントは製品IDを用意するだけで
    • .
  • 常温、冷蔵品は分類せず、全部送り出す->フロント分類展示、
  • 数量変更部分、削除部分は後で
    • について話します.
  • オーダー
  • で注文を完了し、
  • オーダーIDを受け取り、完了を通知
  • カートから注文したばかりの部分(フロントで、カートページの元のfetch操作に従えばよい)
    • を削除する.
  • カート画面は、カートに残っているものだけが表示されます

    • 成長コード


    productList


    最初の計画



    変化する部分

  • のルーティング部分が多く、ルーティングはパスを変更するときに使用され、フロント内部が変化するときに使用されると思います.
    中身は一部だけ変えて、ほとんど取り出せばいいことに気づきました.
    (バックエンドとの通信は初めてなので、いろいろ違います.これらの部分を知るのは本当に楽しいです!!)

    • カテゴリ選択コード(1つのみ選択)


    イニシャルコード
  • という部分を真偽管理しようとしたことがある.
    • const [sortCheck, setSortCheck] = useState([true, false, false]);
setSortCheck(sortCheck.map((_, i) => (i === id ? true : false)));
className={`sortBtn ${sortCheck[i] ? 'checked' : ''}`}
    変更されたコード
  • を考えると、いつも1つの値しかありません.
  • の場合、値を格納するだけで、値が/またはに等しい場合、論理は
    • とみなされる.
  • を再包装します.
  • はもっとシンプルで、もっときれいなコードになります!!!
    • const [sortCheck, setSortCheck] = useState(0); 
setSortCheck(id);
className={`sortBtn ${sortCheck === i ? 'checked' : ''}`}

    今日の成長

  • のバックエンドと会って、私は今日fetchがどのような面を考えるべきかについて多くのことを学びました.
  • のデータテーブルを表示することにより、バックエンドに必要な部分
    • を概略的に理解することができる.
  • のフロントから、ウェブサイトを変えるのはフロントがコミュニケーションするために使われていることがわかりました.
  • このように教えてくれなければ、ページが変わると、後ろのページを担当するフロントは前に何が起こったのか分かりません.
  • 前ページのフロントは後ページのフロントに取るべき経路を考慮して送るべきです.
  • urlはバックエンドとのコミュニケーションのためだけに変更されると思います.これはすべての人が考えるべき部分で、前のページ、後のページのフロント、バックエンド-3の部分です.実際、fetchで発生したページが持つurlは、前のページから与えられたurlです.
    • Code Kata # 1
    暗号化に関するいくつかの方法