先日の v-tokyo #11 の懇親会で質問されたので、Native TSX Support される Vue 3 でなぜ tsc だけで TSX が動作しないのかを聞かれたのでメモとして残しておこうと思います。 ちなみに Vue 3.0 beta が出た頃に既に検証し終えているコードは以下にあります。 https://github.com/potato4d/vue-next-tsx-only-tsc TL;DR Vue 3 にて、render function の h 関数が分離された h 関数の分離に伴い、 API が React のに近いインターフェースとなった この2点によって tsc だけで Vue TSX が動くようになったが、 近いだけで微妙に違う仕様によって実用は難しい 具体的には children のとり方が VNode[] か ...VNode かの違いがある Vue

僕は誰かに褒められたとき、謙遜しないようにしている。 褒められたら「ありがとうございます」「嬉しいです」「照れます」と、はっきり言葉で喜びを示す。 これを心がけはじめた最初のころは意識的だったけど、最近では意識しなくても自然にそう振る舞えるようになった。 これまで何人かに、「それいいですね」と言われることがあって、そういえばこの自分ルールについてちゃんと言葉にしたことがなかったなと思ってこの記事を書いている。 褒めたいと思ったあなたを否定しない 「謙遜しない」というルールの根幹は、「褒めたいと思ったあなたを否定しない」ということ。 褒めてもらったことが、自分が本当に認められたいことではないときもある。あるいは、何気なくやったことで自分ではそれほど価値を感じていないことのときもある。 それでも、相手が自分を褒めたいと思ったそのことはその人にとって疑いようのない事実である。「そう思った」という

TL;DR ES6 modules(import/export)が優秀なのでこれで良いと思う。むりに難しくする必要はない。 Vue3 からはcomposition apiを使えるけどこれもES6 modulesベースで使っていくことになる。ReactのContext的なことがしたいならinject/provideを使おう。 自分は今までいろいろな理由でvueのmixinsを避けてたけど、最近転職して強制的に目の当たりにしたため改めてmixinsの何が自分にとって辛いものなのかを書いてみようと思った。ちなみにすでに社のslackでお気持ち表明済みで、いい反応をもらったことだしなんとかしていこうとなっている（なっただけ）。 thisがmixinの中にいる mixinsはプロパティオプションをコンポーネント間で使い回す（マージする）ためにオプション丸ごと外部定義する機能だが、普通に運用していれば

heyのSTORESでECの開発をしている@nkobaです。 この記事ではフロントエンドで使用しているUIライブラリについて発信していきます！ 社内UIライブラリとは STORESのECではSTORES.jp-Front-Commonというフロントエンドライブラリを作成しています。 その一部としてUIライブラリが含まれており、これを社内プロダクトで利用することで開発効率を向上させたり、ユーザーにとっての触り心地を担保しています。 基本的にSTORESのECではブランド、デザイン、使い心地などを表現するために、ほぼ全てのUIは自作しています。 社内UIライブラリで主に使用している技術は以下になります。 Vue.js Storybook REG-SUIT Jest コンポーネントライブラリの実際 実際に使われているページ 導入期 背景 私がフロントエンドチームに加わったのは2018年の末頃でし

この記事は littledan から依頼を受けて、翻訳しています。広く Date and Times の JS プロポーザルについて意見がほしいとのことです。 意見は以下の場所にポストできます。 docs.google.com 原文: blogs.igalia.com tl;dr: Temporal のプロポーザルについてフィードバックを求めています。 Polyfill を試したら、サーベイの回答を送ってください、ただしまだ本番環境では使わないでもらいたいです。 JavaScript の Date クラスは壊れています、しかし Breaking the Web を起こさずに修正する方法はありません。風のうわさでは、 Date クラスは 10 日で作られた JS Engine のhackに含まれたもので、 java.util.Date に基づいたものと言われています。しかも java.uti

