AWS Dev Day Tokyo 2018でMicro Frontendsについて話したスライドです。 #MicroFrontends #マイクロフロントエンド

AWS Dev Day Tokyo 2018でMicro Frontendsについて話したスライドです。 #MicroFrontends #マイクロフロントエンド
JavaScriptでは、最近、DOMContentLoadedをよく目にします。 原典 クリーンアーキテクチャ(The Clean Architecture翻訳) JavaScriptで実践 勤務実績一覧 人を選んだら過去勤務実績を年度/毎月(概要あり)のタブ区切りで表示する 毎月、何時間働いたか、その内訳は何か 選択ユースケース 選択した所属部門に属する人だけ絞込可能 選択可能な従業員の勤務形態も同時変更 さらに選択した勤務形態(社員/パート)でも絞込可能 この場合は所属部門は絞り込まれない 同様に、勤務した個別月から絞込可能 UIイメージ 早速困ったこと Usecaseの粒度 ひとまず、class Usecaseで一つ FilterUsecase#changeDepartment(i, department) FilterUsecase#changeLabortype(i, labo
All slide content and descriptions are owned by their creators.
こんにちは、fluctの@nekoyaです。 今日は現在開発に携わっている、俗に言う「管理画面」のWebアプリケーションのアーキテクチャをご紹介します。 このアプリケーションはReactとRxJSを軸として作られており、コードはTypeScriptを使って書いています。 アプリケーションを流れるデータと状態の管理について、Write StackとRead Stackという考え方を取り入れたところ、いろいろなメリットが得られたので、そのあたりを軸に掘り下げてみます。 全体の大まかな構成 各Stackの前に、まずはアプリケーション全体の構成をざっくりと見ておきます。 流れとしては、DispatcherからWrite Stack, Read Stackを通ってStateが生成され、それをViewが受け取るという構成になっています。 全体の流れとしてはFluxっぽい何かのひとつのあり方なのですが、
こんにちは、Web アプリケーションエンジニアの id:nanto_vi です。先日開催された Kyoto.js #12 において、「薄いフレームワーク指向の Web クライアントサイドプログラミング」と題した発表を行いました。とある Web アプリケーションの開発にあたって、JavaScript による GUI プログラミングにどう取り組んだかという話になります。当日のスライドの内容に口頭で伝えた内容を加え、以下にまとめます。 前提 SPA ではない そこまで覚悟しなくてもよい 薄いフレームワーク指向 cf. ぼくのかんがえたさいきょうのうぇぶあぷりけーしょんふれーむわーく - YAPC Asia 2011 開発期間が決まっている Web アプリケーションを新規開発するにあたり、クライアントサイドをどう実現するか。ここでは開発期間が決まっているというのが大きな要因となり、チームメンバーの
プロダクトに関わるエンジニアは40人近くいて、弊社ではフロントエンド/サーバーサイドといった明確な線引きがないため全員がフロントエンドに触れる機会が有りえます。開発チーム・コード共にそれなりに大規模と言えるのではないでしょうか。 やったこと モジュール間の依存解決 もともとRailsのSprocketsに沿ってjsを書いていたため、classは全て一つのグローバル変数に格納され、全てのjsが結合された巨大なapplication.jsをロードしている状態で、メンテナビリティやパフォーマンスに大きな問題を抱えていました。そこで去年よりWebpackを導入し、各モジュールの依存関係を整理してjsファイルを適切な単位に分割するようにしました。ファイル数が多いため段階的に作業をつづけ、今年ようやく全てのファイルの依存解決が完了することができました。 過渡期はWebpackとSprockets両方か
How does SAM work? SAM is built on one of the most robust foundation of computer science (TLA+). SAM recommends factoring application state management along three building blocks, actions, model, and state that are invoked in well defined "steps". Actions are triggered by events, their role is to translate events into proposals to mutate the model The Model is solely responsible for the decision o
数ヶ月前、私はなぜここにたどり着き、何が可能かを理解する旅に出ました。この旅は、私にアプリケーションアーキテクチャ、MVCという強烈な宗教に対する疑いをもたらしました。そして、リアクティブ、関数型プログラミングの真の実力に触れたのです。また、シンプルさに集中する旅でもあり、私たちの産業はうまくやっているという考えを捨てる旅でもありました。どんなことを見つけたか興味がある方もいるでしょう。 私たちの見ている画面の背後にあるパターンはMVC –Model-View-Controllerです。まだウェブがなくソフトウエアアーキテクチャも分厚いクライアントが単一のデータベースに原始的なネットワークでアクセスするのがせいぜい、という時代にMVCは生まれました。そして数十年後、MVCはまだ現役であり、衰え知らずでオムニチャネルアプリケーションの開発に使われています。 Angular2のリリースの前にM
Immutable data structures – also known as persistent or purely functional data structures – are a key part of modern functional programming. Once created, immutable data structures cannot be modified. Instead, they support operations which efficiently produce a new copy of the structure with the desired changes applied. As I’ve gotten more experience working with immutable data structures, I’ve fo
Edit · Apr 10, 2016 · 21 minutes read · Follow @mgechev JavaScript Angular 2 TypeScript redux flux dependency injection In order to have better understanding of the following blog post you should be familiar with the fundamentals of the object-oriented and functional programming. I also strongly encourage you to explore the redux pattern. A couple of months ago I started working on the first versi
For the past few months, I’ve been on adventure learning everything I could about functional programming. It seems like every week there’s a new frontend framework or library claiming some inspiration from functional programming, so I decided to check it out. One of my explorations was into Elm: an amazing Haskell-inspired language for building web applications. It gave me a taste of what function
このファイルは README.md の翻訳です。 commit 7d5d75bc7a2ecb87c0d7ed182a94ff4d128f722f 時点の README.md に基づいています。 Elm アーキテクチャ このチュートリアルでは "Elm アーキテクチャ" を概説する。 "Elm アーキテクチャ" は全ての Elm プログラムに見出す事が出来る。例えば、 TodoMVC や dreamwriter といったものから、 NoRedInk や CircuitHub などの商用製品の中で動作しているものにもである。基本的なパターンはフロントエンドを Elm や JS や、他の何かで記述する際にも有用である。 Elm アーキテクチャは無限にネストされるコンポーネントの為の単純なパターンであり、モジュール性、コードの再利用、テストの観点で優れている。究極的には、このパターンは複雑なウェブ
名前はダークソウルのフラムト(frampt)から。FLux Minimum なんたらかんたら。 なんかTwitterで色々言ってたら naoyaさんにまとめられたので、ここに僕の考えを詳しく書いておく。 mizchi の Redux 考 - Togetterまとめ やりたかったこと 基本的なアイデアは、stateをpushする方式(setStateみたいな)だと非同期間で参照したときの値がズレて非同期の終わる順番次第では状態の遷移ステップが壊れてしまう可能性があるんだけど、前のstateをとって次のstateを返す非同期をキューに並べて順に実行することで、トランザクションみたいなものを保証することができるだろう、というもの。 軽量(pubsubインターフェースはEventEmitterそのまま) 複数の状態更新関数の待ち合わせ reduxで感じた不満の解消 TypeScriptフレンドリー
最初はちょっととっつきにくいけど、責務がはっきり分かれていて比較的コードがごちゃごちゃになりにくい(と思っている)Reduxですが、やはり実戦投入するとどうにも扱いにくい部分が出てきます。 特にそう感じるのは通信系の処理、ユーザーとのインタラクションです。これってつまるところ非同期処理なんですが、処理を依頼する側、つまりActionを投げる側としては「あとのことはまかせた!」と言いたい。Actionを投げる部分ってのはだいたい何かのイベントハンドラだったりしますが、そういう場所に通信やインタラクションの処理をダラダラと書きたくない。 本稿ではそれらの面倒な部分を責務が分離されたメンテナンスのしやすいコードになるようにmiddlewareを活用する例をいくつか紹介します。 その前にmiddlewareについて Reduxの公式ドキュメントではログ出力を例に取り、アプリケーション本体から分離し
How to design the architecture of an Angular application and not go insane in the process Do I really need a strategy?Yes. A fresh application always starts out as that one application that’s going to be designed for easy maintenance and development. Unfortunately, it’s just a matter of time until that application becomes non-trivial and needs reorganisation and/or a rewrite. In those moments, it
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く