TypeScriptのunion型はorです 〜union型、構造的部分型、余剰プロパティチェックの話〜 - Qiita
TypeScriptのunion型はorです 〜union型、構造的部分型、余剰プロパティチェックの話〜TypeScript 先日、「TypeScriptのunion型はorではない」とする以下の記事が公開されました。 TypeScript の共用体型（Union Types）は or ではない 残念ながら筆者はこの主張に同意できないので、この記事では上記の記事に含まれる問題点を指摘しつつ、正しい結論を導きます。 この記事の目的はあくまで正しい情報を皆さまに届けることであり、上記の記事（以下では「元記事」と呼びます）の筆者を攻撃する意図は無いことをご理解ください。 では、元記事からコードを引用しながら何がまずいのかを見ていきましょう。 元記事の主張 元記事の最初のコードを引用します。
Storyshotsが最高すぎる件 - Qiita
こんにちは、@takanoripです。 今回は最近導入したStoryshotsというやつを紹介していきたいと思います。 Storyshots StoryshotsはStorybookのアドオンで、Storybookに登録されているコンポーネントのスナップショットテストをしてくれます。できることはjestのスナップショットテストとほぼ同じです。 Storyshotsを使うと、コンポーネントごとにテストファイルを用意しなくて良いので手軽にスナップショットテストを導入することができます。 すでにStorybookを導入していれば、下記ファイルを追加するだけでOKです。 簡単でしょ？ また、Storyshotsを使うと、スナップショットテストができること以上に良い効果をProjectにもたらすことができます。その効果について説明していきます。 Storybook Storybookは皆さんご存知だ
雰囲気で使わない React hooks の useCallback/useMemo - Qiita
React hooks にはメモ化のための useCallback と useMemo という関数があります。 hooks を使い始めて、この二つの関数を知った私はこう思いました。 「え？無条件でパフォーマンス上がるんなら全部これで書くべきやん！」 と。 というわけで、しばらくそのスタンスで書いてきたのですが、果たしてこの「無条件でパフォーマンスが上がる」という前提は本当に正しいのか、というかそもそも"パフォーマンス上がる"とは具体的に何をしてくれるのかを理解せずに使っていたので、ここで「全て useCallback/useMemo で書く」という方針が正しいのか、それとも他の方針が存在するかを考えてみました。 大きく次の3つの観点で考えます。 パフォーマンス 可読性 バグの発生しやすさ 1.パフォーマンス 「そもそも useCallback/useMemo はパフォーマンス向上の用途なの
reactでuseStateとuseCallbackを使う - Qiita
背景 reactでこんなことを実現したいとします。 まあよくある、ボタンを押すと数字がインクリメントされるやつです。 日本ではvueが盛り上がっていますが、reactも盛り上がって欲しいところ...！ あまり日本語の文献がないので書いていきます。 react16.8より追加されたHookを使って作っていきましょう。 typescriptで書いていきます。 だめな例1 // Sample.tsx import React, { useState } from "react"; const Sample = () => { const [count, setCount] = useState(0); return ( <div> <button onClick={() => { setCount(count + 1); }} > click here! </button> <p>count:
経年劣化に耐える ReactComponent の書き方 - Qiita
「経年劣化に耐えるコード」というのは、だれもが目指すものでしょう。「そもそもフロントエンドのコードは、今ある技術で最良のものを書き捨てるべき」という意見も理解できますが「備えあれば憂いなし」ということもありますので、ここにメモを残します。あくまで、私なりのベストプラクティスですのでご了承ください。 5層に別れた SFC 私はレイヤーによる技術の分離で、ReactComponent の経年劣化に備えています。ここでいうSFCとは「Stateless Functional Component」の略称ではありません。Vue.js の文脈にある「Single File Component」を指します。 // (1) import層 import React from 'react' import styled from 'styled-components' // (2) Types層 type
SSRはおまいらには早すぎた 〜Next.jsのgetServerSidePropsの登場が何を意味するか〜 - Qiita
概要 Next.js 9.3から getServerSideProps という仕組みが導入されました。 上記がそのドキュメントですが、これを読んで感動した私はつい語りたくなってしまいました、私情が多分に含まれております、ああそういう視点もあるんだくらいに見ていただければと思います。 僕自身は、SEOをあまり気にしないいわゆるSPAっぽいWebページのNext.jsでの開発を1年ちょいくらい業務でやっていて、今もNext.jsユーザーです。 「getServerSidePropsって何が良いの？なんで生まれたの？」 「なんでgetInitialPropsは非推奨なの？」 「Vercel製のSWRってライブラリあるけど、あれ何？」 「てかgetServerSidePropsとSWRって関係あるの？」 この辺の疑問をお持ちのNext.jsユーザーの方は是非ご一読ください。 ※過剰な煽りタイトルで
graphql-codegen で型定義を生成する (React, Apollo, TypeScript) - Qiita
graphql-codegen で型定義を生成する (React, Apollo, TypeScript)TypeScriptReactGraphQLapollo 本記事はこのリポジトリでやったことのまとめです。 GraphQL + TypeScript への課題感 TypeScript(に限らず他の静的型付の言語) と GraphQL を使うと、型の二重定義が発生がちです。折角 GraphQL に通信規約としての型を書いているのに、それを多重定義することで、運用の面倒臭さやバグの温床になりかねない、という懸念がありました。 今回は、graphql のスキーマとクエリを書くと、サーバー向けに resolver の型定義、クライアント向けにクエリの型定義を生成し、それによってできるかぎり型安全なコードを扱うのをゴールとします。 やり方 graphql-code-generator を使います
モバイルブラウザのビデオ再生がいろいろ変わるので確かめてみた - Qiita
以前、モバイルブラウザのビデオ再生でアプリキャッシュが使えるかを再度検証という記事を書きまして、その頃は、モバイルブラウザではビデオの自動再生ができなかったり、キャッシュが効かなかったりと、なかなか大変でした。 ここ最近になって、この辺りのユーザ体験(UX)を改善しようと、Chrome for AndroidやSafari for iOSでいろいろ変更が試みられていますので、いくつか確かめてみました。 なお、Chrome for Androidの更新内容は、Google Developersの記事「Service worker caching, playbackRate and blob URLs for audio and video on Chrome for Android」で紹介されていますので、詳細は当該記事をご覧下さい。(本記事も当該記事を参考にしています。) 自動再生の仕様変
Reactのレンダリングに関する完全ガイド - Qiita
この記事はComplete Guide to React Rendering Behaviorの翻訳記事になっています。 ご本人(Markさん)にも許可を頂いて翻訳しております。 こちらの記事がReactのレンダリングを理解する上で今までで一番体系的で一番分かりやすかったので、ぜひ紹介したく翻訳させて頂きました。 翻訳ツールにもたくさん助けてもらいながら行い、意訳が出来ていない部分が多々あるかと思いますので修正依頼を出して頂けると幸いです！ Twitterでも、フロントエンドに関する事や、アメリカでのエンジニア経験に関してツイートしているので、よかったらフォローお願いします。 Twitter: @hellokenta_ja 下記から本文です。 Complete Guide to React Rendering Behavior この記事は、Reactレンダリングがどのように振る舞うか、Co
zeit製のswrがすごい - Qiita
react hooksの登場とある程度の枯れ具合を見せてきて、益々利用する機会が増えているReact。 最近はreduxを採用する/しないで議論が白熱することが多くなってきていますが、今回はreduxを採用せずとも、ある程度のアプリケーションなら作れる選択肢の一つを紹介させていただきます。 初投稿なので、読みづらかったらスンマセン。 zeit製のライブラリ swr 今回の主役はこのswr。 reactのSSRフレームワークであるnextjsやPaaSのNowなどのを開発・運用しているzeitから最近登場したライブラリです。 このライブラリのREADMEの頭には、以下のように紹介されています。 SWR is a React Hooks library for remote data fetching. そう、つまり、data fetchをhooksベースで記述するためのライブラリです。 どん
next.js + react-apollo-hooks で SSR する - Qiita
公式の examples にないものを実装したのでメモ。 render-props ベースの https://github.com/zeit/next.js/tree/canary/examples/with-apollo では react-apollo-hooks と作りが違うので https://github.com/trojanowski/react-apollo-hooks の SSR の例を見ながら実装した。 lib/initApolloClient.js は一緒 import { ApolloClient, InMemoryCache, HttpLink, NormalizedCacheObject } from "apollo-boost"; import fetch from "isomorphic-unfetch"; let apolloClient: ApolloCli
TypeScript 4.0で導入されるVariadic Tuple Typesをさっそく使いこなす - Qiita
今日、Anders HejlsbergさんによってTypeScript 4.0に導入予定の新機能のプルリクエストが出されました。この記事では、この新機能Variadic Tuple Typesを解説します。 ちなみに、現在（この記事の執筆時）のTypeScriptのバージョンは3.9であり、4.0はその次のバージョンです。一見メジャーバージョンアップに見えますが、TypeScriptはsemantic versioningを採用していないため、3.9 → 4.0は特別なリリースというわけではなく、3.8 → 3.9とかと規模は同程度です。 Variadic Tuple Typesの基本 さて、Variadic Tuple Typesは、一言でいえばタプル型の中に...Tと書ける機能です。この構文はよく知られたスプレッド構文のいわば型バージョンであり、あるタプル型の要素たちを別のタプル型に埋
Electron アプリケーションの公証に成功する方法 - Qiita
（この記事は Kilian Valkhof 氏による "Notarizing your Electron application" をご本人の了承を得て日本語訳したものです。） macOS 10.14.5 のリリース以降、 ”新規の” 開発者によるすべての署名済みアプリケーションは公証を受けなければ Apple のゲートキーパーに引っ掛かり、ユーザーがインストールできないようになっています。 私は、Polypane というアプリケーション（未公証でした）をローンチした２日後に macOS 10.14.5 が登場し、アプリをインストールできない多くのユーザからの苦情に迎えられる結果となりました。 残念なことに、これについては多くの情報が転がっているわけではありません。私が初めてこの問題に遭遇したとき、Google ではそのエラーメッセージすら見つけることができなかったのです！ 未公証のアプリ
macOS向けにElectronアプリケーションの署名(code signing)・公証(notarization)をする - Qiita
macOS向けにElectronアプリケーションの署名(code signing)・公証(notarization)をするmacOSElectronelectron-buildercodesigningnotarization ElectronアプリケーションのmacOS版を配布するためには、次の２つの方法があります。 1) Mac App Store 2) インターネット上で直接配布（例えば、GitHub releaseにファイルをアップロードする) 2)の方法で配布する場合、署名(code signing)および公証(notarization)が必要になります。この記事では、実際にElectronアプリケーションをリリースした経験をもとに、必要な設定について解説します。 前提 私が開発したElectronアプリケーション(Photo Location Map)では、次の状態・条件から、
Mac OS で Electron の autoUpdate をするために証明書をとってリリースする方法 - Qiita
まずは、証明書について コードサイニング証明書って？ オンラインで配布するソフトウェアにデジタル署名を行う電子署名用の証明書 👆コードサイニング証明書で署名されていないソフトウェアは改ざんを受けている可能性があるため、インストール時に警告が表示される デジタル署名を行うメリット ソフトウェアの開発元・配布元を明確に証明 なりすまし、内容の改ざんされていないことを保証 正規の配布元であることを証明することにより、ソフトウェアのインストール率増加 デジタル署名がされていないソフトウェアのリスク 配布元のなりすまし プログラムが改ざんされている マルウェア（ウイルス）が仕込まれている 署名と検証の仕組み 署名（開発側の処理） コードサイニング証明書取得 オリジナルコード（＝ソフトウェアのプログラムデータ）から、ハッシュ値を生成 コードサイニング証明書の秘密鍵でハッシュ値を暗号化 👈これがデジ
大幅にリニューアルされた Next.js のチュートリアルをどこよりも早く全編和訳しました - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 数日前（4/21頃）に Next.js のチュートリアルが一新されました。 Next.js は 3 月頭に ver 9.3 がリリースされ、ビルド時に静的に HTML を生成する関数などが追加されるなど、今までよりもかなりパワフルになり、いわゆる JAMstack と呼ばれるようなアプリケーションを作りやすくなりました。 そのバージョンアップに対応するかたちで、チュートリアルも大幅に書き直されました。 参考（開発チームの @chibicode さんのツイッター） Next.jsの公式チュートリアルを最新版に沿ってゼロから書き直しました!
Electron + Travis で楽々ビルド・リリースする最強のデスクトップアプリ開発 - Qiita
この記事は古いです。 ぼくが考えた最強のデスクトップアプリ開発環境 Web技術でデスクトップアプリ書いて push するだけの環境を作る。 主に利用するのは Electron + Travis + GitHub の3つ。 Electron でデスクトップアプリ書いて、push するだけでビルドしてリリースまで完結するデスクトップアプリ開発ができる。 もっと簡単に言うと 「ローカルで開発→push」 だけで GitHub Release に自動でリリースできる。 アプリのビルド自体もTravis内で行えるため、開発環境のOSに依存しない開発が可能。 以下は OS X 環境を前提として説明するが、クロスプラットフォームのためのビルドはTravis内で行うため OS は何でも良い。 念のため各種サービス・フレームワークの説明 簡単に説明すると以下。どれもすごく便利。 Electron: みんな大
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Storybookの最新フォーマット・Component Story Format(CSF)を速攻で試す - Qiita
MindBEMding と近代 Component 設計の共通点 - Qiita
46436d30d967f9f5030b
