久々に心踊るカラースキームに出会った(bluewery)
また書くかも!とかいいつつ、書いて今年終える!!!
エディタのカラースキームはやる気とかに直結すると思っている派です。
あと、カラースキームを変えると気分も変わる気がします。
そんなこんなで、久々に心踊るカラースキームに出会ったので書いておきます。
bluewery.vim
早速入れて適用してみました。
スクショの時間12/20だね。随分前だ・・・。
この緑感たまりません。
何回かカラースキーム変えようと試みてはいましたが、結局icebergかhybridに戻す始末。
なんで気に入ったのか・・・。
READMEに理由がありました。
This colorscheme is inspired by
iceberg gotham solarized
そらそう。inspired byにicebergが。
個人的にはsolarizedは好きになれなかったのですが、これならいけそうです。
2019年まとめ
年末なのでまとめ記事。
2019年やったこと。
やったこと
ギョーム
業務はほぼ後半はjQuery書いてた気します。
前半はVueやらAngular書いてた気もします・・・。
個人的なやつ
- しょーもないことでも、ちょいちょいブログ書いた
- 夏頃に少しだけGoに入門した
- 秋頃にVimに戻った
カンファレンス系
カンファレンス参加はng-japanのみでした。
Vue Fesは参加予定でしたが台風で流れて、色々と金銭面の関係でVimConfも不参加でした。
来年
Goは正直チュートリアルやった程度なので、もう少し書けるようになりたいところ。
ブログも今年ぐらいの感じで書けたら良いなと思います。
その他
大きかったのは、VSCodeからVimに戻ってきたこと。
coc.nvimを知って入れてみたら、アレ、これVimでいけるんちゃう・・・?となったのがキッカケです。
VSCodeのVim拡張を入れて使ってましたが、行数が増えるとパフォーマンスの悪さが目立ってしまって、さすがにしんどくなりました。
今までMacVim-kaoriyaでやってたのも、いろんな人を見ていると大体ターミナルでVim使ってる気するので、
その辺りもAlacritty + tmuxでVim使う感じに変えました。
で、年末。
久々に心踊るカラースキームと出会って終了みたいな感じです。
bluewery
今はこのカラースキーム使ってます。
hybrid -> iceberg -> bluewery。
また適当に紹介記事書くかもです。
なぐり書きですが、それでは良いお年を。
iTerm2からAlacritty+tmuxにしてみた
今までGVimだったんですけど、周り見てみると、普通にターミナル環境でVim触ってる人多いですよね。
Vimにターミナルが入ったとはいえ、あまり使いこなせていないのも現状。
あと、VSCodeではこの感じでずっとやってたので、こんな感じにしたいなーと思った次第。
+なんかツイッターで「Alacritty」なるものを見かけたので、ちょっと飛びついてみました。
Alacrittyを導入
AlacrittyRust製の高速なターミナルエミュレータらしい。
公式に書いてあるとおり、brea cask install alacritty
で入れます。
設定
$XDG_CONFIG_HOME/alacritty/alacritty.yml $XDG_CONFIG_HOME/alacritty.yml $HOME/.config/alacritty/alacritty.yml $HOME/.alacritty.yml
ここのどこかに。
自分は.config/alacritty/alacritty.yml
にできてました。
上から順に辿るとのこと。
見て分かるように、設定はyamlファイルです。
少しだけ設定変えました。
window: # デフォ0,0でやたら画面端から描画されるので、余白ちょっととる padding: x: 5 y: 5 font: normal: family: "Ricty for Powerline" size: 12.5
フォントサイズ小さい言われるけど、ある程度小さめで、全体見渡したいんです。
(でもミニマップは不要派)
Ricty for Powerlineも長年お世話になってます。
tmuxを導入
次にtmux。
便利なのは聞いてたんですけど、とくに不自由もしてなかったので、導入してませんでした。
が、しかし。
「タブ増やしたり、ペイン分割したい」と思っても、Alacrittyだけではできなさそう。
Why isn't feature X implemented?
which are best left to a window manager or terminal multiplexer
そういうのはウィンドウマネージャとかターミナルマルチプレクサーがええよ!みたいな。
だったら、重い腰上げて導入しようじゃないか。が経緯です。
brew install tmux
設定
~/.tmux.conf
。
# デフォルトのC-bが打ちにくい。 set -g prefix C-a # なんかいろいろ ... set -g escape-time 0 bind | split-window -h bind - split-window -v bind h select-pane -L bind j select-pane -D bind k select-pane -U bind l select-pane -R
見かけた設定を入れてみつつ、ちゃっかりペイン移動をhjklにしておく感じです。
やった感想
tmux良いーー。なんで導入してこなかったんだ・・・。
Alacrittyが速いっていうのは、正直なところあんまり体感できてないのですが、、、
(そこまでiTermとかで気にしたことがなかったから)
こういう機会を作ってくれたことには感謝です。
今後体感できるときがくるかもしれないです。。
VSCodeからVimに戻った
去年の末ぐらいからVSCodeに浮気をして、VSCodeを使っていました。
とはいえ、VSCodeのVim拡張を入れて使っていたわけですが。。。
昨年末、Angularを書く機会があって、Vimでは書きにくかったのもあって移行したのでした。
結構不自由なく使えていて、不満もなくしばらくは使っていました。
ところが・・・。
VSCodeVIM is unusable (incredibly slow) on larger files, especially in INSERT MODE
この類のIssueにもあるように、とある部分でパフォーマンスが著しく落ちるのです。
体感1000行あるときっついなーとは思ってます。
新規案件で最初から作っていくならともかく、既存のもを改修するタイプでは厳しかったです。
(最初は、これが遅くなるようならもっと減らせるんじゃない?みたいな指標にしてたりもしましたが)
せっかくだから、貢献できないのかな?とも考えたのですが・・・。
力及ばず。
結局Angularの案件もポシャってしまって、惰性でそのままVSCodeを使っていましたが、段々としんどくなってくるわけです。
遅いなーと思うファイルもVimで開けば快適。
PHPStormなんかもいいなーと社内のPHPStorm勢を横目に、
いい機会だしvimrc整理から始めるかー!と、重い腰を上げた次第です。
少し身を引いていた間の環境の変化に驚く
マッピング周りはほぼ変えず、無駄に入れては使っていないプラグインや、乗り換えができるなら乗り換え先を探して、そこの整理を主にやりました。
プラグインマネージャはdeinからvim-plugに乗り換え。分かりやすく、シンプルでした。
ファイラはvim-filer+依存していたuniteからVaffleに。
さて、補完周り。
VimConfを探ってみると、何やらとcoc.nvimなるものがあるらしい。
ここがネオコンからcoc.nvimになりました。
その他、入れたはいいけど使ってないプラグインなどを削除していった結果、60ちょいあったのが、30ぐらいまで減りました。
なんやかんやよく分からず行数だけ増えてた.vimrcも700ぐらいから370ぐらい?まで減りました。
coc.nvimへの驚き
似たような記事にいろいろ出くわしたのですが、やっぱりすごかったcoc.nvim。
元々TS書きにくいなー、tsuquyomiとかあるにはあるけど、VSCode楽だなーみたいな理由で乗り換えていたので、こいつのおかげでTSも普通に書けるじゃないですか!?
当初の移行した理由がカイゼンされるのなら、Vimでいいような・・・。
定義ジャンプもできるんですか!?
あっ・・・。
元鞘・・・。
またよろしくVim。
おわり。
CSSでDOMを非表示にするパターン比較的なやつ
JavaScript書いていると、「DOMを非表示にしておいて、特定条件で表示する」みたいなのってよく書きます。
一個一個は単純でも、複数になるとそこそこ面倒。。。
今回は、この非表示にする方法にフォーカスしてみるやつです。
なんでもかんでもdisplay: none;
使ってない!?ちょっと考えて使おうね!が趣旨。
CSSで非表示する方法
以下の3つ。
- display: none;
- visibility: hidden;
- opacity: 0;
display:none
はおなじみですね。
他は?opacity
はなんとなく使ったことあるけど、visibility
ってあまり馴染みないような。
だけど、意外と使い分けが大事な場面もあったり。
それぞれ違いを見ていきます。
違いは?
単純な違い
まずdisplay:none
。
display:noneのデモ
触ってもらえば分かると思いますが、DOMが消えて、「高さ」なども消滅しています。
次にvisibility: hidden
。
visibility: hiddenのデモ
display:none
と違って、表示は消えても「高さ」などは残っていることが分かります。
最後にopacity:0
。
opacity: 0のデモ
これも表示は消えて、「高さ」などは残ることが分かります。
ここまでで分かるのは、がっつり消してしまいたいならdisplay: none
。
高さとか残しときたいならvisibility: hidden
かopacity: 0
ってな具合でしょう。
これだけなら好みでどうぞ!って感じなんですが、そんなわけないです。
イベント発火
次にそれぞれにイベントを付与してみます。
toggleを押す前、押した後で、clickしてみると違いが浮き彫りに。
display: none
はそもそも何もないので、イベントはおきない。
visibility: hidden
も同じくイベントはおきない。
opacity: 0
だけはイベントが発生。
opacityは透過度を指定しているだけなので、実態はそこにある状態。
なのでイベントも効いてきますね(考えてみたら当然)。
対象にイベントが付与されている場合は、display:none
か、visibility:hidden
。
一昔前の隠しリンク的なのがやりたいならopacity:0
ですね。
DOMの取得とか
まずGetSizeして、toggleしてGetSizeしてみると分かると思いますが。
display: none
だとサイズもポジションも取れないので、DOMのポジション使って何かするような処理書いてる場合は注意です。
例えば、対象要素の真下にドロップダウンリスト出すーとか、そんなパターンのやつ。
意外と
サンプル書いて、こうやって並べてみると当たり前に思えるけど、実際ハマることがあるので、
何が適切か考えながら使おうねって話でした。
JavaScriptのProxyって結構便利なのでは
Proxyオブジェクトが結構便利だったので書いてみます。
Proxy
Proxy オブジェクトは、基本的な操作 (例えばプロパティの検索、代入、列挙、関数の起動など) について独自の動作を定義するために使用します。
const proxy = new Proxy(targetObject, handler)
targetObject
に対象のオブジェクト、handler
にはそのオブジェクトに対してどうするのか、トラップと呼ばれるメソッドを定義して渡します。
よく使うであろうget
とset
だけ紹介しときます。
get
const user = { name: 'Alice', age: 30 } const proxy = new Proxy(user, { get(target, name) { if (target[name] <= 30) return 17 return target[name] } }) console.log(proxy.age) // 17
get
はconsole.log
など、そのプロパティにアクセスがあったとき、どうやって返すのかを定義できます。
例の場合はage
が30以上なら17
と表示されます。永遠のなんとやら・・・。
set
次にset。
const user = { name: 'Alice', age: null } const proxy = new Proxy(user, { set(target, name, value) { if (name === 'age') { target[name] = 17 return true } return Reflect.set(...arguments) } }) proxy.age = 30 console.log(proxy.age) // 17
例は何をいれても17になります(永遠の...)
使い所
表なりなんなり、データを一覧で表示しないといけないときとか。
条件として、nullとか空文字は-
で表示してー!みたいな場合。
普通に書くと。。。
const rows = dataList.map(data => { return ` <tr> <td>${data.A !== null ? data.A : '-'}</td> <td>${data.B !== null ? data.B : '-'}</td> <td>${data.C !== null ? data.C : '-'}</td> <td>${data.D !== null ? data.D : '-'}</td> </tr> ` }) // tbodyなりにrowsをappend
何も意識せず書くとこんな感じでテーブルのデータ組むと思います。
まとめるならこんな感じ。
const formatter = value => value !== null ? value : '-' const rows = dataList.map(data => { return ` <tr> <td>${formatter(data.A)}</td> <td>${formatter(data.B)}</td> <td>${formatter(data.C)}</td> <td>${formatter(data.D)}</td> </tr> ` })
やってることが単純なので、このレベルならこれで十分ですね正直。。。
Proxyを使うと、
const rows = dataList.map(data => { const p = new Proxy(data, { get(target, name) { if (target[name] === null) return '-' return target[name] } }) return ` <tr> <td>${p.A}</td> <td>${p.B}</td> <td>${p.C}</td> <td>${p.D}</td> </tr> ` })
HTML作ってる部分はスッキリしますね。
その他
ループでnewしまくるのが良いかどうのかってのはちょっとありそうですが、便利な機能なのでもう少し突き詰めたいところ 。
set
なんかはオブジェクトの変更監視もできる気がするので、いわゆるオレオレstore的なのが作れるかも?
Vue3.0でProxyが使われてるとかそんな話を聞いたことがあるようなないような。
そもそもProxyってこんな使い方して良いのかなという疑問は残るんですが。
どうなんでしょう?
今更WebComponentsの触り
わりとガンガンjQueryな、とくにUIライブラリも使っていない。(jQueryUIはあるけど)
いろいろと辛い状況なやつ。
画面追加がある度に、ほぼその画面に合わせてCSSも書きつつ。
レイアウト指示はそこそこ細かく、px単位でたまに指摘される。
そんなのが続くと画面追加があるたびに、HTML、CSS書くのめんどくさい!!!という感情が湧いてくるわけです。
WebComponentsって楽できないのかな・・・がはじまり。
書き方基礎
<hello-world/>
class HelloWorld extends HTMLElement { constructor() { super() const shadowRoot = this.attachShadow({ mode: 'open" }) shadowRoot.innerHTML = `<h1>Hello World</h1>` } } customElements.define('hello-world', HelloWorld)
書き方は意外と簡単ですね。
プロパティ与えたい
React, Vue, Angularなんかを書いていると、コンポーネントにpropsを渡して描画することが多々あります。
似たようなことできないの?って思ったんですが、厳しそうです。
<hello-world data-name="Bob"/>
const HelloWorld extends HTMLElement { constructor() { super() this.myName = this.getAttribute('data-name') ? this.getAttribute('data-name') : '' const shadowRoot = this.attachElement({ mode: 'open' }) shadowRoot.innerHTML = this.template() } template() { return `<h1>Hello ${this.myName}` } } customElements.define('hello-world', HelloWorld)
Attributeでプロパティは渡せるけど、取り出したらこれ文字列ですよね。
無理矢理JSONなんか渡したらいけるのかもしれないけど、そこまでするか・・・?
ちょっとしたステータスで色変えたいよ。とか、そんなレベルで使うのが良いのかなと思いました。
いわゆるJS FW系で扱ってるようなコンポーネントとは似て非なるもの。って感じでしょうか。
まだ詳しくは調べてないけど、間違ってたらすいません。