Nuxt.js + TypeScript のアプリケーションで環境変数を安全に管理する - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに イマドキの SPA 開発だとアプリケーションの設定を環境変数で取り扱うことが非常に多くあります。 開発環境・本番環境で変えたい API の baseURL、Google Analytics のトラッキング ID や Firebase の認証情報、ビルド後の成果物を上げる CDN の URL まで、ぶっちゃけ「大体の設定が環境変数で行われている」といっても過言ではない状態です。 ただ、割と環境変数は雑に使われます。いたるところから呼び出されます。いつか崩壊します。 なので、この記事では環境変数の利便性を残しながらも、可能な限り安
Next.jsにおけるSSG（静的サイト生成）とISRについて（自分の）限界まで丁寧に説明する - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この記事では、Web アプリケーションにおけるデータ取得（データフェッチング）やレンダリングに関する各手法について比較・整理することを目的として、特に最近注目度が高まっている **Next.js における SSG（静的サイト生成）や ISR（インクリメンタル静的再生成）、それ以外の手法（SSR、CSR 等）**を具体的なテーマとしてお話しします。 Twitter もやっているのでよかったらフォローおねがいします！ @_thesugar_ 記事内の解説は正確性を期すよう注意を払っておりますが、誤っている部分などがございましたらコメント欄や
GraphQLが"グラフ"であることを利用してビジネスロジックを入れ込んでみる - Qiita
動機 GraphQLを勉強しているとき、 GraphQLが"グラフ"を扱っているのはわかるけどそれによってどんないいことがあるんだろう？ バックエンドにGraphQLを選択した際、ビジネスロジックはどこに表現されるべきなんだろう? という私の疑問にサクッと答えてくれる日本語の文献が少なくともネット上には見つからなかったので、書いてみることにしました。 作るもの いわゆる"TODOリスト"を作ります。TodoistやRememberTheMiik的なあれですね。 いきなり余談ではありますが、何か新しい言語やフレームワーク、DBなどをサクッと試したいときに作るものの題材として、"TODOリスト"は個人的に以下の観点からオススメです。 仕様がイメージしやすい 大抵の方は何らかのTODOリストを使ったことありますよね？ どんなアーキテクチャでも大抵１日以内に完成する 慣れないアーキテクチャであまり
Next.js 4年目の知見：SSRはもう古い、VercelにAPIサーバを置くな - Qiita
Next.js by Vercel - The React Framework 画像は Next.js サイコー！っていう顔です。 Webフロントエンドエンジニアであれば、「Reactのフレームワーク」と聞いて真っ先に思いつくであろうNext.js。僕は小規模の趣味開発から中規模の業務まで、4年程度Next.jsを使い続けてきました。触りはじめの当時はバージョン4で、”SSR（Server-side Rendering）を提供するReact製フレームワーク”だったものが、執筆時時点の最新バージョン（10.0.1）ではガラッと異なるフレームワークへと進化しています。 この4年間は実務で利用するだけでなく、新しいものや廃止された機能、RFC止まりになった機能など、Next.jsに関する情報を追いかけており、ある程度の知見をためつつも、Next.js並びに開発元のVercelが目指す方向性を何と
top-level awaitがどのようにES Modulesに影響するのか完全に理解する - Qiita
先日、TypeScript 3.8 RCが公開されました。TypeScript 3.8はクラスのprivateフィールド（#nameみたいなやつ）を始めとして、ECMAScriptの新機能のサポートがいくつか追加されています。この記事で取り扱うtop-level awaitもその一つです。 この記事ではtop-level awaitに焦点を当てて、その意味や使い方について余すところなく解説します。top-level awaitは一見単純な機能に見えますが、実はモジュール (ES Modules) と深い関係があり、そこがtop-level awaitの特に難しい点です。そこで、この記事ではECMAScriptのモジュールについても詳しく解説します。この記事を読んでtop-level awaitを完全に理解して備えましょう。 **※ この記事は3分の1くらい読むと「まとめ」があり、残りはおま
React Testing Libraryの使い方 - Qiita
Robin Wieruch氏によるHow to use React Testing Library Tutorialを著者の許可を得て意訳しました。 誤りやより良い表現などがあればご指摘頂けると助かります。 原文： https://www.robinwieruch.de/react-testing-library Kent C. Dodds氏によるReact Testing Library (RTL)がAirbnbのEnzymeに取って代わるものとしてリリースされました。EnzymeはReact開発者にReactコンポーネント内部をテストするためのユーティリティを提供しますが、React Testing Libraryは一歩さがって、「Reactコンポーネントを完全に信頼するためにはどうテストすべきか」を問いかけます。コンポーネントの実装の詳細をテストするのではなく、React Testi
なぜ我々は頑なにforを避けるのか - Qiita
動機 前回の記事を投稿したことを某SNSで通知したところ、そのSNSでこんなコメントをいただいた。転記する許可を取ったわけでは無いので私なりに要約させていただくと、 なぜそんなトリッキーな書き方をしてまでforを使うのを避けるのか そんな書き方をして可読性を下げるくらいなら素直にforを使う方が良い ということだと理解している。 なるほど、一理ありそうだ。しかし一方で、前回貼ったStackOverflowのQ&Aはなかなかの人気記事（質問に1243ポイント、回答に最大で1559ポイント）なので「多少トリッキーなことをしてでもforを書きたくない！！」という意見をもつプログラマも一定以上いるのだろう。当然私もその1人だ。 ということで、この記事で「なぜそこまで意固地になってまでforを書きたくないのか」を説明することにする。 尚、今回は前回の記事つながりで言語はJavaScriptを使うが、
Testable Redux ~ React と Redux のテスト戦略 ~ - Qiita
本記事では Redux を使用した場合の React コンポーネントに対するテスト方法を考察します。 Redux に接続された React コンポーネントは、コンポーネント内のプロパティを Redux Store の state と同期させています。 Redux に強く依存しているコンポーネントをどのように Testable にしていけば良いのでしょうか。記事のタイトルは、t-wada 先生の言葉をお借りして、Testable Redux とつけさせていただきました。 純粋な React コンポーネントをテストする さて、まずはじめに純粋な React のコンポーネントに対するテスト方法を振り返ってみます。Facebook に習えば、jest の公式ドキュメントでも紹介されている jest と enzyme を組み合わせた方法が一般的でしょう。 以下のようなシンプルなコンポーネントを例とし
実践 Web Stories（旧 AMP Stories） - Qiita
はじめに 先日業務でWeb Stories（旧 AMP Stories）を用いたページを実装しました。 AMPが提供するコンポーネントを用いて、アニメーションやビジュアルに関するattributeを指定していくだけで、JavaScriptを一切書かずしてInstagramのストーリーに似たリッチなwebページを簡単に作ることができます。 出典: https://amp.dev/about/stories/ 本記事では、Web Storiesと合わせて使用した技術についての紹介のほか、SERP1表出を目指してGoogleのガイドラインとじっくり向き合ったお話などについても書いていこうと思います。 技術スタック 現在自分が関わっているプロジェクトのフロントエンド部分に選定されている技術について、それぞれをWeb Stories（というより、AMP自体）と組み合わせた際に注意すべき点などについて
「え!? jsの遅延ロードで document.write 動かないんですか!? 」からの解決方法 - Qiita
概要 document.writeが入った外部jsを、Reactで作られたクライアント側で遅延実行したかったけど、様々な都合からできないことを知り、色々調べた結果、解決方法を発見しました。 この記事が解決する可能性のある状況 adなどで、外部サーバーにホスティングされたJavaScriptファイル(以下、外部js) を、サイト上に<script>を使ってロードする必要がある 外部jsに document.write が使われていてるが、その仕様を変更することが難しい。 React で 実装する必要がある。 免責事項 本投稿の内容を実践し、なんらかの不利益を負った場合も、当方は責任を負いません。 結論 postscribe を使う インストールなど ↑のgithubリポジトリ参照 コード // Test.tsx import React from 'react'; export defaul
フロントエンド開発でパッケージのアップデートを継続的におこなう - Qiita
フロントエンド開発でパッケージのアップデートを継続的におこなう これは Classi Advent Calendar 2018 1 日目の記事です。 フロントエンドエンジニアの @kasaharu です。 はじめに 昨今のフロントエンド開発はフレームワークと呼ばれるものから便利なライブラリまで幅広いパッケージを使って行われている しかし、これらは導入したときのままであることが多く、バージョンアップすることを怠ると後々問題の原因になったりする バージョンを上げないとセキュリティ問題に対応できなくなったり、パッケージそのものがサポートされなくなったりする また、逆にバージョンを上げることでパフォーマンス改善などの恩恵を受けられる場合もあるが、その機会を損失していたりする 今回は、できるだけ負荷にならずに継続的なパッケージアップデートを習慣化するために Renovate というサービスを使用して
DependabotとRenovateってどっちがいいの？ - Qiita
DependabotとRenovateってどっちがいいの？ この記事は第二のドワンゴ Advent Calendar 2019の10日目の記事です。 この記事の概要 Webフロント開発をしている際に、npmライブラリのマイグレーションって結構コストかかるので自動化したいよねって動機の元、そのためのツールとしてDependabotとかRenovateとかあるけど、どっち使うのが良さそうかなという検討をしました。 ただし、あくまでもnpmライブラリの更新という側面からの記事のため、他の言語やパッケージ管理システムからの側面についての検討はされていないことをご留意ください。 また、時間に追われて書きなぐった内容になっていて後で書き直すかもしれませんがご了承いただければと思います。 結論 先に結論だけ書いてしまうと、Github EnterpriseやArtifactoryなどのprivate n
ノンフレームワークなJavaScriptでもDOMとうまく付き合う方法 - Qiita
ReactやVueなどのフロントエンドフレームワークが全盛期を迎えているJavaScriptですが、様々な制約から導入を足踏みしているプロジェクトは多々あると思います。 そして、そのようなプロジェクトではおそらくjQueryが現役で使われており、フロントエンドのコードはスパゲッティと化し、ネストされたコードは可読性を落とし、どの関数がどこで使われているのかわからない、そんな状態に陥っているのではないでしょうか。 この記事では、そんなプロジェクトを対象に、ノンフレームワークでも出来る限り可読性を向上させるための工夫をまとめてみました。 JavaScriptからHTMLをできるだけ触らない JavaScriptとDOMは密結合になりがち JavaScriptとDOM・HTMLの密結合がスパゲッティ化を招きます。逆に、JavaScriptとDOMを疎結合にしてしまえばスパゲッティ化しにくいといえ
GraphQLのFragment colocationとvariablesでモヤついている - Qiita
最近、空いた時間でチマチマとApolloを触っているのだけど、どうも腑に落ちないことがあったのでメモを残しておきます。 先に言っておきますが、特に何の結論もないです。 GraphQLのFragment colocationとは 僕が直面している課題感を説明するために、クライアントサイドGraphQLにおけるFragment colocationについて整理してみましょう。 "colocate" という単語自体、普段はそうそう耳にしないと思います（僕もGraphQLの文脈以外で使ったことがない）。「一緒に配置する」といった意味のようです。 では、何と何を一緒に配置するのでしょうか。それはGraphQLクエリとコンポーネントです（ここでのコンポーネントは、ReactやAngularにおけるViewの部品単位を指します）。 GraphQLの大きな特徴の1つに「クエリのレスポンスに含まれるデータは
TypeScriptのreadonlyプロパティを使いこなす - Qiita
TypeScriptでは、オブジェクト型のプロパティをreadonlyにできる機能があります。型でreadonlyと宣言されているプロパティを書き換えようとするとコンパイルエラーとなります。 type MyObj = { readonly foo: string; }; const obj: MyObj = { foo: "Do not change me!" }; // これは MyObjのfooプロパティがreadonlyなのでコンパイルエラー obj.foo = "hi";
Apollo Client 3で追加された機能 - Qiita
はじめに Apollo Client 3がリリースされました。AC2からの変更点としては これまで別々のパッケージから呼び出していた各モジュールが @apollo/client に集約された typePolicies や Reactive Variable など、ローカルのステート管理機能が拡充された といった感じです。実際にAC3を試してみると、今までメインで使っていた機能の使い方はほぼ変わらず、特に上記ローカルのステート管理周辺が改善された印象です。今回はtypePoliciesとReactive Variableのご紹介をします。 typePolicies ローカルのキャッシュ（Apollo ClientのInMemoryCacheと呼ばれる）において、GraphQLスキーマの各タイプをどう扱うかをtypePoliciesで定義できるようになりました。また、バージョン2まで@clie
「(HTML) + CSS」のみを使って、今「リアルな電卓」を作ってみた - Qiita
続編を書きました。CSSも大幅改善してるので、一度見てみてください。 【小数点実装】「(HTML +) CSS」のみを使って、今「もっとリアルな電卓」を作ってみた - Qiita 完成品 まずは、CodePenで完成品を紹介します。ボタンを押して計算を試してみてください。 ※ スマホだと反応が悪い場合があります。 See the Pen qiita_calc_last by j5c8k6m8 (@j5c8k6m8) on CodePen. はじめに はじめて、CSS カウンター の存在をはじめて知ったときは驚きました。 テーブルの行番号は (必要であればJavaScriptで動的に) HTMLに記載するしか方法がない と思っていたからです。 Qiitaにも、CSSカウンターのサンプルを載せた良記事があります。 CSS でテーブルに行番号を振る - Qiita CSSで見出しタグに連番をつけ
20 年代のフロントエンド - Qiita
これはなに 高円寺.dev #3 用の資料 https://koenji.connpass.com/event/160886/ フロントエンド専門じゃない人向けの、フロントエンドの最先端〜やや未来の話です このレイヤーでは Node.js を使うべき/使うと強いという部分がありますが、他言語を否定しているわけではありません。むしろ他言語でこのアーキテクチャを模倣してほしいという話です。 10 年代のフロントエンドのポストモーテム 10 年代まとめ IE が死ななかったので各種ポリフィル、メタ言語からのトランスパイルが発達。しかしモダンとレガシーの乖離が深刻に。 node と npm エコシステムの成立 仮想 DOM がフロントエンドライブラリの標準的な状態管理手法に モジュールシステム需要が ES Modules(ES2015)に結実。しかし webpack は死ねなかった。 モダンとレガ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Reactのテストライブラリを比較する - react-test-renderer, enzyme, react-testing-library - Qiita
TypeScript + Node.jsプロジェクトにESLint + Prettierを導入する手順2020 - Qiita
