今日やるべきこと/ガイドカードを選別して、ログインを維持します

3405 ワード

🍊 今日の事

  • 移動レイアウト修正
  • 修正
  • ガイドフィルタレイアウト
  • 日実施(datePicker install)
  • dateリクエストフォーマットに対するrest api
  • kakao地図ガイドカードフィルタエラー修正
  • ガイドカードcss実施
  • 開始

    🍊 今日のアレンジ


    🍉 redux-persistを使用してisLogin状態を維持


    問題の状況


    =>2週目にログイン状態を維持するために、サーバ要求時にaccessTokenをヘッダに入れて認証し、ユーザのログイン状態を維持する.メンテナンスログインは問題ありませんが、stateをusStateとして管理するため、リフレッシュ時にログインステータスが消失するため、リフレッシュのたびにサーバリクエストを再度送信してログインが有効かどうかを確認する必要があります.
    この場合、サーバリクエストが繰り返されるという問題が発生します.

    トラブルシューティング


    この問題を解決するため、4週目にredux-persistでログイン状態を管理することにしました.
    isloginステータスをlocalStorageに保存し、リフレッシュしてもステータスを維持できます.islogin=falseはログアウト時にのみログインステータスを変更します.

    🍉 kakao mapブートカードフィルタの適用


    地図ページを最初にレンダリングすると、地図を生成する論理が実現されます.let map = new kakao.maps.Map(container, options);しかし、この時問題が発生しました.
    userEffectでmapが宣言されているため、このmapはuserEffect以外でしか使用できません.varを使用するとグローバルで使用できますが、コードの統一性が消失したり、変数が重なる可能性があるなどの理由で、チームコードルールはvarを使用しないことを決定します.
    この問題を解決するために,多くの方法を考慮したが,最終的にこのコンポーネントの最上位層にlet=mapを設定した.宣言的に近づいた.
    このような宣言は必要な機能を実現することができるが、宣言変数は満足できるコードではない.

    🍉 ブートカードフィルタ


    問題の状況


    次の論理では、データ値を入力するとfilterInfo値が変更され、同じ条件でもサーバリクエストが繰り返されます.
    また,遅いネットワーク環境では,フィルタリング検索を複数回クリックすることで,不要なサーバ要求やサーバ負担の問題が発生する.
      const [filterInfo, setFilterInfo] = useState({});
    
      const filterSubmit = (data) => {
        setFilterInfo({ ...data });
      };

    トラブルシューティング


    このような事態を防止するために,条件に変化がないか否かを判別し,変化がなければサーバ要求を出さない.
    MapPage.js
    
      const [filterInfo, setFilterInfo] = useState({gender:'', startDate:'', endDate:'',});
    
    
      const filterSubmit = (...args) => {
        // 하나라도 필터링 조건이 바뀌어야 서버 GET 요청
        let [gen, start, end] = args;
        let { gender, startDate, endDate } = filterInfo;
    
        if (gen !== gender || start !== startDate || end !== endDate) {
          setFilterInfo({ gender: gen, startDate: start, endDate: end });
        }
      };

    難問


    ユーザが要求が正しいか否かを認識できるように、ビジュアルロード画面を挿入する必要がある.
    =>回転ロードを加えるのもいいですね.

    🍉 最悪だ...CSS


    思ったより悪かった...
    構造を再組織するようだ.


    🍊 DevLog


    反応型css地獄


    今日はどのようにプロジェクトに貢献しましたか。

  • 移動レイアウト修正
  • 修正
  • ガイドフィルタレイアウト
  • フィルタガイドカードサーバ要求
  • を実施する.
  • kakao地図ガイドカードフィルタエラー修正
  • ブートカードレイアウト実施
  • は、やっと反応型ページを所望のレイアウトに変更することができます.全体が触れるのが怖かったので迂回してアプローチしました.しかし、最終的なコードはさらに葛藤しているようで、全体のレイアウトを再調整し、反応型ページを再体現しています.
    実装プロセスは想像以上に困難ではなく,迂回アクセスを試みたときに記述されたコードよりもずっと簡潔であるようだ.
  • 今日のプロジェクトで苦労したことは何ですか。

  • cssはいつも骨が折れる.
  • ガイドカードをWebおよびモバイルバージョンに実装する過程で、多くのエラーが発生しました.これらの問題の原因は、まず、モバイルレイアウトを考慮せずにWebガイドカードレイアウトを作成したからです.不要な内容だけを簡単に表示:noneをあげればいいと思っていましたが、フォントサイズ、余白、flexなどの思いがけない動きで、粗末なガイドカードが生成されました.
  • 今日のプロジェクトで残念に思ったことは何ですか。

  • 応答ページの理解不足
  • はまだ反応型ページ番号を効果的に書く方法を把握していないようだ.レイアウトとコードの作成を認識する必要があります.
  • 明日は何をしてプロジェクトに貢献すればいいですか?

  • 地図ページサーバテスト
  • ブートモード
  • を作成
  • ガイドカードcss修正