JavaScript Patterns Workshop | JavaScript Patterns
The content is based on Patterns.dev - a free online resource on design patterns and component patterns for building powerful web apps with vanilla JavaScript and React. The patterns covered on this website and in the workshop can guide you when facing a problem other developers have encountered many times before, but are not a blunt tool for jamming into every scenario. The goal is to raise aware
The new wave of Javascript web frameworks
The new wave of Javascript web frameworksMake sense of the proliferation of new Javascript web frameworks. A deep dive into the problems at scale and the recent evolution of innovation. IntroductionStaying current in the Javascript ecosystem is not for the faint of heart. It’s challenging for those entering the industry to follow what’s happening amongst the new libraries, frameworks, concepts, an
React で <Stack.Item> みたいな作り方の使い所を考える
自分ではあまり使ったことがないのですが、最近他所のデザインシステムの実装なんかを眺めていて <Stack.Item> のようにあるコンポーネントのプロパティとして他のコンポーネントを定義するパターンを何度か見かけて、どんな時に有効なのかを考えてみたくなった次第です。 具体例 Shopify のデザインシステムの中にある Stack と Stack.Item が当てはまります。 これらのコンポーネントは次のようにセットで使われます。 <Stack> <Stack.Item fill> <Heading>Order #1136</Heading> </Stack.Item> <Stack.Item> <Badge>Paid</Badge> </Stack.Item> <Stack.Item> <Badge>Fulfilled</Badge> </Stack.Item> </Stack> //
フロントエンドでClean Architectureを適用してみる(+サンプルコード) - Qiita
ここ数年でClean Architectureはおなじみのアーキテクトとして親しまれるようになりました。 とりわけ単体テストを書く習慣が根付いているバックエンドで重点的に取り入れられているように見受けられますが、フロントエンドにおいても同様にClean Architectureを導入し、メリットを享受できます。 今回はフロントエンドにClean Architectureを導入する手順を、実際にコードを追いながら紹介していきます。 実際のコード 実際に書いたコードはこちらのGithubに公開しています。データを外部から取得するフローを表現するために、node.jsで実装されたモックサーバーも用意しました。 https://github.com/t-tiger/React-CleanArchitecture-Example 前提知識 Clean Architectureでおなじみの図と共に前提
Webアプリケーションのセッション管理にJWT導入を検討する際の考え方 - r-weblife
おはようございます、ritou です。 qiita.com これの初日です。 なんの話か 皆さんは今まで、こんな記事を目にしたことがありませんか？ Cookie vs JWT 認証に JWT を利用するのってどうなの？ JWT をセッション管理に使うべきではない！ リンク貼るのは省略しますが、年に何度か見かける記事です。 個人的にこの話題の原点は最近 IDaaS(Identity as a Service) として注目を集めている Auth0 が Cookie vs Token とか言う比較記事を書いたことだと思っていますが、今探したところ記事は削除されたのか最近の記事にリダイレクトされてるようなのでもうよくわからん。 なのでそれはおいといて、この話題を扱う記事は クライアントでのセッション管理 : HTTP Cookie vs WebStorage(LocalStorage / Sess
Reactのコンポーネントをステートレスに！！！recomposeとは？ ~0からreact習得記 day 09~ - Qiita
Reactのコンポーネントをステートレスに！！！recomposeとは？ ~0からreact習得記 day 09~ これまでのreact習得記は、こちらから閲覧できます。 はじめに 株式会社VRizeでインターンとして勤務しているryo_tです。 短期目標に「１ヶ月でReactのUIを開発できるように」と伝えられたので、Reactはほとんど未経験ですが一歩一歩頑張って行きます。 目的 Higher-order Componentsとrecomposeを理解してコンポーネントに状態を持たせない設計を 行える様にする。 Qiitaで検索してもrecomposeの記事は13件しか（2017年10月12日現在）なかったので、使い方を簡単にまとめてみようと思います。 用語整理 recomposeはHigher-order Componentsを作成・提供するための便利関数ライブラリです。 React
JSON Schema 中心設計 - FlowType から RAML まで - - Qiita
はじめに Web サービスの運用を続けていくと，依存関係が徐々に複雑になっていきます．そしてメンテナンスするものが増えた結果，それらが相互に乖離していく，といったことが起こりがちです． そこで今回は，JSON Schema のみをメンテナンスしていくことで，動的チェック (バリデーション)，静的チェック (FlowType)，API ドキュメント生成，スタブ作成といった様々な恩恵を享受し，品質と保守性を同時に向上させるアプローチについて書いていきます．この JSON Schema を中心に据えたエコシステムを，JSON Schema 中心設計と呼ぶことにします． JSON Schema の仕様については割愛しますので，必要な方は こちら をご覧下さい．また，本記事では JavaScript での事例を紹介しますが，他の言語でも同様の適用ができるかと思います． アプローチ 本記事では，以下の
実況中継シリーズ - 複雑なJavaScriptアプリケーションに立ち向かうためのアーキテクチャ - Re.Ra.Ku tech blog
先日行われた builderscon tokyo 2017 にて、「複雑なJavaScriptアプリケーションに立ち向かうためのアーキテクチャ」という発表をしてきました。この記事では、そのプレゼンテーションの再現を行います。 アバンパート 本日はこういう発表をします。よろしくおねがいします。 普段はメディロムという会社で働いていて、ScalaとJSを主軸に活動しています。PerlとRubyもたしなむ程度には書きます。業務では、業務で使うアプリケーションをブラウザプラットフォーム上に作っています。こういうブログも書いてるんでよかったら読んでください。 あと、何度かweb+DBプレスに特集書かせてもらっていて、とくに左の「データ構造の基礎知識」ってやつは自分で言うけどまじでいい記事なんでまだ読んでないひとはバックナンバー買って読んでください。 さて、複雑なアプリケーションに立ち向かうためのアー
Reduxにドメイン層を導入する - Qiita
【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) =
Polyfill のあり方と Web の進化と協調するためのガイドライン | blog.jxck.io
Intro W3C の TAG から、主にブラウザ API の Polyfill に関するドキュメントが公開された。 Polyfills and the evolution of the Web Polyfill は便利な一方で、時として標準化の妨げになってしまう場合があるため、それを避けるために、 Polyfill 実装者、利用者、仕様策定者などが、どう振る舞うべきかという趣旨である。 今回はこの内容を元に、 Web の進化と協調する Polyfill のあり方について、主に「実装者」がどうすべきかに着目し記す。 Web における Breaking Change Breaking Change は、簡単に言えば 後方互換を失うことで既存のものが壊れる可能性がある変更 のことを表す。 そして、 Web における Breaking Change (Break the Web)、具体的には W
Redux without React — State Management in Vanilla JavaScript — SitePoint
This article was peer reviewed by Vildan Softic. Thanks to all of SitePoint’s peer reviewers for making SitePoint content the best it can be! I am one of those developers who likes to do things from scratch and get to know how everything works. Although I am aware of the (unnecessary) work I get myself into, it definitely helps me appreciate and understand what lies behind a specific framework, li
javascriptで発行/購読パターンを使ってモジュールの関係を疎結合に保つ - Qiita
発行/購読パターンとはなんぞや。 発行/購読パターン(パブリッシュ/サブスクライブ)とは、発行側(パブリッシャー)と購読側(サブスクライバー)という二つの実体の間に、チャンネル(トピック)と呼ばれる中継層を設け、メッセージ交換はチャンネルを介して行うパターンです。パブサブ(Pubsub)とも呼ばれます。 パブリッシャーは、特定のチャンネルにメッセージを公開(パブリッシュ)し、サブスクライバーは購読(サブスクライブ)しているチャンネルの新規メッセージ公開時にその通知を受け取ります。 発行/購読パターンを用いれば、各実体(メソッドなりオブジェクトなり)を分離し部品化することができます。これによりアーキテクチャが疎結合になり、拡張性・再利用性を高めます。 論よりコード まずは発行/購読パターンを使わない場合の例を書いてみます。 ユーザーがアクセスすると、サーバーからAjaxでユーザー情報を取得し
たぶんこれが一番分かりやすいと思います React + Redux のフロー図解 - Qiita
【追記】 もうこれ古いから参考にしないでください https://t.co/mXtcc73Orf — もし Laravel が流行しなくなってこられてきてたとしたら、絶対に捨てられてこられてたと思うか (@mpyw) January 26, 2021 Redux にはその昔 connect()() とかいうクソ API と， Redux-Saga とかいう宗教がありました という考古学です — もし Laravel が流行しなくなってこられてきてたとしたら、絶対に捨てられてこられてたと思うか (@mpyw) January 26, 2021 読者対象 Tutorial: Intro To React - React Example: Todo List · Redux 「チュートリアルそれぞれ一周した！Reactは何とか理解できたが，Reduxがさっぱりわかんねぇ！」 ぐらいの人向け。自分
Railsが時代に合わなくなってきた
追記 RailsでJS辛い問題に関しての結論：http://qiita.com/kaiinui@github/items/dad6180f1910c6a4bfd5 -- 近年、(1) Web/App両対応が増えてきたこと、(2) WebでもJSを多用するようになったこと、の二つがあり、以下の点でRailsが微妙になっている。 ViewのJavascriptがRailsから独立している API層のサポートが微妙 最初に書いておきますが、特に決定的な解決策もなく、辛いから今後解消されてほしいよね、な話です。 ViewのJavascriptがRailsから独立している Railsはとても堅牢。 モデル、コントローラ、ルーティングと、変にいじらない限りはほとんどテストが要らない。 必要なのは、モデルに新たにpublicメソッドを付けたときくらいだろう。 実際、バックエンドはそうそうバグが出ない。
全てがJSONになる - ✘╹◡╹✘
TL;DR JSON Schemaを使ってこういうことが実現可能になった。 ダミーAPIサーバの提供 ドキュメントの自動生成 APIクライアントの動的定義 APIサーバのバリデータの動的定義 APIサーバのレスポンスの自動テスト JSON Schemaとは JSON SchemaというのはあるJSONのデータ構造を記述するための方法および書式の仕様で、 JSON SchemaもJSONで記述される。 これを利用すれば、リソースベースの(=RESTfulライクな)APIの仕様が簡便に記述できる。 例えば、我々のAPIはレシピとユーザというリソースを扱っていて、 それぞれCRUDのAPIを備えており、レシピはidとtitleとdescriptionという属性を持つ、 という旨をJSON Schemaで表現できる。 なんで最近ちょっと流行ってんの Mobile First、 Service Or
Fluxアーキテクチャのメモ
最近は Flux + React を使っています。Secure Code Tipsでも部分的に採用しました。今回は Fluxアーキテクチャについて、現時点で自分の理解している内容をメモしておきます。 Fluxの概念図Flux: Actions and the Dispatcher | React というページでは以下の図が使用されています。よく見る図です。 現在の自分の認識を基にしてこの図をもう少し詳しくすると、以下になります（だいたいこんな感じという程度の図です）。 * Web API と Web API Utils は省略しています。 Web API と Web API UtilsAction Creators が保持しているメソッド内からAjaxリクエスト処理等を行う場合、その部分をこちらに切り出して使用します。Action Creators と ActionsAction何かしら新
André Staltz - Unidirectional User Interface Architectures
This post is a non-exhaustive quick overview of the so-called “unidirectional data flow” architectures. Not meant to be taken as a beginner tutorial, but rather as an overview of their differences and peculiarities. At the end, I’ll introduce a new architecture which deviates significantly from the others. This post assumes client-side Web UI frameworks only. TERMINOLOGY It would be confusing to t
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://post.simplie.jp/posts/81
Redux + React (Example: Todo List) の構成図 - Qiita
Payforward
