Closed27

ブルーベリー本勉強会用🫐

ピン留めされたアイテム
koukou

これはなに?

分からないことを持ち寄ってみんなで考える勉強会です😌
気軽に、誰でも参加できることを目標にしています。

対象者

TS初学者からTS上級者までどなたでも

題材(対象本)

『プロを目指す人のためのTypeScript入門 初版』(→ Amazon

開催日時&回数

5/4(水) 21:00 ~(初回。多くて2~3回程度やりたい?)

進め方

  • 各自学びたい範囲を学び、自分が 「読んで理解出来なかったこと / わからなかったこと」 をこのスクラップにコメントとして残す
  • 勉強会当日までの期間、このスクラップに付いている他の人の「わからなかったところ」について、回答することができそうな場合は回答してあげる(できる範囲でOK!)(→ イメージ
  • 勉強会当日まで残った「わからなかったところ」について、勉強会当日参加しているみんなで考えてみる


  • 「分からなかったところ」の書き方については 書き方テンプレート 参照

  • 「分からなかったところ」が解消した場合は、チェックマーク(✅)を付けて解決済みであることを示す(付け方がマークダウン形式なので少し迷ってしまうかも...!)

注意点

  • 本を読んでいて「わからないところ」に遭遇した場合、まずはMAX15分ぐらいを目処にその周辺の単語を調べてみてほしいです!(見境なく目についたわからないことを投稿するとどえらい量になりそうなので…笑)。調べてみたけどそれでもあまりしっくりこなかったようなことを投稿して頂けると助かります!🙇‍♀️

懸念点

  • マークダウン記法に慣れていないともしかしたら結構書くの大変かも...
ピン留めされたアイテム
koukou

改善点など

改善点や反省点、ここをこうしたらもっとよくなりそうなどのメモです😌
この投稿に対する返信を通して、皆さんからのご意見等もお待ちしています🏋️‍♂️

# [良い点]
- Zennスクラップを用いた形式は結構面白い試みだと思っていたりする(これは今後も活かしたい)

# [所感(反省/改善点)]
- 勉強会に参加している感が薄い?
  - 何かスライドを作ったり記事にまとめたりという成果物の提出や読んでくる範囲の指定がない分(=責任が課されていない分)、個々人のモチベーションに依存してしまうという難しさがある(?)
- 勉強会に参加する人が何をしているのかが見えづらい?(→ からモチベーションに繋がりにくいとかある?)
  - ただこれは一般的な勉強会でも開催当日までは似たような感じである気がする🤔
  - [改]みんなで各自読む範囲を宣言してもくもく読む会を開くのは対応策となりえそう
- Zennアカウントを持っていない人への配慮足りていなかった説 is ある
  - 作成自体はGoogle垢連携なのでそこまでの手間ではないだろうけども
- 参加してくれる方へ連絡取る方法は改善点盛り盛りだった
  - 仲間募集Chで連投することになってしまったから、見ない人は見ないだろうし、勉強会用で一つグループ作ってもらうのが良かったかなあ🤔
  - 仲間募集Chに入っていない方へのリーチ策(100人弱)。アナウンスChで取り上げてもらうとか。
- 勉強会当日までの過程で、集まれる人のみで集まってもくもくと各自読み進める会を設けても良かったかも?(各自この時間でどこを読むとか最初に宣言しておくみたいな?)
  - 毎日21時とかから?もしくは隔日21時からとか?(定期開催よさそう)
- 学びになったところを投稿していくスタイルもあり?
  - 自分が読んでいなかった範囲のことを軽くでも知れるのはいいかも
  - 勉強会当日の運営難しそう(?)🤔(分からなかったところ列挙と比べて)
- Kindle版で読んでいる人だと「ページ」という概念がなくなるから、ページ指定はいらなそう
  - 「l章.m節.n項 項タイトル」だけで十分かも(ページは任意)
- ある程度スレッドが長くなってくると読むの大変(?)
  - GitHubのIssueベースでやるの面白そう
- 書籍の説明がとても丁寧だったため疑問点が特に生まれなかった説
- 今日やるイベント掲示板Ch欲しいかも?
  - カレンダーChとの差別化難しい?メンバー発のイベントを知れるCh
  - oVice内に「今週のイベント」ボードを作るのもよいかも(oViceよく来る人ターゲット)
    - 講座形式などの勉強会方式にはよさそう!
- 初回告知はSlackの@here付けてもよかったかも
- 勉強会当日にペアプロ?モブプロ?的に画面共有しながらコーディングするとか面白そう
  - 本写経 → 使われそうなケースを想定したり考えたりしてコーディングする(複雑にしていくイメージ)
- 見学大歓迎!聞き専OK!(本買ってないけど勉強会自体に興味ある人)
- 本で学んだことを実際に作ったコードに適用できるケースがあるかを探してみる
- GitHubのリポジトリを勉強会の疑問質問投稿の集約場所にする
  - Isuue単位で管理
- 本に学びになった感想を書き込んでいる人からするとここにもう一度書くのは二度手間説(自分)
  - 学びになったところ書くのは任意だけれども。

# [その他ご意見]
- 読むのに集中してしまってわからないところや疑問点のことを忘れがちかも(T.Maeさん)
koukou

分からなかったことテンプレート

以下のコードブロック内をコピペして使うと同じ形式でコメントを残すことができます。
勿論ご自身の好きに変えて頂いても構いません。🫐

分からなかったところが、回答コメントのおかげで分かったり、自分で調べて理解出来たときは、分からなかったところのチェックボックスにチェックマーク(✅)を付けて置いて貰えると判別しやすくて助かります!


以下をコピーして使用(コードブロック右上のコピーボタンからコピーすると楽です)

<!-- 例:P293 6.6.1 any型という最終兵器 -->
## ページ数 l章.m節.n項 項のタイトル

<!-- 分からなかったところが複数ある場合は先頭に①などの数字を付けて貰えると、回答する側が喜びます🍒 -->
- [ ] ① 分からなかったところ
- [x] ② 分からなかったところ <!-- 解決したものは [ ] の中に x を付けて解決済みに! ✅ -->

> 書籍からの引用を分かりやすく書きたい場合は、
> マークダウン記法の引用文を表す記法(`>`)を用いると見易いかもしれません。


<!-- 複数ページで分からなかったところがある場合は分けて頂けると見やすいです -->
<!-- 例:P295 6.6.3 anyに近いが安全なunknown型 -->
## ページ数 l章.m節.n項 項のタイトル
- [ ] ① 分からなかったところ

---

<!-- 自分の学びたい範囲を読んでいて、学びになったところなどがあればメモ用にどうぞ -->
## 学びになった / 印象に残ったところ
- ここを書くのは任意です(この項目自体を消してもOK)
koukou

P293 6.6.1 any型という最終兵器

  • ① p293上の方に、「次の例のように、関数の実体にそぐわない値を引数として渡してもコンパイルエラーは一切発生しません。そして、以下の呼び出しはすべてランタイムエラーという結果に終わります」とあるけど、 「コンパイルエラー」と「ランタイムエラー」の違い ってなんだろう?🤔

学びになった / 印象に残ったところ

p295 6.6.2の最後の方に書いてある、

あいまいな理解でanyを使用することは破滅的な結果を招くので、しっかりとした理由付けができないのであれば、まだanyを使用するレベルにはないと考えて使用を避けましょう

という部分を読んで、anyは何にでもなれるというわかりやすい性質上初学者のうちこそ使ってしまいたくなるが、anyを"正しく"使うことが出来るレベルはずっとずっと上だったんだなあ。

(※サンプル投稿です🥸)

koukou

[A] P293 ①
「コンパイルエラー」はTypeScriptをJavaScriptに変換している際に出るエラー?「ランタイムエラー」はブラウザがJSを実行するときに起こるエラー?🤔

koukou

P378 8.4.2 await式も使ってみる

  • ① p378の上から3行目あたりに書いてある、

その後も実行は続き、p.thenが実行され(これはコールバック関数を登録するだけで即座に何か起こるわけではありません)、その次にconsole.logが実行されます

という部分の「コールバック関数を登録するだけで即座に何か起こるわけではない」という部分がいまいちピンとこない。。。

(※サンプル投稿です🥸)

koukou

[A] P378 ①
個人的な感覚としては、コールバック関数は「あとで呼び出す(呼び出してもらう)関数」って認識するのが分かりやすいかなあ。「あとで呼び出す関数」を登録するだけ登録して一旦処理が終わるってことかな。

  1. 今回で言えば、まずPromiseオブジェクトであるpthenメソッドに「あとで呼び出す関数(コールバック関数)」を登録(渡しておく)しておく(ここでは登録だけするなので「あとで呼び出す関数」はまだ実行されない。ここが書籍内で言っていること)。
  2. Promiseオブジェクトが持っているthenメソッドに登録した「あとで呼び出す関数」は、Promiseの解決時に実行されるので、Promiseが解決したタイミングで、1.で登録してあった「あとで呼び出す関数」が実際に呼ばれて実行される

みたいなイメージかな?🤔

[参考]

T.MaeT.Mae

このリンク、整理する上でも分かりやすくて良いですね〜
(サンプルとは、ありますが有用だなと思ったので回答させて頂きます。

koukou

コメントありがとうございます!

このシリーズとてもわかり易くて良いですよね笑
大変お世話になってます🥸

shin_k_2281shin_k_2281

自分も疑問点として、awaitが完全にそこで「止まる」みたいな認識だったのでこの部分の挙動は謎でした。
get3関数のawaitに差し掛かった時点で一旦const p = get3()のPromiseオブジェクトpはpendingとなるため、その後に行われるthenメソッドにおけるコールバック関数の登録ではpがpending状態なために実行まではされない。って感じでしょうかね🤔

「awaitに対してPromiseを渡した場合そのPromiseの完了を待機します」となっているのにawait部分でget3関数を中断しているみたいな挙動で一層????となりましたw

shin_k_2281shin_k_2281

普段何気なく使っているasync/awaitは、awaitの実行によってそ間の処理を、その処理があるasync関数の戻り値のPromiseオブジェクトをpendingとすることで可能としているみたいな感じですかね🤔

koukou

@shin_k_2281
総じて、難しい😂笑

awaitが完全にそこで「止まる」みたいな認識だった

自分もこの感覚でしたね〜

貼っていただいた記事ちゃんと読まねばと思っていたところでした読みます!😂

koukou

[所感]
つまみ食い的に色々なところをちょこちょこ読んでいるけれど、この本説明が本当に丁寧で、自然と「ん?」となるようなところが今のところ殆どない。
というか、「ん?」となることはあるけど、殆どの場合その直後にそれに対する解説があったりして、想定されうる疑問は大体解決されるように組まれている感じ。気持ちいい。

これは本当に凄い良書説濃厚🤔

YuriYuri

2.3.10 プリミティブ型同士の変換(2) 明示的な変換を行う (121P)

学びになった / 印象に残ったところ

  • ランタイムエラー
    ランタイムエラーという概念は、恥ずかしながら、今までただのエラーの一部というふわっとした感覚でしか考えていなかった。
    この章の中では、ランタイムエラー  = 「例外」というふうにとらえてよいと書いてあるようで、学びになった。
    ただ、これが発生したときにはtry-catch文でハンドリングしないとプログラムが強制終了するとか、とくに避けないといけないなどと書いてあり、このエラーが起きた時、今までなんとなくやり過ごしてきたのは間違いだったと気づけました。
    詳しくは5章で学習できると書いてあるので、引き続き読んでみたいと思います。
YuriYuri

P226 3.2.5 任意のプロパティ名を許容する型(インデックスシグネチャ)

学びになった / 印象に残ったところ

コラム9 インデックスシグネチャに潜む罠

なにげなくその存在を認識していたインデックスシグネチャ。

(基本形)
[キー名: string] : 型
こうすると、任意の名前のプロパティが型を持つという意味になります。

type PriceData = {
 [key: string]:number;
}

const data: PriceData = {
 apple: 220,
 coffee: 120,
 bento: 500
}

// これはOKになる

data.chicken = 250;

//これはコンパイルエラー :Type "foo" is not assignable to type 'number'.

data.弁当 = "foo";

ただ、インデックスシグネチャは、「TypeScriptが保証する型安全性を破壊することができる」ので、注意しながら使う必要があるみたいです。

インデックスシグネチャがあるオブジェクト型では、実際にプロパティが存在するかどうかとは無関係に、「どんな名前のプロパティにもアクセスできる」という特性を持っているようです。
この特性により「型安全性」が破壊されてしまうらしい。

TypeScriptでは、インデックスシグネチャがあると、こうした特性によってコンパイルエラーを発生させないため、よくないようです。

TypeScriptで型安全にしようとしているのなら、インデックスシグネチャを使うことは避けるべきと書いてありました。

koukou

Yuriさんの投稿を見て自分もこの部分を読んでみたのですが、インデックスシグネチャが型安全性を破壊する懸念があることは初耳でした。👀
また、p92 コラム9最後の方の、型安全性に懸念のあるインデックスシグネチャを使用する代わりにMapオブジェクトを用いることで型安全に代替が出来るというのも初めて知りました!

学びになった…🥳

T.MaeT.Mae

書籍とkindleでページが違う??
(メモ)書籍だとP90

コラムはまだ、ちゃんと読んでいないですが、
読み進めていて3.2.5 は改めて読み返したので
じっくり理解しないといけなさそう、と感じました。

アーカイブのTypeScript講座で一旦は、
雰囲気掴んでいたけれど、
やっぱり読んでみるとすんなり入ってきにくそう。

同じく印象に残りました!

YuriYuri

ありがとうございます!
なるほど、Mapオブジェクトを用いると型安全に代替ができるんですね〜😃
また読み進んでみたいと思います。

koukou

@T.mae
あ、なるほど!
Kindleだとページ数が書籍と異なるの完全なる盲点でした!👀

電子書籍で読んでる方のことも考えると、ページ数の表記はなくして(あるいは任意として)「l章.m節.n項 項タイトル」の部分だけの方がよさそうですね🙋‍♀️

YuriYuri

書籍とkindleでページが違う??
(メモ)書籍だとP90

👀あらそれは知らなかった..笑

T.MaeT.Mae

コラム何気に難しかったので、まだTypeScriptを実際に活用出来ていない今は、
ちょっと理解を深めるのは断念し、もう少しレベルが上がった時に、
振り返ってみようと思いました!

型推論の3.1.3 とかの解説が腑に落ちないと言うか、
今は何言ってるか分からん。になった😓

アーカイブ動画でそれっぽいところだけ
つまみ食いしてみたけど、全体通して理解を
深めるのがまずは近道?かなーと。

shin_k_2281shin_k_2281

P240 5章 コラム25 「throwは何でも投げられる」

学びになった / 印象に残ったところ

try {
  
} catch(err) {

}

このtry-catch構文における引数errの型はunknownになる。
これはthrowが何でも投げられることに起因するものであるため、「何の型かわからない」ことを表すunknownに推論されるのには納得がいく。

また最近のReactで実装されているSuspenceに関する言及も勉強になった。

また、エラーを表す以外の目的でthrowを用いるというなかなかアグレッシブな手法も存在します。最近ではReactという人気の高いライブラリが、Promiseオブジェクトをthrowすることでコンポーネントのサスペンドを表すという斬新なコンセプトを発表したことでフロントエンドの界隈が騒然としたのが記憶に新しいところです。

throwのもつ「大域脱出(※1)」という性質はうまく活用できるシーンが他にもあるのではないかと思った。

koukou

Suspenseの発想は本当に奇抜で面白いですよね〜

Suspenseの元になった発想(?)らしい「Algebraic Effects(代数効果)」について、Danさんが説明してるブログ記事があるんですが、これだいぶ難しいんですが面白かったです!🙋‍♀️

https://overreacted.io/ja/algebraic-effects-for-the-rest-of-us/

shin_k_2281shin_k_2281

P93 3.2.8 typeofキーワードで変数の型を得る

P273 6.3.2 typeof演算子を用いる絞り込み

学びになった / 印象に残ったところ

上記2つの項を見るとわかるが、typeofには2種類ある。

const num: number = 0;

// 型としてのtypeof
type Piyo = typeof num
// 演算子としてのtypeof
const piyo = typeof num
koukou

P301 6.7.2 型述語(ユーザー定義型ガード)& P53 2.4.4

学びになった / 印象に残ったところ

x == null という書き方

ユーザー定義型ガードの説明用コードで、

function isHuman(value: any): value is Human {
  if (value == null) return false;

  // 以下略
}

というコードがあって、見慣れないvalue == nullが使われていたので、参照先である P53 2.4.4 比較演算子と等価演算子 のところに戻って少し読んでみたら、どうやら厳密等価ではない == 演算子を使ってもいい場面がこの x == null の場面だということを知った。

厳密等価を用いて表す場合は、x === null || x === undefined。確かに見易さの点では x == null の方が良さそうだけれど、なんとなく、x == null の場面だけ == が出てくるのにはもどかしさというか気持ち悪さがあるなと言ったところ🙂

参考:JavaScript: Check if Variable is undefined or null

T.MaeT.Mae

P100 3.4 型引数を持つ型

P101 3.4.3 部分型関係による型引数の制約

  • 3.3 部分型関係からカタカタ出てきて本読むだけだと分かりづらい
    言葉と例がセットになってはいるが、実際にコード入力しながらとかがオススメかも
このスクラップは2022/05/26にクローズされました