vue3が本格的に使われるようになってくるとvue2系では影が薄かったprovideとinjectも流行ってくると思います。（願望） こいつらがいい感じに型で補強してあげるとより使いやすくなるので紹介します。 provide/injectって何 そもそもこいつらが何かという話ですが、簡単に言えば親のインスタンスにkey:valueを保持しておいてどのコンポーネントからでも取り出せるようにする関数です。 以下のように、provideで登録したkeyとvalueをinjectで簡単に利用することができます。valueは登録時にリアクティブにしておけば、取り出した側での変更を追跡します。 main.ts import { createApp, ref } from 'vue' import App from './App.vue' const key = 'count' // 一意なキーを生成す

What is tooling.report? It's a quick way to determine the best build tool for your next web project, or if tooling migration is worth it, or how to adopt a tool's best practice into your existing configuration and code base. Getting StartedThis homepage shows the aggregated results from a bespoke suite of build tool tests. A build tool test is a configuration file created to specifically handle a

スクラムではチームの成果にフォーカスする。 そのためには、個人で仕事をする形から、チームで仕事をする考え方にシフトしないとけない。 いわゆる Swarming という考え方で、チームが寄ってたかって一つの開発アイテムを進めることを意味している。 逆に、チームでバラバラと仕事を進めるわけではない。 イメージしにくい人は、アメフトの試合で、ボールがフィールド上にいくつあるのか（１つに決まっている）、チームはどのボールに向かっているのか（１つに決まっている）を想像してみるといいと思う。あっちもこっちもボールが転がってたら大変だ。面白そうだけど。 なぜチームで仕事をするのか 5つの機能がスプリントのスコープに入っているとする。 5人でこれらに取り組むとする。 効率を重視したこれまでのやり方で言えば、各自が分担してそれぞれの機能の開発を進める。 この場合、それぞれが進める中で、 レビューが必要になる

#remote_vue で話しました。

ある日の超暮方(ほぼ夜)の事である。一人の下人が、クソデカい羅生門の完全な真下で雨やみを気持ち悪いほどずっと待ちまくっていた。 馬鹿みたいに広い門の真下には、この大男のほかに全然誰もいない。ただ、所々丹塗のびっくりするくらい剥げた、信じられないほど大きな円柱に、象くらいある蟋蟀が一匹とまっている。クソデカ羅生門が、大河のように広い朱雀大路にある以上は、この狂った男のほかにも、激・雨やみをする巨大市女笠や爆裂揉烏帽子が、もう二三百人はありそうなものである。それが、この珍妙男のほかには全然誰もマジで全くいない。 何故かと云うと、この二三千年、京都には、超巨大地震とか破壊的辻風とか最強大火事とか極限饑饉とか云うエグすぎる災が毎日つづいて起こった。そこでクソ広い洛中のさびれ方はマジでもう一通りとかそういうレベルではない。旧記によると、クソデカい仏像や文化財クラスの仏具をものすごいパワーで打砕いて、

ストアの型はサボった。 github.com Vue3からinjectとprovideという関数が提供されており、（機能的にはVue2のものと同じだが）コンポネ間の状態共有が簡単にできるようになった。 ドキュメント https://composition-api.vuejs.org/api.html#dependency-injection 簡単に言うと、provideにキー付きで渡したリアクティブな状態をinjectで取り出すことでどこからでも状態を参照できるようになるもの。 provideとinjectはsetupでのみ動作する。 例えば状態を共有したいコンポーネント2つがあった時、それ用のスコープでディレクトリを切って専用のストアを作ることが可能。 Symbolを使って一意のキーを生成し、リアクティブにしたい状態や関数をセットでprovideに渡す。 components/miniS

今回は以前から気になっていた、日本製Headless CMSであるmicroCMSを触ってみたのでそのことについて書きます Headles CMSとは Head (ビュー = 表示画面) less(ない) CMS(コンテンツ管理システム)で、表示画面がないCMSのことです。 今までのCMSは表示画面とコンテンツ管理が合わさったものでしたが、HeadlessCMSは表示画面が存在しないので、自分で自由に作成することができます。 また、サイトのある一部分のみコンテンツ管理することも可能です。 Contentfulなどが有名だと思います。 microCMSとは 導入でも書きましたが、microCMSは日本製のCMSです。 ドキュメントや、サポートまですべて日本語対応しているため、初めてHeadlessCMSを触ってみる場合には取り扱いやすいと思います。 また、完全に主観ですが管理画面が分かりやす

