<Animate play={false} start={{ opacity: 1, filter: 'blur(0)' }} end={{ opacity: 0, filter: 'blur(10px)' }} > <Component /> </Animate>
esm: Implement esm mode flag by guybedford · Pull Request #18392 · nodejs/node This provides a mode: "esm" flag for package.json files which will treat ".js" files as ES modules w... まだ、master へ入っていないので、未確定です。 今は、Core で開発するか http2 の様な感じで upstream で開発するや semver の扱い等の開発指針を決めたところです。 現在の Node.js の ECMAScript Modules に対する問題点 ESM を使用する場合、現在はファイルの拡張子を.mjsにする必要があるが可能であれば、ユーザーは.jsファイルで書きたい。 Node.js Package
「30分でわかる」のは、だいたい、 4. モナド(Monad)とは何か? の読了までを想定しています。 また速い人なら、30分で全部一気に読み通せる分量でもあると思います。 30分以上かかっても一気読みしてしまうことが推奨されますし、一気読みできるように、前に戻って知識の再確認をしなくて済むように、最大限留意して構成を設計した上で執筆されています。 数学と用語問題。モナドの理論的基盤として圏論があるのは事実。理論的基盤がしっかりしているのはプログラミングという数学的作業において歓迎すべきことではある一方で、他方そのため一般的なプログラマにとってはまず用語に馴染みがない。歴史的に、圏論ベースのモナドを理論から関数型プログラミングに応用されていく過程では、実際、先駆者の間でさえ紆余曲折があったのだが、学習者へは馴染みのない用語を伴って、いきなり高度な数学的概念全開で天下り的に提示されてしまうこ
はじめに 気になってはいたけど、特に触ることなく過ごしていた React Hooks なのですが、最近少しずつですが仕事でも趣味でも導入を始めました。 最近 Lazy Image 的な実装をすることがあったので、React Hooks で置き換えてみようと思い、練習がてら IntersectionObserver を簡単に扱うための Custom Hook を作ってみました。 作ったもの use-intersection というライブラリを作成しました。以下リポジトリです。 use-intersection https://github.com/cats-oss/use-intersection npm にパッケージとして公開しているため、
Transcript ݱ͔Βಧ͚Δ3FBDUϓϩδΣΫτͷ Έͱվળ� 6*5���ਐԽ͢Δ�3FBDU�KT wTBLJUP !@@TBLJUP@@ � w'SPOU�&OE�&OHJOFFS� w3FBDU XFCQBDL (BUTCZ+4� w&WFOU� w#POpSF�'SPOUFOE� w'SPOUFOE�5SBJOJOH�.FFUVQ� w3FBDU�NFFUVQ� w*OTJEF�'SPOUFOE� ࠂ None *OTJEF�'SPOUFOE��� �����݄��։࠵ʂ✨ IUUQT���JOTJEF�GSPOUFOE�DPN� $'1ืूͷకΊΓ ໌ �݄����࣌�� ·Ͱʂ ·ͩؒʹ߹͏ʂʂʂ ࠂऴྃ ݱҰͭҰͭʹ3FBDUʹؔ͢Δ͕͋Δͱ͓ͬͯΔ ࠙ձͰͦΜͳͰΓ্͕Γ͍ͨ ͷ3FBDUϓϩδΣΫτͷݱͰվળ
performance.markというパフォーマンス計測に役立つAPIがあります。 performance.mark APIを使うと、指定して処理をマーキングでき、その結果を開発者ツールでみれます。とても便利なのですが、そのマーキングとメタデータを紐付ける仕組みがありませんでした。 performance.markでパフォーマンス計測する | Web Scratch Almin + React/Vue.jsのパフォーマンスプロファイルをタイムライン表示できるように | Web Scratch TPAC 2017のUser Timing L3 - Google スライドでは、performance.mark APIでメタデータ(details)を紐付けできる仕組みが提案されています。 これを使うと「Aという処理でデータを取得」をperformance.markでマーキングする際に、実際に取得
ECMAScriptの浮動小数点数の丸め関数である Number.prototype.toFixed() について調べてみたところ、浮動小数点数をわかっている人が作った硬派な仕様だと感じたので、解説してみます。 浮動小数点数の丸めの善し悪しについて 私はプログラミング言語の浮動小数点数の丸め処理に興味があり、過去に関連記事を30本以上書いています。こうした活動から得られた知見として、良い丸め関数には次のような性質があると考えています。 仕様がシンプルで直感的であること 仕様が抜け漏れなく文書化されていること バグを作り込みにくい仕様であること どれも良い関数の一般論のような話ですが、丸め処理に限って言えば簡単な話ではありません。そもそも浮動小数点数の性質が人の直感に反するため利用者にとっても実装者にとっても罠が多く、結果として上の条件を満たせないことが多いのです(私が面白いと感じるポイント
import React, { Dispatch, useContext, useReducer, useState, useCallback } from "react"; import { Route, Switch, Link } from "react-router-dom"; import styled, { createGlobalStyle } from "styled-components"; import { Action, reducer, RootState } from "./reducer"; import * as actions from "./reducer"; // RootState context export const RootContext = React.createContext<RootState>(null as any); export
Scalable Full Stack Without the Cortisol Over 3 million apps have launched on Fly.io, boosted by global Anycast load-balancing, zero-configuration private networking, hardware isolation, and instant WireGuard VPN connections. Push-button deployments that scale to thousands of instances. Speedrun Your App Public Cloud Infrastructure. Modern Platform Endorphins. The most flexible and powerful comput
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く