【2018/6/18更新】immutable.js を利用せずに、当エントリー同等以上の開発が可能な、FP・型推論の強いモジュールを公開しました。https://qiita.com/Takepepe/items/a79e767b38981c910c3f ドメインモデルの需要 フロントエンドフレームワークでプロダクトを作り込んでいくと、ビジネスロジックが view に介入しすぎてしまうことが少なからずあります。下記の様なビジネスロジックが散在しているコードに、スケール耐性があるとは思えません。リリース当時は単純だったものが、複雑に変化していくケースは往々にしてあります。 function TodoItems (props) { const { todos, updateTodo, deleteTodo } = props const items = todos.map(item , i) =

前回：ぼくのかんがえたさいきょうのReact+Redux+CleanArchitecture 前回のさいきょうパターンの検証結果 まずは前回のさいきょうパターンですが、会社内の勉強会で実装を進めて行ったところ、少し整理されてこのようになりました。 Entity（図中model）はExternal層で使えるようにImmutable.jsのRecordを使って実装 ReadOnly、副作用NGという意図 ○ React+Redux的には使いやすかった × mutateメソッドで複製が作れてしまうため、"見るだけ"の意図を突破できちゃった UseCaseはredux-thunkを用いたThunkActionで実装 ○ CleanArchitectureを意識しないで作っていた頃に似た形で実装できた × Storeの構造に依存してしまった re-ducks構造が合わなかったので廃止した re-du

続編を書きました！ 続・ぼくのかんがえたさいきょうのReact+Redux+CleanArchitecture 前書き 最近話題のFluxにおいてモデルをどう扱うのかについて、自分もたまたま似た課題に取り組んでいたのでアウトプットしてみたものです。 まだ検証段階なのであれこれコメントいただけると幸いです。 タイトルは、、一度書いてみたかっただけです（照 発端 扱っているプロダクト（UI）のメンテナビリティ、エンハンサビリティが低い 業務ロジックとUI制御ロジックの分離がうまくできておらず、 ちょっとしたUI改善でも業務ロジックの考慮が必要な状況。 SPAになりさらにUIのコードは複雑化してきている UIだから複雑なアーキテクチャは要らないなんて言わず、DDDを取り入れてみたらどうか と言うことで、インフラストラクチャ層の分離がしっかりしている CleanArchitecture の採用を検

みなさんReactやってますか。やってますよね。最近React Native流行ってるし。 んでいきなりなんですが、あのReactとかいうやつ、実は 特にウェブとは関係ないライブラリ なんですよね。ええぇ……。なのでこの記事ではそれについてだらだらと説明したいと思います。 この記事の背景 最近のReact Nativeブームで「React is 何」「React Nativeについて3行で教えてくれ」みたいなアレコレがよく発生するんですが、その際に「Reactはウェブ向けライブラリである」という先入観がだいぶ素直な理解を阻害しているなーと感じました。 「Reactはウェブ向け」って登場初期は全然間違ってなかったんですけど、厳密には2015年には全く違う状況になって、2019年とか2020年になると完全に間違ってると言える状況が発生し出したので、改めて説明させていただこうと思いました。 別に

「経年劣化に耐えるコード」というのは、だれもが目指すものでしょう。「そもそもフロントエンドのコードは、今ある技術で最良のものを書き捨てるべき」という意見も理解できますが「備えあれば憂いなし」ということもありますので、ここにメモを残します。あくまで、私なりのベストプラクティスですのでご了承ください。 5層に別れた SFC 私はレイヤーによる技術の分離で、ReactComponent の経年劣化に備えています。ここでいうSFCとは「Stateless Functional Component」の略称ではありません。Vue.js の文脈にある「Single File Component」を指します。 // (1) import層 import React from 'react' import styled from 'styled-components' // (2) Types層 type

新人「先輩、TypeScriptのコーディングできました！」 先輩社員「どれどれ」 先輩社員「いやそこら中コンパイルエラーだらけ...なのは型システムが働いてる証拠だ！」 先輩社員「そうだろ？」 先輩社員「型は...ガードレールだ」 先輩社員「進むべきじゃない場所へ進もうとしたら、ちゃんとブロックしてくれる...」 （ぺこぱ風） ってことで、静的型付言語って良いですよね。 今回はTypeScriptを使ってみて嬉しかったことを書いてみます。 登場人物 ワイ・・・ワイ（36歳） 社長・・・社長 ハスケル子・・・インターンの中学2年生 今日から新しいプロジェクト開始 社長「おーい、やめ太郎、ハスケル子ちゃん」 社長「新しいお仕事を獲得してきたで」 社長「技術記事投稿サイトを作る案件や」 ワイ「おお〜、さすが社長はんや」 社長「おおきにやで」 社長「ほんで、そのお仕事の話なんやけど」 社長「クラ

