Utopia is a production-grade online coding and design tool for React that reads and writes code you’ll want to commit.
The Plan for React 18 のブログで React v18 の計画が発表され、アルファもリリースされました。当初の計画からは色々と変わりましたが、順調に進めば今年中に v18 がリリースされそうです。 このアルファリリースは、React 関連のライブラリ作者に試してもらってフィードバックもらうことを目的にしているため、現時点でプロダクトのコードに導入することは推奨していません。 アルファリリースなのでまだまだ破壊的な API も予想されます。 reactwg/react-18 フィードバックをもらう場所として、reactwg/react-18 という GitHub Discussions のためのリポジトリが作成されています。この Discussions は誰でも見ることはできますが書き込めるのは Collaborators になっている人のみです。そのため比較的議論の内容
Flexboxのチートシートの一部 displayプロパティ Flexboxを使用するには親要素にdisplay: flex;(または、display: inline-flex;)を適用すると、その子要素がFlexアイテムになります。 flex-directionプロパティ FlexアイテムがFlexコンテナでどのように配置されるか明示します。方向は2種類で、横列(row)の水平、縦列(column)の垂直に配置できます。 flex-wrapプロパティ Flexコンテナが複数のFlexアイテムを一行(no-wrap)、または複数行(wrap)に配置することをコントロールします。 Flexboxの各プロパティの詳しい説明は、下記の記事をご覧ください。 CSS Flexboxの基礎知識と使い方をやさしく解説
フロントエンド連載2日目のエントリーです。 あまり話題になっていないような気がしますが、Web Componentsを実装するためのフレームワークのLit-Element v3がバージョンアップして、ついでにリブランディングしてLit v2.0となりました。ロゴも変わり、ウェブサイトも新しくなりました。 Introducing “Lit” for Web Components 本当はこのLitの紹介をこの連載でしようとしたのですが、上記のウェブサイトがすごく詳しいので、単に紹介するだけの記事だとあまり価値がないので、この中のコントローラ機能のみをとりあげようと思いますが、まずはWeb Componentsとは、というところを説明します。 n回目のWeb Components元年以前次のような記事を書きました。最初のPolymerというフレームワークが推進していたころよりも、ブラウザ対応も進
※前編がこちらにあります 目次 icon links inputs keyboard navigation navigation menu modals prefers-reduced-* “skip” links SVGs tabs tables toggle switches tools tooltips video/audio players アクセシブルなインプット 2019年、WebAIMは上位100万件のWebサイトのアクセシビリティを分析し、エラーがないページの推定割合は1%未満というショッキングな結論に到達しました。アシスティブテクノロジー(支援技術)に頼っている人にとってインクルーシブで使いやすいサイトを作成するには、セマンティックHTMLの基礎を正しく理解する必要があります。Oscar Braunertのインクルーシブなインプットに関する記事は、彼の「小さく始めて共有・
Core Changes fix(types): allow nonpromise return types for static functions: #24685 Ensure history navigates correctly with dynamic routes + basePath: #25459 Fix external check for non-local next import: #25518 Ensure providing only query on dynamic route works as expected: #25469 Assume a recent react@experimental if reactRoot is set: #25496 Update to latest webpack 5 and webpack-sources: #25558
2016年ジャストシステムへ新卒入社。新規サービスの立ち上げでマイクロサービスの設計や開発・運用に従事し、2019年7月にメルペイ参画。Credit DesignチームのBackendエンジニアとしてメルペイスマート払いに関連するマイクロサービス化や新機能開発に従事している。 技術的負債と戦う メルペイスマート払いは、2019年4月に提供を開始したサービスです。なので、記事執筆現在では、まだ2年と少ししか経っていません。「2年で大きな技術的負債?」と感じる方もいらっしゃるかもしれないので、まずはリリース当初の話を少ししたいと思います。 当初、メルペイスマート払いのサービス提供に向けた開発は、メルペイのマイクロサービスアーキテクチャに則り、独立した開発を想定していました。しかし、開発工数とお客さまに提供開始したい時期には大きなギャップがありました。 そこで、「メルカリ月イチ払い」というメルペ
こむろ@事業開発部です。 前回 の続きです。 そろそろ諸々の記憶が薄れ始めている頃なので早めに全部書ききっておきたいところです。 前回までのまとめ データの取得と転送方法についての検討は終わりました。 Amazon S3 の転送方法の検討と想定される時間の計測 → 完了 Amazon ElastiCache for Redis の転送方法の検討と想定される時間の計測 → 完了 Amazon DynamoDB の転送方法の検討と想定される時間の計測 → 完了 転送対象の絞り込み → 完了 重要データ、ログイン情報の3テーブルにフォーカスを絞る 認証情報は除外 データ完全性検証の方法検討 → 未着手 全体のスケジュール作成 → 未完成 転送作業の実施 → 未着手 今回のテーマ データ完全性検証の方法を検討します。 データ完全性検証について。ここでは、「移行元のデータ」と「移行先のデータ」が完全
クリーンアーキテクチャで web アプリケーションを作る際に、バリデーションはどのレイヤの責務なのか?と悩むことが多いため、それについての考察を行ってみる。 あと、バリデーションについて書いてたはずがドメインロジックとアプリケーションロジックの違いについても結構言及せざるを得ない感じになったので、そのへんの話もしてみる。 結論から言うと バリデーションはどのレイヤの責務なのか?という問い自体が間違いであり、レイヤごとにそのレイヤの責務となるバリデーションを行うべき、というのが今のところの結論。 バリデーションという単語は意味があまりに広い。「意図していないもの/ことを防ぐ」ことはすべてバリデーションと呼ばれている節がある。そのことにより、バリデーションというのはあたかも唯一つの責務であるかのように錯覚しがちだが、そうではない。クリーンアーキテクチャではレイヤによって責務を分担しているが、同
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く