アンサー: named exportは有害なのか - uhyo/blog
こんにちは。ここ数日は、以下の記事が話題になりました。 named exportは有害だと考えられます「named exportは有害」という主張はこれまで常識と思われていたこととは異なるため、界隈のエンジニアからは否定的・懐疑的な意見が見られます。実際、筆者もnamed exportが有害であるとは1ミリグラムも思っていません。 しかし、自分と異なる意見は当然に下等・幼稚なものであるというのは筆者が最も嫌う考え方ですから、このような異なる意見を分析・理解する必要があると思い、アンサー記事という形でまとめました。具体的には、異なる意見に達する理由としては前提が異なることと論理が異なることが主に挙げられます。前提が異なることが分かれば、自分と異なる意見に至った理由を理解でき、場合によっては取り入れることもできます。論理が違うのであれば、それは瑕疵であり指摘しなければいけません。 なお、そもそ
2021年のTypeScript環境構築で絶対入れるべき「better-typescript-lib」の紹介 - Qiita
こんにちは。この記事は筆者が開発した「better-typescript-lib」を宣伝する記事です。これは、導入するだけでTypeScriptプログラムがより型安全になるという素晴らしいライブラリです。あくまで型定義なので、導入してもランタイムの挙動は何も変わらず、バンドルサイズなどへの影響もありません。 better-typescript-libの導入法 ここに記載されているのはv1 (TypeScript 4.0 〜 4.4向け）のインストール方法です。v2 （TypeScript 4.5〜）ではインストール方法が変わり、最初のnpm installのみで良くなります。詳しくは次の記事をご覧ください。
Active Recordから考える次の10年を見据えた技術選定 / Architecture decision for the next 10 years at PIXTA
September 15, 2021 @ iCARE Dev Meetup #25
TypeScript * GraphQLのバックエンド設計プラクティス
2冊目も公開中なのでみてください！ https://zenn.dev/tatta/books/4e993c596e7dc9 TypeScriptを使いはじめて1年になるので、バックエンドのWebアプリを設計するときに気を付けていることをまとめました。（※社内勉強会用資料の公開版です。） TypeScriptについては、Next.jsを中心にフロントエンドに関する公開情報が豊富です。一方でバックエンドに関する公開情報が少ないと感じています。（かくいう私もNext.jsからTypeScriptデビューしたわけですが） TypeScript * GraphQL という構成は仕事・趣味で採用されている方も多いのではないでしょうか？ 私もその1人です。私のような方のためにも、バックエンドの設計プラクティスについてまとめようと思い筆を取りました。 本書がこれから始める読者にとっては教科書のようになり、
Next.js の InferGetStaticPropsType が便利
Next.jsのサンプルリポジトリを眺めていたらInferGetStaticPropsTypeというものを見つけました。これを使うと、getStaticPropsでreturnされた値をもとに、Pageに渡されるPropsの型を類推してくれます。 ↓ ドキュメントはこちら これまではこんな感じで書いていた これまではPropsの型宣言を自分で書いていました。 import { GetStaticProps } from 'next'; // 👇 type Props = { posts: Post[] }; export const getStaticProps: GetStaticProps<Props> = async () => { const { posts } = await getPosts(); return { props: { posts, }, revalidate:
DevTools architecture refresh: migrating DevTools to TypeScript | Blog | Chrome for Developers
This post is part of a series of blog posts describing the changes we are making to DevTools' architecture and how it is built. Following up on our migration to JavaScript modules and migration to Web Components, today we are continuing our blog post series on the changes we are making to Devtools' architecture and how it is built. (If you have not seen it already, we posted a video on our work of
JavaScript / TypeScript全体研修を実施 ~歴史あるサービス保守からモダンフロント開発まで幅広く手掛ける為に~ | NIJIBOXのフロントエンドエンジニア
フロントエンドグループ JavaScript / TypeScript全体研修を実施ニジボックス フロントエンド開発室の高橋です。 3月4日、3月11日の2日間にかけて弊社、株式会社ニジボックスのフロントエンドグループ全体を対象にJavaScript, TypeScriptの全体リモート研修を実施しました。講師にはリクルートから３名のプロフェッショナルをお招きしました。参加者は総勢で50名近くになりました。 今回この研修の企画運営メンバーの一人として携わりましたので、研修当日の雰囲気や研修後の成果を含めてご紹介させていただきます。 ニジボックスフロントエンドグループの現状と課題ニジボックスフロントエンドグループはSUUMO, ゼクシィをはじめとしたリクルート内のWebサービスのフロントエンド業務に幅広く関わっています。 業界も様々ですが、使用している技術や開発フローもプロダクトによって大き
TypeScript＋Reactで安全に動かし続けるために LINE証券のフロントエンドにおける型安全性への取り組み
2020年11月25〜27日の3日間、LINE株式会社が主催するエンジニア向け技術カンファレンス「LINE DEVELOPER DAY 2020」がオンラインで開催されました。そこでLINEのフィナンシャル開発センターFront-endチームのフロントエンドエンジニアである鈴木僚太氏が、「LINE証券フロントエンドにおける型安全性への取り組み」というテーマで、TypeScript＋Reactで安全に開発を続ける方法について共有。前半は「LINE証券」のフロントエンドがどのように作られているかについて紹介しました。 LINE証券フロントエンドにおける型安全性への取り組み 鈴木僚太氏（以下、鈴木）：このセッションでは『LINE証券フロントエンドにおける型安全性への取り組み』についてお話いたします。私はフィナンシャル開発センターの鈴木僚太と申します。よろしくお願いします。 最初少し自己紹介をさせ
ESLint, Prettier, VS Code, npm scripts の設定: 2021春
eslint-plugin-prettier 時代の設定をずっと使っていたので、重い腰を上げてアップデートした作業メモ。 背景 Prettier 公式ドキュメントによれば、現在 eslint-plugin-prettier は以下の問題があるとして推奨していない。 エディタが真っ赤になる（人間が気にする必要のない問題なのに！） 直接実行するより遅い（同様に prettier-eslint も遅い） ESLint と Prettier の間に間接レイヤーを追加するので、壊れやすい なるほど正しい。 一方、別々に実行することで以下のような問題も出てくるので、解決していく。 CLI とエディタを個別に設定する必要がある エディタで ESLint と Prettier の協調動作が必要 CLI (npm scripts) で ESLint と Prettier の対象ファイルが別管理になる 上記の
最近の ESLint とかの構成2021
みんな好きな構成を好きなように入れれば良いと思ってるけど、自分が最近やってるやつを雑に紹介する。 シンプルなTypeScriptのプロジェクトを想定している。 npm install --save-dev eslint prettier typescript eslint-config-prettier @typescript-eslint/parser @typescript-eslint/eslint-plugin npm-run-all
TypeORMはNode.js開発のスタンダードになるか？ - Qiita
こんにちはGAOGAOの代表をしております @tejitak です。GAOGAOアドベントカレンダー 17日目の記事です。GAOGAOのスタートアップスタジオにて、最近お手伝いしている海外のお客様案件にてTypeORMを導入しています。 今回の記事では、TypeORMとはなんぞや？という方を対象として、まだ比較的日本語記事が少ないTypeORMについてのご紹介します。 Node.jsのORM Node.jsでサーバーサイドを実装する際にはExpressを使うことが多いと思います。ExpressはサーバーサイドのWebフレームワークで、データベースを扱うORMは自由に導入することができます。以下代表的なORMを紹介します。 mongoose 公式ドキュメント： https://mongoosejs.com/ MongoDBはJavaScriptとの相性の良さから昔からNode.jsの多くのプ
atoms の「制御・非制御」をどう作るのか
本稿では React で atoms を作る際「制御・非制御」どちら前程に作るべきか？という課題についてを考察します。 「制御・非制御」は atoms では決定しない なぜ決定しないのかは「ライブラリ選定に縛られないため」につきます。Form 関連ライブラリはたくさん選択肢がありますが、この選定が atom に影響するのはあまり良いパターンではありません。 「制御・非制御」は atoms では決定しないといっても、正確には以下の「A・B」のうち 「A」で決定しない という意味です。以下「A・B」の様にきちんと分けて構成することで「A」は「制御・非制御」に囚われず、再利用することが出来ます。 A. 【"style"決定層】CSS のみが適用された element 集 B. 【"制御・非制御"決定層】A を用いて、再度小さい atom を構築する CSS in JS 以外での定義 CSS in
ミニマルなモーダルライブラリをnpmで公開しました
ミニマルなモーダルライブラリ(MinimalModal.js)を自作してみたので紹介します。 MinimalModal.js とは 🤔 TypeScript で作成された、軽量かつ最小限の機能のモーダルライブラリです。 なんでこのライブラリ作ったの？ 🤔 Micromodal.jsを使おうと思ったのですが、 背景スクロール無効がなかったり、IE 未対応といったところが私の用途には合わなかったため、 いっそのこと作ってしまったほうが早いかなと考え、作ってみました。 機能 😋 モーダル用エレメントの open 属性の有無、及び aria-hidden の true/false の切り替え (開閉のアニメーションは CSS で実装) 背景をクリックまたは ESC キー押下でモーダルを閉じる。 (HTML の実装次第で背景クリックでも閉じないようにできる) タブキーのフォーカス移動でモーダル
GitHub - typescript-cheatsheets/react: Cheatsheets for experienced React developers getting started with TypeScript
The Basic Cheatsheet is focused on helping React devs just start using TS in React apps Focus on opinionated best practices, copy+pastable examples. Explains some basic TS types usage and setup along the way. Answers the most Frequently Asked Questions. Does not cover generic type logic in detail. Instead we prefer to teach simple troubleshooting techniques for newbies. The goal is to get effectiv
Figma プラグインを作る時の Tips
Figma のプラグインを作る時の注意点や生産性を上げる方法についてまとめてみます。 ライブラリ使ってもいいけどバンドルサイズには気をつけよう どうも Figma のプラグインは実行される度にキャッシュは保持してくれず毎回 JS を一から実行しているっぽいのでバンドルサイズが膨らみすぎないように気をつけましょう。 Figmotion みたいな一回動いたら長く使う系では問題にならないですが、何回も繰り返し実行するタイプでは問題になります。 VSCode だとこういったプラグインを入れておくと「あ、これやばそう」と気づくことができます。 Figma 内でも開発者ツールを立ち上げられる ブラウザと一緒で Command + Option + I です。 プラグインのランタイム error とか console.log とかはここに出力されるので絶対に覚えておきましょう。 Command + Op
Next.js+TypeScript+AWS Amplify+RecoilでToDoリストを作る
※投稿テストも兼ねてQiitaから記事をコピーしてみました 元記事 : https://qiita.com/Y_uuu/items/249dfcc794f101129b09 本記事ではNext.js+TypeScript+AWS Amplify+Recoilを使って、モダンなToDoリストを作る方法を紹介します。 Githubリポジトリを公開しますので、不具合や不適切な実装を見つけた場合はドシドシIssueかPull-Requestいただけると幸いです。 背景 私自身普段はRuby on Railsを使って開発しています。JavaScriptは正直まだ苦手です。 Railsは爆速でアプリを開発出来る点が魅力的ですが、一方でモバイルアプリとの連携やリッチなUIが求められる案件では、フロントエンドとバックエンドを分離した構成にせざるをえないケースがあります。 そのような構成だと、かえってRai
TypeScript で type と interface どっち使うのか問題
はじめに あくまで一個人の意見なので絶対的な解ではないというのと、どっちをデフォルトに選んでも普通にアプリケーション開発してて困ることはほぼほぼないと思うので、そこまで気を揉むことでもない、ということだけ最初に述べておいて意見をしたためます。 TL;DR アプリケーション開発では基本的に type でおk Declaration merging したい時だけ interface ライブラリ開発のような使う側で拡張したい(Declaration merging したい)時は interface とりあえずチームでどっちをデフォルトにするかは統一しといた方が気持ちいい type と interface の違い 機能的にはそんなに大きな違いはなく、個人的に判断に関わるのは次の3つかなと思います。 interface では Declaration merging がされる。type ではされない
LINE NEWS を TypeScript 化したい！/ How we did refactoring LINE NEWS codes into TypeScript
LINE NEWS を TypeScript 化したい！/ How we did refactoring LINE NEWS codes into TypeScript
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
React + TypeScriptでpropsと型を便利に扱うTips集
JavaScriptのCollection操作をする時はお願いがある、一呼吸置いてから操作をしてくれ
