GPM Adminプロジェクト

GPMはpixelというフェイスブック分析ツールを入力し管理するバックグラウンドオフィスです.7月中旬から現在まで、伝統がないまま6週間ほど開発が行われています.

フォルダ構造の問題

POC期間中からフォルダ構造に悩んでいます.私はatomic設計モデルから発展しようとしたが、いくつかの限界があり、会社の既存の構造に従って仕事をし、最後に次の構造の中で定住した.
汎用ロジックは、最上位レベルで管理され、featuresというサブフォルダに各ドメインに関連するロジックが作成されます.これにより、ドメインや機能を追加する際に拡張が容易になり、ドメインの結合度が低下し、メンテナンスが容易になります.これにより、より直感的になり、再構築や追加機能を実装する場合、ドメインはまったく影響を受けず、フォルダでのみ動作します.非常に満足できる構造なので、会社のプロジェクトや個人のプロジェクトでは、短期間でこの構造が使われるはずです.
https://github.com/alan2207/bulletproof-react?fbclid=IwAR0Q3gck2B9CZyPaU5bEsA96NADfd0AA1t79uc_ZvN1C80JuAAN1w3ScvsQ

├── assets
├── components
│   ├── Elements
│   ├── Form
│   └── Head
│   └── Layout
├── features
│   ├── auth
│   │   ├── api
│   │   ├── components
│   │   ├── routes
│   │   ├── types
│   │   ├── hooks
│   │   └── index.ts
│   ├── comments
│   ├── teams
│   └── user
├── hooks
│   └── useHooook.ts
├── lib
│   ├── auth.tsx
│   ├── axios.ts
│   ├── react-query.ts
├── store
├── types
└── utils
    ├── format.ts
    ├── lazyImport.ts
    └──  storage.ts

react queryの導入

apiリクエストは通常redixミドルウェアを使用しており,今回はreact-queryを導入した.
使用後

ミドルウェアの使用に比べて、論理は大幅に減少しました.

のロード、エラーなどの状態の処理が容易

Reduxを使用することなく、サーバから受信したデータを複数のコンポーネントで使用できます.
欠点は

clickイベントなどを使用してrefetchを行う場合、Effectを使用する必要があります
詳しい使い方は別途発表します!

reduxを書かない

apiの呼び出しに加えて、パブリックステータス管理は不要のようですので、本プロジェクトではreduceを使用しないことにします.主にreduxで処理されているログインでは、苦労してしまいましたが、どうすればいいのでしょうか.(再確認方法)
私が働いたコンポーネントには、他のドメインに分離された2つのケースがあり、1つのモードで使用されたケースは、最上位コンポーネントに互いに共有されたデータを加え、propsで伝達し、実現し、context 사용했으면 어땠을까요のフィードバックを受けた.ステータス管理ライブラリを無条件に使えないと思ったので、reduceの必要性だけを切実に感じました...そうじゃない...思わなかったcontext.reduceは使用していませんが、reduceを使用していないため、かえってreduceや状態管理、contextなどの全面的な理解に欠けていると感じます.最近、なぜリドスが嫌われているのか、他の新しいステータス管理ライブラリに何があるのか、なぜ現れたのかを学びます.

JIRA

JIRAのスプレー愛子デー方式でプロジェクトを行った.プロジェクトをするとき、自分が一番発展している部分はこの部分だと思います.집중という噴霧剤の概念を理解し,よく実行されていると考えた.切符を小さく割って、私がしなければならないことを直感的に把握して、やっていることを把握して、注意力を集中することができます.仕事中に他の修正事項を見ていると、すぐに処理したいという気持ちになりますが、新しいチケットを作って、仕事が終わってから仕事をするほうが効率的です.また,PRを行うと,コメンテーターもコードを把握しやすい.仕事のやり方に慣れている.追加の愛子の働き方を学ぶ必要があります.

コードコメント、再構築、公平なプログラミング

プロジェクトで一番苦労しました!一番意味があるのは!これは公平なプログラミングによって実現された再構築である.我々の公平なプログラミングの目的は,それぞれ異なる符号化スタイルに合わせて,今後のプロジェクトで一貫したスタイルを維持し,再構築によってコード品質を向上させることである.私が作ったコードを相手に理解させ、私の考えとは異なる部分を調整し、私がずっと堅持してきたスタイルを捨てる過程は容易ではありませんが、私は多くの異なる観点、異なる方法を学び、再包装を通じてより良い結果を創造することができます.ただ、他の方法が過程をもっと難しくして、もっと楽しくすることができるかどうか分かりません.さらにantdの使い方やrappingレベルなどを統一して使いたいのですが、できなくて残念です.

脈絡について

最近、頭がなくて仕事をしていると感じている人が多い.明らかに、1週間の噴霧剤単位で、仕事はよくできたが、発行がずいぶん遅れた.2、3週間で実現が早かった...?プロジェクト全体の日程に対する認識はないと思います.また、2ヶ月も働いていますが、会社のドメイン名や製品に対する理解はまだ不足しています.私はまだ新人の考えを持って深く理解していないと思います.そして反省...仕事中はいつも脈全体を考えています!!

発展する

トークン関連ロジックのリフレッシュ

型使用習慣

勉強する

改造2版

たくさんの評価の話を聞いただけで、やっているふりをしているだけで、どうしてやるのか、どうするのか分かりません.この点を理解するために、週に2回勉強します.今月、再構築とは何か、なぜ再構築するのか、コードのどの部分を再構築すべきかについて読みました.(ch 1,2,3)
なぜ開発者の仕事の8割が名前をつけたのか理解した.私は実践の中で始める前に再包装する原則を制定しましたが、いつも忘れています...^^;

ブラウザ101

JavaScriptとブラウザの働き方をよりよく理解するためのレッスンです.授業内容は私の目的に合っているが、進度が遅すぎる.とにかく今月.

web api

アクティビティ

crpについて学習と総括を行った.

来月の目標

精算項目給油

browser 101受講

運動は週に3回必ず

をしなければならない.

免許証

再包装勤勉読書

webpack、aws

を理解