↑前半の振り返り
要約
ものづくり系
個人開発 x 1 LT x 1 threeを使ったポートフォリオ x 1 ``` 習慣系
毎日React記事 読書週一冊 毎週の振り返り
# 後半はどういう年にするか 前半は転職先の情報のインプットが多い半年だったので、後半はその学習した内容に関するアウトプットを増やす半年にしたいなと思います。 来年あたりでECサイト作成に取り掛かれるように、今年てフロントエンド周りの知識ガンガン蓄えたいと思います。 おしまい
↑前半の振り返り
ものづくり系
個人開発 x 1 LT x 1 threeを使ったポートフォリオ x 1 ``` 習慣系
毎日React記事 読書週一冊 毎週の振り返り
# 後半はどういう年にするか 前半は転職先の情報のインプットが多い半年だったので、後半はその学習した内容に関するアウトプットを増やす半年にしたいなと思います。 来年あたりでECサイト作成に取り掛かれるように、今年てフロントエンド周りの知識ガンガン蓄えたいと思います。 おしまい
人生で初めて振り返りの記事を書きたいと思います。
ということでいってみよう。
参考にした記事を三つ。
マイナビのいかにもって感じの記事です。
フレームワークを色々探すより、考えることがシンプルなのが好き。
gakumado.mynavi.jp
料理アドバイザーの先生のブログ。
仕事の話だけでなくプライベートも整理してるのが好き。
smart-kitchen.jp
masakichiさん、最近かけ出したお方。参考にさせていただきます。
毎月のやっていることを振り返っていて好き。
qiita.com
↓↓↓↓
全然そんなことありませんでした(笑)。
成長実感よりも、全然ついていけてないことを実感するばかりです。
↓↓↓↓
理想通りで、音楽大好きでフラットなチームでした。
実装したいフレームワークやサービスも続々提案されていて素敵なチームです。
↓↓↓↓
想像以上にめちゃめちゃ書けてます。
オンボーディングで既存のサービスを理解しながら実装を進められて、
新規サービスにアサインされつつアウトプットできてるのでめっちゃチャンスだなと思います。
↓↓↓↓
妄想でした。夢でした。
持ち前の仕事の遅さと怠惰が仇となり、平日夜はあんまり時間取れませんでした。(笑)
仕事面の妄想と現実についてざっくりまとめるとこんな感じです。 ・転職して想像以上にフロントエンドエンジニアとして成長できる環境をGetできた。 ・妄想してたほどの成長はできてないし、仕事以外での個人開発などもそこまで進められなかった。
エンジニアや会社の皆さんとのコミュニケーションを図るイベントが多く自分を知ってもらう時間でした。仕事はオンボーディングとして、パソコンの環境構築、会社説明のMTGなどの仕事するための準備系と、実際に細かいチケットを行いながらサービスについて触れる機会を作っていただきました。実際に自社サービスを使って社員が何を行っているかを知るために他の社員がやっていることもさせていただきました。 実際のオンボーディング時はリモートの環境下でも常にmeetを繋いでいただけて質問したい時に質問できる環境でした。
小さめのプロジェクトに初めてアサインしていただきました。ボタンを追加する、バナーを作成し実装する、ラベルを追加する、OGPを追加する、などのタスクを行いました。PMの方とも初めて連携しながら実装させていただいたので貴重な経験を得られました。本当だったら簡単に終わるはずの実装が「テストコードを書く」「レビューをいただく」「実装を再検討する」ことなど、想定できていない工数が無限に増えてしまうタスクにもぶつかりました。貴重な経験と同時に、反省点も多く見つかりました。ここで初めて以前書いていたjavascriptが通用しないことに気が付きボッコボコでした。
Javascirptで特定の文字を弾く実装を組む、一つのページをリニューアルするという実装を行いました。ここで初めてページ全体をReactで実装するということに挑戦させていただいたのですが、大苦戦。Typescriptの型、Rceatの挙動やコンポーネント設計、さらには実装の進め方などの理解が全然追いついていないことを痛感しました。進捗悪いので頑張らなくちゃーって思う一ヶ月でした。
正式に新規のサービスにアサインさせていただき、設計段階がスタートしました。改めて既存のサービスのコードを比較しながら、一ヶ月かけて新規サービスのコンポーネント設計をさせていただきました。あまりコードは書かなかったなという印象です。
いよいよサービス開発がスタートしました。ページ作成、ヘッダー、テンプレートの外枠、ログイン、サインイン実装を行いました。ここで初めてDomain層やData層の理解がつかめてきました。先輩方が教えてくれたクリーンアーキテクチャをコードを持って理解し始めており、少しだけ理解が進みました。ちょっとずつコードが良くなっている!と言われることもあり涙ポロポロです。
というような五ヶ月間でした。これからも頑張りたいと思います。
「会社の歓迎会と同期飲み会が割とフランクに皆さんと打ち解けて素敵な会だった」
「とあるオンボーディングでのラベルの実装」
「新規開発の設計、コンポーネント設計」
「サインイン画面、サインアップ画面の実装」
「とある開発で丸々二週間遅延してしまい、迷惑かける」
「三ヶ月目、チケットが全て終わらなくてテンションの低いスプリント最終日」
「これは私じゃなくて〇〇さんにお願い、、の瞬間 TT」
「UIの改善タスクを他のメンバー任せにしてしまっていること」
「書いているコードが全くレビュー通らない時」
楽しい時はスムーズに実装が完了する時や理解度が上がっていると実感する時が主でした。
逆に苦しかった時は、自分の無力感を改めて痛感した時と、レビューでゴリゴリ言われちゃう時。
貴重なレビューがあって今があるので、これからもたくさんレビューを頂こうと思います。
などなど、この半年は仕事のインプットと転職転居に時間が注がれたなと実感しました。
暇な時にやりたいことリスト、略して「暇人リスト」なるものがあります。
そのうち一つだけ達成しました。
「音楽関係の仕事に就く」😤
書いてみるもんですね笑
ということで2022年前半の振り返りでした。
次の半年の目標は別の記事で考えようと思います。
ではでは〜!
実装のレビューで素敵な書き方を教えていただいたのでメモ。
ステータスを受け取り
その結果に応じてreturnが異なるコンポーネントがあります。
ここには主に以下のような改善点があります。
- マジックストリングを用いない (複製や多くの箇所でValueStatusを呼び出した際に、値を変更するのがしんどいため)
- 一箇所から呼び出せていない (今日はここがメイン)
import React from "react"; import { ValueStatus, VALUE_STATUS } from "./model"; export type ValueStatus = "success" | "failed" | null; interface Props { valueStatus: ValueStatus } const Modal : React.VFC<Props> = ({ valueStatus }: ValueStatus) => { if (valueStatus === "success") { return <div>成功しました</div>; } if (valueStatus === "failed") { return <div>失敗しました</div>; } return <div>デフォルト</div>; }; export default Modal;
//model.ts import React from "react"; export const VALUE_STATUS = { SIGNUP_SUCCESS: "success", SIGNUP_FAILED: "failed", DEFAULT: null }; export type ValidateStatus = ValueOf<typeof VALUE_STATUS>;
//index.tsx import React from "react"; import { ValueStatus, VALUE_STATUS } from "./model"; //型と定数を取り出す const Modal : React.VFC<Props> = ({ valueStatus }: ValueStatus) => { if (valueStatus === "success") { return <div>成功しました</div>; } if (valueStatus === "failed") { return <div>失敗しました</div>; } return <div>デフォルト</div>; }; export default Modal;
これで、一つの参照先を変更するだけで一括で切り替わるようになりました。
教えてくれてありがとうございます。。!
コードを書くときは以下を意識する
- マジックストリングをできるだけ書かないように
- 型と定数はDomain層から呼び出せるように
- SSOTを意識し、一つのオブジェクトから定数と型を引っ張ってこられるようにするとGood
現在開発中のサービスにおいて
既存のAtomic Design に沿ったコンポーネント設計をしております。
Atomic Design がよくわからなかったのでメモしていきます。
Atomic design is methodology for creating design systems. There are five distinct levels in atomic design: Atomic design はデザインシステムを構築するための手段(方法論)です。大きさのレベルに応じて5つの要素に分類できます。
Atoms, Molecules, Organisms, Templates, Pages それらは Atoms, Molecules, Organisms, Templates, Pages の五つです。
つまり、Atomic DesignはUIを構成するコンポーネントを5つのコンポーネントレベルに分け、
その五つを組み合わせることで全てのUIを表現する手法のことです。
(参照: https://bradfrost.com/blog/post/atomic-web-design/)
「モジュールが持つ責務は一つにすべき」という考え方のこと。
Atomic Design でいうところの Atomに一つの責務を置き、それらを組み合わせてアプリケーションを開発する。
「大きな課題を小さく分割することで課題解決をしていく」という考え方。
最近コンポーネント設計をしていて、
単一責任の法則も分割統治法も「コンポーネント一つのタスクを最小限にして問題解決、リファクタしやすくする」
ための基本の考え方みたい。
哲学っぽくて面白い。。
参考
https://zenn.dev/offers/articles/20220523-component-design-best-practice
sort()メソッドは、配列の要素をソートする関数のこと。
https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/Array/sort
配列にsort() を実行すると昇順に並び替えてくれます。
定義した配列そのものが変更されているので、破壊的変更が加わっていることになります。
const nameList = ["Batto","Atsuki","chieko","Den"]; console.log(nameList.sort()) //["Atsuki", "Batto", "Chieko", "Den"]
nameList.sort()だと、nameListそのものの配列の順序が変わってしまいます。
それだとイミュータブルの観点からデバックしにくくなってしまいます。
残余構文を利用して、以下のように書き換え
const nameList = ["Batto","Atsuki","chieko","Den"]; const newNameArray = [...nameArray].sort() //newNameArray → ["Atsuki", "Batto", "Chieko", "Den"] //nameArrayはそのまま
ミューテーションについてはこちらの関数型プログラミングお姉さんの動画がおすすめ(笑)
https://www.youtube.com/watch?v=e-5obm1G_FY
実はsort()の第一引数に関数を追加することで並び順を制御することができます。
デフォルトの昇順は以下のような比較関数になります。
nameList.sort((a,b) => a + b) //昇順
そして降順は
nameList.sort((a,b) => a - b) //昇順
以下のようなオブジェクトでもソートできるということ。。。すごいですよね、、
const stations = [ {name: "池袋", users: 55223}, {name: "新宿", users: 10000}, {name: "渋谷", users: 300}, {name: "東京", users: 400000}, ] const stationsOriginal = stations.sort((a, b)=> a.users - b.users) //結果 const stations = [{ "name": "渋谷", "users": 300 }, { "name": "新宿", "users": 10000 }, { "name": "池袋", "users": 55223 }, { "name": "東京", "users": 400000 }] //うおおお
今まではsplice(num)などを利用して
配列を切り分けて取り出していたのですが、最近はもっと直感的な取り出し方があるみたいです。
配列があります
const smalls = [ "小動物", "小型車", "小論文" ];
まとめて取り出すことも可能!!
const [a, b , c] = smalls; //a = '小動物
スプレッド構文を用いて、一番目以降の配列を取得します。
const [, ...other] = smalls; //["小型車", "小論文"]
新しい配列を作るときは左辺に代入していくのではなく、右辺で配列を直接作って代入する。
const smallsAnime = [ "コナン君", "小次郎" ] const newArray= [...smalls(slice(0,2),"小売業"],...smallsAnime )] //[ "小動物", "小型車", "小売業", "コナン君", "小次郎"]
直感できでわかりやすい、、これから使ってみよう。
今日はUtility Typesについて学んだので、その学習メモ。
さまざまなユーティリティーがあるが、その一つを例にとってみると少し理解が深まりました。
今回はPartialについて。
Typescriptが提供する型の関数のようなもの。
元のインターフェースを利用し、新しい型を作成することができる。
それぞれのプロパティをoptionalにしたいときに利用する。
//インターフェースがあります interface Todo { title: string; description: string; } //インターフェースTodoをもつtodo1 const todo1: Todo = { title: "orgnize desk", description: "clear clutter", } //アップデートするための関数 function updateTodo(todo: Todo, fieldsTodUpdate: Partial<Todo>){ return {...todo, ...fieldsTodUpdate}; } //updateTodoを利用し第一引数にコピーしたいオブジェクト、第二引数に追加したいオブジェクトを追加 const todo2 = updateTodo(todo1, {description: "throw out trash",})
この時、updateTodoの第二引数の型を
Partial<Todo>
にすることで、「Todoのプロパティーのうちどれか」を実現することができます。
こんな感じで、ユーティリティーを使うと元々のインターフェースを加工した型を表現することが可能です。
他にも特定のインターフェースを減らしたり、増やしたり、レコードを作成したり、色々できるみたいなので
現場のコードと照らし合わせつつ勉強していこうと思います。
https://www.typescriptlang.org/docs/handbook/utility-types.html