Skip to content

Instantly share code, notes, and snippets.

@mitubaEX
Last active August 31, 2019 07:40
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save mitubaEX/a87857be92aa57e089edcb15accbfbda to your computer and use it in GitHub Desktop.
Save mitubaEX/a87857be92aa57e089edcb15accbfbda to your computer and use it in GitHub Desktop.

フロントエンドのつくりかた - シンプルなコードを達成するためのセオリー

nrslibさん

フロントエンドのつくりかた │ nrslib

GUIアーキテクチャパターン

MVC

simpleな処理の流れにしたい

ゲームに例えるとわかりやすい コントローラー -> ハード -> テレビ

これは古典的MVC

model から viewへのdataの流れ、observerパターンを利用

MVC2 <- controllerがviewを描画する

MVP

view -> presenter -> model

昨今のゲームはviewにボタンがあるので、コントローラがなくてもよくなった

MVC -> MVPになった

MVVM

双方向バインディングでやる MVP

重要なのはMVを分けることが重要

MVX

M V extra

MVW

model view whatever

flux

MVC -> MVP -> fluxになったと考える

重要なのはデータフロー

データ同期

フロント側でユーザ情報を更新するという処理は不整合に繋がる

流れは、ユーザがサーバにリクエストを持ってきて、frontは再度値を持ってくるだけ あくまでフロントは、サーバのデータを取るのみの仕事をする

エラーハンドリング

ユーザが回復できるエラーを優先する

システムエラーは拾わないようにする

ディレクティブなどでvalidationの処理を共通化する

画面ごとに表示するのは結構大変なので、上に一括でエラーを出してあげる

axiosのconfigを変えてやって、エラーメッセージを日本語化してあげたりする

axiosにcallbackを渡して、validateをカスタムできるようにしてあげれば共通化がしやすい

コンポーネント構造

オブジェクト指向

相互参照はやばい

一つ親を作ってやればいい

コンポーネント構造も一緒 tabButton, tabButtonGroup

データは基本的に親コンポーネントが持っているべき

fluxの利用方法

全体が共通して持つべき値のみを持っているべき

v-modelは上に対してeventを発火しているらしい

GUIプログラミングで目指すべきこと

humble view

テストが必要もないほど、慎ましいviewを目指すこと

○○2vec 再考

agatanさん

いろんなものをベクトルにする

顔画像検索

類似ベクトルを検索する

文書分類

グラフ構造

大体のデータはグラフ構造で考えられる

○○2vecとグラフ構造を合わせると様々なことができる

0円自作キーボード(配列)入門

postboさん

dvorak歴8年

JIS X 4063に日本語入力方法の仕様が書いている もう廃止されている

google はこれを全て実装しているらしい

入力の抽象

物理層 -> キーコード層 -> アスキー層 -> 表音層 -> 表意層

漢直は3ストロークで全部出せるらしい

キーボードカスタマイズしている人は物理層が多め

ローマ字テーブルは誰もいじっていないので、いじった

ローマ字テーブルはgoogle 日本語入力から簡単に取得できる

dvorakの悩みは母音の偏りがあるので、dvorak jpがある

v, fは利用しないので消したらしい

anpan配列だと左右交互に打つ確立が高いらしい

設計した自作キーボードの基板を中国で小ロット量産するときの苦労、涙、理由

mackee

話に集中していた

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment