Svelte • Web development for the rest of usSvelte はコンパイラを使用する UI フレームワークで、息を呑むほど簡潔にコンポーネントを記述でき、 ブラウザで最小限の動作となるようにしてくれます。開発者には既知の言語である HTML、CSS、JavaScript を使うことができます。 これは、web 開発へのラブレターです。 私たちだけでなく、常に開発者たちからも、Svelte は使用する上で最もエキサイティングなフレームワークとしてランク付けされています。
React 18 alpha版発表まとめ
先日、The Plan for React 18という記事が React チームから発表されました。これは React の次期メジャーバージョンである React 18 で予定されている変更や新機能を紹介するとともに、React 18 の alpha 版の公開を知らせるものです。この記事自体に技術的なトピックは載っておらず、それらはReact 18 Working Groupという新設されたリポジトリに Discussion としてまとめられています。 本記事では、今回あった発表のポイントを厳選してお伝えします。ポイントを絞ってお伝えするため載せる情報は取捨選択しています。隅々まで理解したいという方は原文か他の記事を参照しましょう。 アップグレードの簡単さ React 17 の際もそうでしたが、最近の React は「簡単にアップデートできる」ことをたいへん重要視しており、React 18
GitHubのトレンドで振り返る2020年のJavaScript
れこです。この記事はNode.js Advent Calendar 2020の 12 日目の記事です。今回は年の瀬ということで酒の肴になりそうな記事を書きたいと思います。 本記事では 2020 年に GitHub のトレンドに上がったリポジトリをいくつかの切り口で集計して、独断と偏見で感想を付け加えます。 この記事を酒の肴に 2020 年の JS/TS について懐かしんでもらえたら幸いです。 集計方法 GitHub のトレンドは過去の履歴が残っていないので非公式に集計されたデータを利用しています。 集計期間は 2020/01/01 から 2020/12/05 までの 341 日間 対象言語はJavaScriptとTypeScriptのみ トレンドの過去データのソースはxiaobaiha/github-trending-historyを参照 日ごとにまとめた markdown になっており、
Comparing the New Generation of Build Tools | CSS-Tricks
A bunch of new developer tools have landed in the past year and they are biting at the heels of the tools that have dominated front-end development over the last few years, including webpack, Babel, Rollup, Parcel, create-react-app. These new tools aren’t designed to perform the exact same function, and each has different things they’re trying to achieve and features to get there. Despite their di
JSXはspread演算子で<Foo a={a} b={b}>を<Foo {...{a, b}}>で書ける
JSXはspread演算子で<Foo a={a} b={b}>を<Foo {...{a, b}}>で書ける
Index as a key is an anti-pattern
So many times I have seen developers use the index of an item as its key when they render a list. { todos.map((todo, index) => <Todo {...todo} key={index} />); } It looks elegant and it does get rid of the warning (which was the ‘real’ issue, right?). What is the danger here? It may break your application and display wrong data! Let me explain, a key is the only thing React uses to identify DOM el
2020年代、使う技術はどう選ぶ？
Front-End Study #5 の発表資料です。 https://forkwell.connpass.com/event/205227/ フィードバックはこちら： https://koibu.me/events/14/talks/wQQs0pbvMZHcnZ8TawAi
Reactのprops/contextの使い分け - saneyuki_s log
Reactのprops/contextの使い分け 仕事先でたまたまこれの話になり、個人的に思っていることをまとめた。 公開したのは、時々見かける「どっちを使うべき？」みたいな議論に 自分も混ざりたかった 思うところがあったから. 「とにかくpropsでいい」と自分は考えている。 なによりReactは書き方に詰まった場合に、フレームワークライブラリ固有の事情を考慮して解決するというよりも、実装や設計上の問題が一般的なプログラミングパターンの範疇の発想で解決できるのがよい 前提 以下のように考える React/preact のコンポーネント = 通常のclassや関数 状態を隠蔽して抽象する 最近は冪等性がどうとかReact語るときにあんまりいわなくなったけども.... props = 関数やメソッドの引数（入力） context = グローバル変数（モジュールグローバルな変数） 実装の指針
props のバケツリレーって何が悪いんだっけ - fsubal
#React やってて、props のバケツリレーを何か嫌がる人たまにいるんだけど、自分は props のバケツリレーそのものをそんなに悪いと思ったことがない。 「バケツリレーがつらい」ように見えるコンポーネントの大半はそもそも props の設計がおかしい場合が多く、本当の問題はそっちにあると思っている。 たとえば、次のようなバケツリレーはつらいかもしれない。ここでいう Body はサイドバーとしてフォロワーの一覧を表示し、メインコンテンツとしてフィード一覧を表示するみたいなものを想像して欲しい。フォロワー一覧の中で使う props とフィード一覧で使う props を混ぜて1つの親に渡している状況だ。 code:typescript <Body logo="/logo.svg" followers={followers} // 実はサイドバーの中でだけ使う feeds={feeds}
State of JavaScript 2020：いちばん利用率の高いJSフレームワーク、フロントエンドがReact、バックエンドはExpress、テストにはJest。2万4000人の調査結果
IT技術者のSacha Greif氏とRaphaël Benitte氏が、JavaScriptに興味を持つ世界中のIT技術者約2万4000人にアンケートを取り、結果をまとめたWebサイト「State of JavaScript 2020」が公開されています。 JavaScriptの最新のシンタックスや命令がどれくらい使われているか、フロントエンドやバックエンド、ビルドツールなど分野ごとにさまざまなJavaScript関連の技術はどれくらい興味を持たれているかなど、アンケート結果を基にして、満足度（Satisfaction）、興味（Interest）、利用率（Usage）、認知度（Awareness）などを計算。それぞれについてランキングを作成しています。 それぞれの値は次の式で計算されると説明されています。それぞれの項目にはアンケートの回答数が入ります。 満足度＝またこの技術を使いたい／（
Concurrent Mode時代のReact設計論 (1) Concurrent Modeにおける非同期処理 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Concurrent Modeは、現在（2020年3月）実験的機能として公開されているReactの新しいバージョンです。Reactの次のメジャーバージョン（17.x）で正式リリースされるのではないかと思っていますが、確証はありません。なお、React公式からもすでに結構詳細なドキュメントが出ています。 並列モードの導入（実験的機能） Concurrent Modeに適応したアプリケーションを作るためには、従来とは異なる新しい設計が必要となります。筆者はConcurrent Modeを使ったアプリケーションをひとつ試作してみました。この記
今からでも遅くない！誰も教えてくれなかった React とアクセシビリティーの世界
この記事は Front-End Study #3 で発表されたライブコーディングの内容を記事にしたものです。記事中のソースコードは GitHub でご覧いただけます。 この記事は、これまで一般的なフロントエンドエンジニアだった私が一年ほどアクセシビリティーについて勉強する上で 「最初に教えてくれればよかったのに〜！」と思った内容 を React と Next.js を用いて紹介するものとなっています。 読み終わった後に次にコードを書く際にふと意識できるようなアクセシビリティーの普遍的な事実を紹介し、最後に今後の React の動きについて軽く触れるものになっています。目次は次のとおりです： 基本事項 SPA のルーティングによる問題 リッチなコンポーネントでの例 Jest + React Testing Library でのテスト Reactとアクセシビリティーの今後の動き 役に立つweb
Recoil について勉強した
Fecebook が新しく発表した Recoil について 自分の学習手順 Getting Started | Recoil を写経して動かす Facebook 製の新しいステート管理ライブラリ「Recoil」を最速で理解する - uhyo/blog で非同期周りを理解 公式ドキュメントの API Reference で理解 <RecoilRoot ...props /> | Recoil これは自分が写経しながら書いた型定義。色々足りてないがチュートリアルで出る範囲は理解できる。 declare module "recoil" { export type RecoilState<T> = {}; export const RecoilRoot: React.ComponentType<{ initializeState?: (options: { set: <T>(recoilVal:
Hugo で React + TypeScript を利用してサクッとウェブサイトに RSS リーダーを追加する
はじめに Hugo のウェブサイトに組み込む RSS リーダーを TypeScript で開発してみたいと思い調査したところ、Hugo の最新版には ESBuild が組み込まれていて、非常に手厚く JavaScript の開発環境がサポートされていることが分かりました。 本記事では紹介していませんが Babel も利用できるようです。 また、NPM パッケージも利用できるため、普段のウェブ開発と同様の流れで開発ができ、各種ライブラリを用いた開発も非常に楽でした。 今回は Hugo で JavaScript 開発する方法を RSS リーダーの開発を例に上げ、そこで得た知見についても交える形で記事として残しておくことにしました。 ちなみに本記事内容は Hugo で JavaScript 開発する方法に焦点を絞ったものなのですが、ウェブサイトに RSS リーダーを組み込むことに焦点を絞って見た
設定0行でNext.jsとNuxt.jsの内部リンクを型安全に取得できる最強ライブラリ「pathpida」
Qiita TypeScript Advent Calendar 2020 最終日の記事です。 TypeScript製の内部リンク取得ライブラリ「pathpida」 最近ちょっと話題になった frourio と aspida を開発したSolufaです。 Zenn初投稿を記念して、新作ライブラリ「pathpida」を紹介します。 と言っても完全な新作ではなく、初回リリースからもうすぐ1年が経ち月間DL数は1,000を超えています。自分が関わる案件だけで静かに検証を続け、ようやっと今週全面リニューアルして一般告知が出来るようになりました！ pathpidaはNext.jsとNuxt.jsそれぞれのルーティング規約に最適化しているので設定不要で型安全に使うことが出来ます。 どんな問題を解決するのか 以下のように/post/1 に遷移するLinkがあるとします。 import Link from
blitz-js prisma rails 倒し方
この記事の内容 blitz-js が生まれた背景 prisma の紹介 blitz で簡単なブログを作ってみる blitz を vercel にデプロイしてみる tldr blitz-js は next.js + prisma で rails を再現しようとしているフレームワーク Prisma ORM それ自体が良い。blitz の理解のためにも、まず Prisma を学べ blitz-js 自体はまだ α 品質だけど、今から注目しておく価値はある。デファクトになるかは不明。思想は継承されそう。 はじめに next.js はとても良いフレームワークだが、永続層を持たない。なのでフロントエンドとフロントサーバーに閉じている。 永続層、つまり DB を持たないので、初学者や流行りのプログラミングスクールの教材に選ばれない。また、JavaScript の学習資料が散らばっている。 要は Rail
styled-components（CSS in JS）をやめた理由と、不完全なCSS Modulesを愛する方法 - Qiita
styled-components 画像は styled-components ツライっていう顔です。 Angularのようにスタイリングまで面倒を見てくれるUIフレームワークならまだしも、Reactの場合はコンポーネントのスタイリング方法も自身で選択しなければいけません。CSSのスタイリング方法/設計はいくつか存在しますが、どれも一長一短で、やはり銀の弾丸は存在しません。スタイリング方法を選択可能なUIフレームワークは、この混沌とした選択肢の中から価値を見出す必要があるわけです。 僕はBEMによる人力CSS管理（Sass/Less/Stylus）から、 { fontSize: 14 } のようなJSオブジェクト形式のCSS in JS、 styled-components のようなTemplate Stringsを利用したCSS in JS、そしてCSS Modulesまで幅広く公私とも
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が目指す方向性を何と
Reactコンポーネントの定義にFCではなくVFCを使う - いけだや技術ノート
[RFC] React 18 and types-only breaking changes · Issue #46691 · DefinitelyTyped/DefinitelyTyped [@types/react] add VoidFunctionComponent type which does not accept "children" by awmottaz · Pull Request #46643 · DefinitelyTyped/DefinitelyTyped https://react-typescript-cheatsheet.netlify.app/docs/basic/getting-started/function_components/ 簡単に言うと React.FCのpropsの型定義には暗黙的にchildrenが含まれてしまう childrenが必要ない
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
useHooks
