typeof Diary

VimとかJSとか。やったことのメモ。自分のため。

久々に心踊るカラースキームに出会った(bluewery)

また書くかも!とかいいつつ、書いて今年終える!!!

エディタのカラースキームはやる気とかに直結すると思っている派です。
あと、カラースキームを変えると気分も変わる気がします。

そんなこんなで、久々に心踊るカラースキームに出会ったので書いておきます。

bluewery.vim

bluewery.vim

早速入れて適用してみました。
スクショの時間12/20だね。随分前だ・・・。

f:id:lisia:20191231190523p:plain

この緑感たまりません。
何回かカラースキーム変えようと試みてはいましたが、結局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でいけるんちゃう・・・?となったのがキッカケです。

VSCodeVim拡張を入れて使ってましたが、行数が増えるとパフォーマンスの悪さが目立ってしまって、さすがにしんどくなりました。

今までMacVim-kaoriyaでやってたのも、いろんな人を見ていると大体ターミナルでVim使ってる気するので、
その辺りもAlacritty + tmuxでVim使う感じに変えました。

で、年末。

久々に心踊るカラースキームと出会って終了みたいな感じです。
bluewery

今はこのカラースキーム使ってます。
hybrid -> iceberg -> bluewery。

また適当に紹介記事書くかもです。

なぐり書きですが、それでは良いお年を。

iTerm2からAlacritty+tmuxにしてみた

今までGVimだったんですけど、周り見てみると、普通にターミナル環境でVim触ってる人多いですよね。

Vimにターミナルが入ったとはいえ、あまり使いこなせていないのも現状。
あと、VSCodeではこの感じでずっとやってたので、こんな感じにしたいなーと思った次第。
f:id:lisia:20191117105018p:plain

+なんかツイッターで「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とかで気にしたことがなかったから)

こういう機会を作ってくれたことには感謝です。

今後体感できるときがくるかもしれないです。。 f:id:lisia:20191117105059p:plain

VSCodeからVimに戻った

去年の末ぐらいからVSCodeに浮気をして、VSCodeを使っていました。
とはいえ、VSCodeVim拡張を入れて使っていたわけですが。。。

昨年末、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でいいような・・・。

定義ジャンプもできるんですか!?
あっ・・・。
元鞘・・・。

f:id:lisia:20191116164315g:plain

またよろしく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: hiddenopacity: 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にはそのオブジェクトに対してどうするのか、トラップと呼ばれるメソッドを定義して渡します。
よく使うであろうgetsetだけ紹介しときます。

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

getconsole.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系で扱ってるようなコンポーネントとは似て非なるもの。って感じでしょうか。

まだ詳しくは調べてないけど、間違ってたらすいません。