はじめに 近年徐々に複雑になるwebフロントエンドの状態管理の仕組みとして、ReactやVue.jsといったwebフロントエンドフレームワークのお供にReduxやVuexと言ったライブラリを組み合わせて使うことが多いと思います。 それら二つのライブラリは、Elmという高品質webフロントエンド構築のための関数型AltJSが用いているThe Elm Architectureと呼ばれるアーキテクチャに影響を受けて作られました。 追記: ReduxとElmの時系列はReduxの方が先であり、しかしながら状態のimmutableなどは影響を受けていることから、 現在の形のReduxはElmに影響を受けている所がある。 という表現が正しかったようです。 コメントありがとうございます。 参考 Vuexとは何か？｜Vuex reduxjs / redux Elmの型システムや見た目は非常にリーダブルであ

この記事はElm Advent Calendar 2019最終日の記事です。 去年末あたりから現職のチームでElmを書き始めたので、大体1年程度はプロダクションでElmのコードを書き続けたことになる。学生時代はRubyとJavaScriptばっかりだったので、関数型プログラミングとかそういうバックグラウンドは一切なかった。その観点から、改めて率直な感想を申し上げておく。 なお、弊社フロントエンドチームとElmに関するはなしは、私の書いたFringe81アドベントカレンダーの記事を参照のこと。 fringeneer.hatenablog.com Elmには中毒性がある Elmを触ったことのない方からすると「？」になるかもしれない（というか、昔の自分がそうだった）が、率直に言ってElmには中毒性がある。一度Elmを知ると、Elm以外の言語を触るたびに「これ、Elmだったら〇〇なのにな〜」と思う

フロントエンドカンファレンス福岡2019 の資料です。 https://frontend-conf.fukuoka.jp/

静的サイトジェネレーターが最近、非常に普及してきました。 それに合わせて注目されているのが「JAMスタック」です。JAMスタックとは何なのか、なぜJAMスタックが人気になっているのかを紹介します。 Why JAMstack is Becoming so Popular by Luca Spezzano 下記は各ポイントを意訳したものです。 ※当ブログでの翻訳記事は、元サイト様にライセンスを得て翻訳しています。 はじめに JAMスタックとは JAMスタックを使用する利点 JAMスタックはなぜ人気があるのか まとめ JAMスタックの有用なリソース はじめに 最近、静的サイトジェネレーターが非常に普及してきています。静的サイトジェネレーターは使い方が簡単で、最新のテクノロジーとVue.jsやReactなどのJavaScriptフレームワークに基づいて実装されています。静的サイトジェネレーターをは

この記事は、ある程度以上の規模のGUI開発において、React Hooks以後の宣言的UIにより、大規模開発に用いられる設計論に完全に対応できるようになり「ビジネスロジックの変更や追加」に対応するコストを低く保つこと（技術的負債の抑制）ができるようになったことを解説するものです。 技術的負債の抑制には、技術的負債の原因となりがちな「広範囲の密結合」と「適切な疎結合を保つ仕組みの欠如」が欠かせません。それをカバーするのが、大規模開発をクリーンに行える設計論（ここでは「現代的な設計論」とよぶもの）です。クリーンアーキテクチャなんかでGUIによく適用されるHumble Object Patternのようにプレゼンテーションとビューを分離する必然性が無くなるでしょう。 ポイントは ある程度以上の規模で開発するなら設計論をうまく使い設計しないと、技術的負債を抱え込む（ビジネスロジックの変更や追加に対

組み込みC言語ネットワークスタック開発者からGoバックエンドエンジニアにジョブチェンジしました。 最近はTypeScript, React(Hooks), GraphQL, SwiftUIに夢中。 Follow

Elm触ってみると面白くてハマりまして、この記事もそんな一人による紹介記事になります。 この記事が一番ストック数が多いので、v0.17になったことに合わせて書き直しました。（2016年5月18日） ##Elmとは ###・コンパイルすると、HtmlやCSSやJavascriptになる。 Elmとは、コンパイルするとHTML、CSS、Javascriptを生成するプログラミング言語です。 ###・Elmアーキテクチャで書ける。 v0.17から正式にElmはフレームワークを兼ね備えた言語になりました。 後述するElmアーキテクチャというパラダイムでブラウザアプリケーションを書きます。 ###・Elmはシンプルで小さな関数型の言語です。 ElmはHaskellやいろんな関数型言語を参考にして、とても小さく強力な構文を持っています。 ###・学習が始めやすいです。 かなり学習のしやすさや学習曲線を

宣言的UIの状態管理とアーキテクチャSwiftUIとGraphQLによる実践 https://speakerdeck.com/sonatard/swiftui-graphql