0 0 719 0 この 4 年間、Dropbox では、デスクトップ クライアントの同期エンジンを白紙の状態から再構築しようと懸命に取り組んできました。同期エンジンは、デスクトップ パソコン上の Dropbox フォルダの陰に隠れた魔法です。これは、Dropbox で最も長く使われているコード部分であり、最も重要なコード部分の 1 つでもあります。今回、新しい同期エンジン（コードネーム「Nucleus」）をすべての Dropbox ユーザー向けにリリースさせていただくことを、ここに発表いたします。 同期エンジンの書き換えは本当に大変な作業で、多くの環境でマイナスともなりうる構想であったことに鑑みると、手放しで祝う気持ちにはなれません。結果的には Dropbox にとって素晴らしいアイデアであったわけですが、それは、私たちがこのプロセスにどのように取り組むべきかを熟考したからこそ、たどり着

主語が大きすぎるタイトルですが、今の自分の考えをまとめておきたく、記事を投稿します。 もしかしたら、将来は全然真逆のことを考えているかもしれません。 また、ここでの「エンジニア」はシステムエンジニア、とりわけアプリケーションエンジニアを指します。 主語を「エンジニア」にしているのは、僕がエンジニアリングしか知らないだけなので、もしかしたら営業職や事務職でも同じことが言えるかもしれないし、言えないかもしれません。 サマリ 結論から書くと、以下の2点があるので、長時間労働しないほうが良いです。 長時間労働をすると、成果をあげるためにより時間がかかる 長時間労働をすると、将来的なコストを抱える 長く働けば成果が出るのか 汎用的な例を挙げていきましょう。 「用紙を三つ折りにして、封筒に入れてください。」 という仕事があったとします。 誰でもできる簡単なお仕事ですね。 この仕事を1時間やった場合とさ

オンライン勉強会の運営してます 昨今の事情もあり、エンジニアの勉強会もオンラインで開催されることが増え、 自分自身もいくつかのオンラインイベントの運営に携わっています。 nyamucoro.connpass.com study-in-virtual.connpass.com オフラインとオンラインではやっぱり勝手が違うので、 運絵する上でのメリット、デメリットも違ってきます。 そんなことを運営の目線で語ってみようと思います。 ちなみにcluster ってVR空間で主にイベントしています。 cluster.mu オフライン勉強会のメリット/デメリット メリット 通話アプリがあれば運営がオンラインでも普通に運営できる 以外といける discord 使ってます 会場を確保しなくていい オンラインでいいので実際の場所確保する必要がないのは運営としてはかなり楽 会社等のコネがなければこの時点で積むこ

やった github.com 本当はviteで作る超速モノレポ環境！！をやりたかったが、やっていくうちに一番大事なところが微妙になったので調査の知見を残すことにした（なった） viteとは github.com そもそもviteがなにかというと、今までバンドル作ってそれをwatchしてたけどなんらかの手段でHMRが実現できたら開発時はバンドルせんでもよくね？という発想から生まれた、バンドルを作らない開発サーバである。（alt VuePressであるVitePressがやりたかっただけ説もあるけど） 仕組みとしては、ブラウザが解釈できる形になんらかの方法でファイルを加工（tsxならtsc、sfcなら@vue/compiler-sfc）してESM形式で読み込ませることでバンドルを作らずにブラウザに即時反映している（と理解している）。 バンドルを作らないためwebpackのhmrの比ではないほど

Tailwind CSSいいなあ熱が自分の中で高まっているので、Tailwind CSSの根幹でもあるユーティリティクラスベースのcss設計について書いてみます。 (ユーティリティクラスベースじゃなくて、Tailwind CSSではユーティリティファーストっていっているけど、まあいいか) ユーティリティークラス 結構いいやつなんやなと感じてきた... cssに関してreact、vueとかのコンポーネントベースのフロント実装をしっかり始める前までは、スクラッチでフロント開発を行う際には、FLOCSSやら、SMACCSやらのCSS設計思想に基づいて、ガッチガチのCSS設計をして、CSSの崩れや破綻を根絶する！と息巻いていました。 というのも、3年とか前の話です。 その後reactを書き始めると、css_modules, styledComponents などの恩恵で、そこまでガチガチな、css