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

今朝、指導者は私たちのチームを見学して会議の準備を始めました.

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です.