Redux: RFC：Reduxスターターキット

はいはいはい！ 私はこれについて多くの意見と願いを持っています！ しかし、私は自分自身を抑制し、議論を最初に始めさせます。

createReduxStore()関数に自動的に追加されるレデューサー用の組み込みHMRが、実現可能かどうかわからないウィッシュリスト項目の1つです。 残念ながら、Webpackに関する私の知識といくつかの実験では、Webpack module.hot.accept()コールバックにレデューサーファイルへのパスをハードコードする必要があるため、これはあまり実現可能ではないと言われています。 パーセルまたは他のバンドラーがそれをどのように処理するかわからない。

したがって、全員からのフィードバックの最初の要求：

• このパッケージで満たしたい主な要件は何ですか？
• これらの要件を満たすために、どの_既存の_パッケージを提案しますか？
• これらのパッケージを組み合わせて、エンドユーザーにとって物事をシンプルに保つにはどうすればよいでしょうか。

3つの重要なポイントを挙げましょう。可能な場合、バリアントは互いに_分離_されます。

1. 最初のポイント。 レデューサーマネージャー
   1.0バニラ（ここに当てはまりますか？）
   1.1 Immer.js
   1.2コレダックス
   1.3100500以上のパッケージ

2. 2点目。 ミドルウェア
   2.0バニラ（そうですか？）
   2.1サガ
   2.2叙事詩
   2.3100500以上のパッケージ。

3. 3点目。 Reactの統合
   3.0。 バニラ（ここに当てはまりますか？）
   3.1。 部分空間
   3.2言い換える
   3.3100500以上のパッケージ。

4位、ボーナス、ポイント
4.0_boilerplate_でこれらすべてのものをテストします。

「選ばれたもの」を選ぶことは不可能です。たとえば、私はSagasとEpicsの両方が大好きで使用していますが、いくつかの「料理の領収書」と組み合わせの推奨事項を提供することはできます。

たとえば、ほとんどのreduxユーザーはミドルウェアについて__only__を知っています。 小さな部分もレデューサーで何かをしています（immutable.jsについてはたくさん聞いています）、ほんの数個がReactの統合を強化します。

スターターキットは、最初から完全で_リッチな_アプローチを構築するのに役立つ可能性があります。 または、複数のスターターキットが必要です。

Twitterでセットアップ/ボイラープレートの問題点に関するフィードバックを求められました： https ：

Twitterで私の応答をコピーする：

IMOは、他の人にreduxを行う「あなたの方法」を導入するときに複雑さを増すため、reduxボイラープレートを追加することは明示的に避けてきました。 reduxをより移植性の高いスキルにするために、コードを介して適用されるより規範的な規則が欲しいです。

そのために、 create-redux-appスタイルのリポジトリ（ただし、フレームワークよりもライブラリとして設計されている）、特にReduxのメンテナがベストプラクティスと推奨プラクティスを明示的に承認している場合は、明確化と明確化に大いに役立つと思います。適切なReduxの使用法について。

私たちはReactifluxでこれについて少し話していましたが、このスレッドに含めることへの欲求の統合をコピーしたいと思っていました。これのいくつかは、すでに@timdorrにリストしたポイントと重複しています（したがって、熱狂的な確認です）。

1. より良いデフォルトのcreateStoreのラッパー、つまりミドルウェア、redux開発ツールを追加する簡単な方法
2. 組み込みの不変ヘルパー（イマー？）
3. createReducerが組み込まれています（標準の「リデューサールックアップテーブル」ユーティリティ）
4. ビルトインを再選択
5. FSAに準拠したアクションクリエーター
6. 非同期アクションサポート/副作用サポート（フラックス、サガ、何？）

Henrik Joretegのredux-bundlerのように、すでに存在するものを公式に支持してみませんか？

https://github.com/HenrikJoreteg/redux-bundler

それは簡潔で、（良い意味で）意見があり、アプリケーション間でredux関連の機能を再利用でき、それでも非同期処理のための優れたソリューションを提供します。

これは魅力的なプロジェクトであり、私が本当にさらに調査したいプロジェクトですが、このタスクでやりたいことの範囲外でもあります。

ここで本当に達成したいのは次のとおりです。

• 数行のコードと最小限の構成選択でReduxストアをセットアップする（「zero-configJS」タグラインWebpackとParcelに相当するReduxが使用されています）。
• CRAと同様に、構成要素は基本的に非表示になっており、デフォルトですぐに使用できます。
• 開発エクスペリエンスを向上させ、「ボイラープレートを減らす」ために慎重に選択されたパッケージを含める。 たとえば、Immerは、不変のレデューサーロジックの記述を大幅に簡素化し、devでの状態をフリーズするため、優れた選択肢になります。 （私の唯一の躊躇は、「変化している」コードの外観が混乱することです。）

私はこの努力をかなり厳密に範囲を定めたままにしておきたいと思います。 私はここ数時間、 Reactifluxで@hswolffと@nickmccurdyとチャットしてきました。議論は素晴らしいものでしたが、私たちはすでに、物事を非常に複雑にする可能性のある12の重複するユースケースとアイデアを経験しました。

私は、あまりバイクシェッドをせずに、有用で価値があり、実行可能なものをまとめて、他の議論を脇に置きたいと思っています（Reduxの「バンドル」や「モジュール」を作成するためのAPIなど）。

APIの最初のボイラープレーティングを開始するために、上記で投稿したリストの1〜3の基本的なアイデアを次に示します。

// #1
export function createStore({
    // If an object is given it's passed to combineReducers
    // otherwise it's just used directly.
    reducer: Object<String, Function> | Function,
    // Middleware is built-in and accepts an array of middleware functions.
    middleware: Array<MiddlewareFunction>,
    // Built-in support for devtools.
    // Defaults to NODE_ENV !== production
    devTools: boolean,
    // Same as current createStore.
    preloadedState,
    // Same as current createStore.
    enhancer,
}) {};

// Re-exported for easy usage.
export function combineReducers() {}

// #2
// Re-export immer as the built-in immutability helper.
import immer from 'immer';
export const createNextState = immer;

// #3
// Export an already written version of createReducer .
// Same thing as https://redux.js.org/recipes/structuring-reducers/refactoring-reducers-example#reducing-boilerplate
export function createReducer() {}

うん、私はそれを掘ります。 その場合、ミドルウェアリストの先頭に常にthunk()が追加されるか、ミドルウェアを自分で提供しなかった場合にのみ追加されると思います。 ここでユーザーがエンハンサーを指定できるようにしたくない場合もあります。 私たちは、追加したいapplyMiddleware()任意のミドルウェアがある場合、自動的に、かつ使用composeWithDevtoolsから機能をredux-devtools-extension場合devTools : true 。 この「簡単なセットアップ」の目的のために、ユーザーが構成できるものから「エンハンサー」を排除したいと思うかもしれません。

エンハンサーを排除すると+1。

サンクが自動的に追加されるという点で、デフォルトのミドルウェアを追加するために使用する関数をエクスポートすることで、ケーキを手に入れて食べることができるはずです。

export function createDefaultMiddleware(...additional) {
    return [thunk(), ...additional],
}

// Within a user's application
createStore({
    // By default it's just createDefaultMiddleware()
    // However if you want to add any other middleware you can.
    middleware: createDefaultMiddleware(any, other, middleware)
})

ええ、それは大まかに私が考えていたものです。 私の主な関心事は、ユーザーが誤ってthunk独自のインスタンスを提供しようとしたかどうかを把握することです。

私は今晩少し物事をいじることに決めました。 これが最初のカットです。 考え？

// configureStore.js
import {createStore, compose, applyMiddleware, combineReducers} from "redux";
import { composeWithDevTools } from 'redux-devtools-extension';
import createNextState from "immer";

import isPlainObject from "./isPlainObject";

import thunk from "redux-thunk";


const IS_DEVELOPMENT = process.env.NODE_ENV !== "production";

export function createDefaultMiddleware(...additional) {
    return [thunk, ...additional];
}

export function configureStore(options = {}) {
    const {
        reducer,
        middleware = createDefaultMiddleware(),
        devTools = IS_DEVELOPMENT,
        preloadedState,
    } = options;

    let rootReducer;

    if(typeof reducer === "function") {
        rootReducer = reducer;
    }
    else if(isPlainObject(reducer)) {
        rootReducer = combineReducers(reducer);
    }
    else {
        throw new Error("Reducer argument must be a function or an object of functions that can be passed to combineReducers");
    }

    const middlewareEnhancer = applyMiddleware(...middleware);

    const storeEnhancers = [middlewareEnhancer];

    let finalCompose = devTools ? composeWithDevTools : compose;

    const composedEnhancer = finalCompose(...storeEnhancers);

    const store = createStore(
        rootReducer,
        preloadedState,
        composedEnhancer
    );

    return store;
}

export function createReducer(initialState, actionsMap) {
    return function(state = initialState, action) {
        const {type, payload} = action;

        return createNextState(state, draft => {
            const caseReducer = actionsMap[type];

            if(caseReducer) {
                return caseReducer(draft, payload);
            }

            return draft;
        });
    }
}
export {createNextState, combineReducers};

そして、必須のサンプルtodoアプリ：

import {configureStore, createReducer} from "./configureStore";

const ADD_TODO = "ADD_TODO";
const TOGGLE_TODO = "TOGGLE_TODO";
const SET_VISIBILITY_FILTER = "SET_VISIBILITY_FILTER";

function setVisibility(state, newFilterType) {
    return newFilterType;
}

const visibilityReducer = createReducer("SHOW_ALL", {
    [SET_VISIBILITY_FILTER] : setVisibility
});


function addTodo(state, newTodo) {
    state.push({...newTodo, completed : false});
}

function toggleTodo(state, payload) {
    const {index} = payload;

    const todo = state[index];
    todo.completed = !todo.completed;
}

const todosReducer = createReducer([], {
    [ADD_TODO] : addTodo,
    [TOGGLE_TODO] : toggleTodo
});


const preloadedState = {
    todos: [{
        text: 'Eat food',
        completed: true
    }, {
        text: 'Exercise',
        completed: false
    }],
    visibilityFilter : 'SHOW_COMPLETED'
};


const store = configureStore({
    reducer : {
        todos : todosReducer,
        visibilityFilter : visibilityReducer,
    },
    preloadedState,
});

const exercise1 = store.getState().todos[1];

store.dispatch({type : "TOGGLE_TODO", payload : {index : 1}});

const exercise2 = store.getState().todos[1];

console.log("Same object: ", exercise1 === exercise2);

store.dispatch({type : "SET_VISIBILITY_FILTER", payload : "SHOW_COMPLETED"});

console.log(store.getState());

これは堅実なスタートであり、このスレッドで議論されているlibの素晴らしい始まりだと思います。 上記の必要な機能のリストから、ポイントしています。

この上で繰り返すのは素晴らしいことですが、これは強固な基盤です。

実装に集中するのではなく、DXに集中してほしい。 エクスポート/ APIとは何ですか？それらはどのように使用されますか？ 構成だけを乗り越えて、人々がどのようにストアを使用しているかを見る絶好のチャンスだと思います。 いくつかのランダムなアイデア：

より簡単なレデューサー/アクションのペア：

レデューサーとアクションを状態出力と組み合わせるのが非常に簡単になります。 これは大まかなことですが、基本的な考え方は次のとおりです。

import { createStore, createActionPack, combineActionPacks } from 'redux/starter'

const counter = createActionPack({
  increment: counter => counter + 1,
  decrement: counter => counter - 1,
  set: (_, value) => value
}, 0)

const posts = createActionPack({
  load: async () => await fetch('/posts'),
  create: async (state, text) => state.push(await fetch('/posts/new', { body: { text } }))
}, [])

const store = createStore(
  combineActionPacks(
    counter,
    posts
  )
)

store.dispatch(counter.increment())
store.dispatch(counter.set(42))

await store.dispatch(posts.load())
await store.dispatch(posts.create('First!'))

シングルトンを保存する

これは決して売られていませんが、ReactRouterでシングルトンの歴史があった時代を思い出しました。 完璧ではありませんでしたが、ある程度の価値がありました。

import { store, configureStore } from 'redux/starter'

configureStore(reducer, middleware, initialState)

store.dispatch(someAction())
store.getState()

import構成可能性

私は最後に私の最も奇抜なものを保存します。 しかし、ファイルをインポートして構成を許可した場合はどうなるでしょうか。 グローバルパスの舞台裏が必要になるため、面倒で面倒になります。 しかし、繰り返しになりますが、焦点は私たちの側ではなく、ユーザーにあります。

import { createStore } from 'redux/starter'
import 'redux/starter/devtools'
import 'redux/starter/logger'
import 'redux/starter/immutable'

// OR!

import { createStore } from 'redux/starter/developer'
import { createStore } from 'redux/starter/production'

その2番目の例では、ユーザーがビルドツールでそのパッケージにエイリアシングするか、Reactのようなことをしているのを見ることができます。

OK、今のところ私からは以上です。 繰り返しになりますが、私はユーザーファーストで考えたいと思います。 これを実装するために私たちがしなければならない汚い、醜いハックが何であれ、関係ありません。 重要なのは、記述されたコードが少なく、必要な構成が少ない優れたDXです。

これまでのところ、これらのアイデアが大好きです。 これが判明した場合の私の唯一の願いは、下位レベルの標準ReduxAPIへの優雅なアクセスです。 人々がカスタマイズしたり、排出したりするための自然な道が必要です。 それが数日であろうと、1年か2年であろうと、それは単純なはずです。 ロックインは私が目にする問題の1つです（Jumpstateを使用した私自身の試み、およびRematchなどの最近のライブラリから）。 私たちがそれを避けることができればするほど、人々は口の中でより良い味を感じるでしょう:)

ええ、私はその「アクションパック」のようなことをするかなりの数のutil libsを見てきました（少なくとも「いくつかのレデューサーを書いて、キーをアクションタイプとアクションクリエーターに変える」側面まで）、そして私は投げることを考えていましたそれは追加のアイテムとして-まだそこに到達していませんでした。 「combineActionPack」の側面についてはよくわかりません。

昨夜、 @ hswolffと追加の話し合いがありセレクターライブラリを追加/再エクスポートすることを検討したいと思います。これは、Reselect APIのスーパーセットであり、いくつかの追加の便利な利点があるようです。

import createSelector from 'selectorator';

// selector created with single method call
const getBarBaz = createSelector(['foo.bar', 'baz'], (bar, baz) => {
  return `${bar} ${baz}`;
});

これは、 const selectTodos = state => state.todosような手書きの「単純な入力」セレクターの多くを削減するのに役立ちます。

セレクターライブラリを追加するメリットがわかるかどうかはわかりません。 それによって可能になる状態の形についても意見を述べる必要があります。

これは少なくとも部分的には、ユーザーがpackage.jsonにインストールする必要のあるアイテムが1つ少なくなるためです。

セレクターライブラリは素晴らしいと思います。

関連性もあります： apollo-boostスターターキットに関する最近の記事

mapStateToPropsがArray場合に、 react-reduxのconnectのAPIを拡張して、再選択（または同様のセレクターライブラリ）を使用できる場合は、セレクターの使用を奨励し、互換性を損なうことなく非常に便利にします。 このライブラリをReactまたはreact-redux必ずしも組み合わせる必要はないと思いますが、 react-reduxオプションを使用してその拡張性を処理するか、スターターキットをreact-reduxでラップする別のパッケージを提供することができます。

ええ、私はこの最初のMVPのためにReact-Reduxで何もするつもりはありません。

その場合、Reduxレベルでセレクターの抽象化を追加する良い方法がありますか、それともこれはreact-reduxの上でのみ効果的に行うことができるものですか？ 問題は、これがreact-reduxと互換性がないことを望まないことです。したがって、それが不可能な場合は、今のところセレクターを捨てるべきだと思います。

ストアAPIを実装している限り、react-reduxと互換性があります。 そのAPIを壊すつもりはなく、DXを改善するだけです。

それは理にかなっている。 私はreact-redux以外でセレクターを使用したことがないので、ここでRedux自体を構成するのにそれらが適用できるかどうか疑問に思いました。

@timdorr +1は、より簡単なレデューサー/アクションのペアで表現された欲求に基づいています。 また、reducer、アクションクリエーター、セレクターの作成がはるかに快適で使いやすいように、reduxモジュール（別名アヒルパターン）を簡単に作成できる方法を紹介したいと思います。

大多数の人を幸せにするその問題の解決策を見つけるには、もう少し自転車を落とす必要があると思います。それが最初のブロックをブロックしないように、フォローアップバージョンに追加できるものかどうか疑問に思います。リリース。

@markeriksonが彼のコメントで作成したものは、すでにかなりの定型文を減らしており、素晴らしい初期プレリリース

その後、面倒なReduxの他の側面（redux /アクション/セレクターの作成）に取り組むことができます。

すべての問題を前もって解決しようとすると、何らかの形で具体的な進歩を遂げる妨げになると思います。

十分な準備ができていると思われる場合は、リポジトリを開始して、サンプルコードとドッグフードを使用してこのセットアップをテストできるようにすることをお勧めします（または、monorepoの機能ブランチのパッケージである可能性があります。 PRを通じて協力する）。

もちろん。 今日は少し後で何かをセットアップできるかどうかを確認します。

別のリポジトリは必要ありません。 これは現在のものの中に存在します。 まずは何でもPRしてください。

これを個別のインポートとしてメインのreduxパッケージの一部にする必要がありますか（したがって、これは完全に下位互換性があります）、複数のパッケージを含むモノリポジトリを使用しますか？ 前者で十分だと思います。大きくなりすぎた場合は、新しいパッケージを作成せずに、いつでも別のファイルエクスポートを使用できます。

そもそも、これを別のレポ/パッケージとして試してみたいと思います。

将来的にマージするとエラーが発生しやすくなる可能性があるため、このリポジトリで既存のツール設定を使用する方が簡単な場合があります。 また、このReactを特定していないため、別の構文サポートはおそらく必要ありません。

事前に構成された単一のファイルになる場合は、ここに保持するのが最も簡単です。 依存関係があるため、別のパッケージにする必要があります。 既存のアプリをそれらでサドルしたくありません。

繰り返しになりますが、monorepoに移行する必要はないと思いますが、複数のビルドを開始する場合は、特定のパッケージビルド用のフォルダーを作成できます。 今のところ、独自のpackage.jsonを備えたstarterフォルダーだけでうまくいくはずです。

それ自体をreduxするためにローカルのコードのみを使用している場合、これをメインのreduxパッケージに対してローカルに保つというアイデアが好きです。 ここで表現されたアイデアをサポートするために外部の依存関係を取り入れ始めると、私はもっと躊躇します。

immer、thunk / promise / saga、reselectなどの外部依存関係は、ここでの目標にとって非常に貴重であり、スターターの追加の依存関係に値すると思いますが、メインのreduxパッケージ自体への依存関係は必要ない場合があります。 。

だから、ええと...私は行って何かをしました：

• https://github.com/markerikson/redux-starter-kit
• https://www.npmjs.com/package/@acemarke/redux -starter-kit
• https://unpkg.com/@acemarke/redux [email protected]/

前のスニペットとは異なる点：

• enhancers設定オプションを投入しました。
• 私は追加selectorator依存性を、エクスポートcreateSelector

考え？

過去数週間で自分自身にRedux（およびReact）を教えたばかりの人として、私は最終製品を見るのが待ちきれません。 コードでクリーンアップするものがたくさんあると確信しています。

😏👍

したがって、長いアイデアはreduxの使用を単純化することであるため、2つの瞬間を提案できます。

1. 文字通りexpect(mapStateToProps(state)).toEqual(mapStateToProps(state))に組み込み関数を追加します。 より良いコードを作成するように人々を促すためだけに。 私はこのようなテストを見たことがありませんが、_not-very-pure_mapStateToPropsはreduxの問題の1つです。

2. memoize-stateのような採用を検討してください。 セレクター用のImmer.jsのようなものです。 重要なポイント-顧客は、mapStateToPropsまたはセレクターを好みの形式で記述して、メモ化することができます。 インスタンス間の「共通の」メモ化を失うことなく、「複数のコンポーネントインスタンス間で小道具を使用してセレクターを共有する」でこの再選択の問題を解決することもできます。 ものを二重にメモするだけです

1. 純粋なセレクターを推奨するという意味ではわかりますが、不純なべき等セレクターはそのテストに合格する可能性があります。 私は2番目の提案がもっと好きです。
2. かっこいいと思うので、イマー用のレデューサーをラップするのと同じ方法でセレクターをラップしますよね？

それでも、上で説明したように、これは、Reactにとらわれないスターターパッケージに含まれるものというよりも、react-reduxのことです。

これは本当にクールです！

ただし、1つのリクエスト/少しのフィードバックがあります。 Immerが暗黙的に使用されていない方がいいです。

イマーは素晴らしいです。 それは私のお気に入りのユーティリティの1つになりました。 しかし、それを明示的に使用する場合でも（ produce(baseState, draftState => ... ）、それをよく知らない他の人が私のコードを見るときは心配で、Immerの超能力のためにこの変異的なものしかできないことに気づいていません。

APIの現在の外観では、redux状態が不変であるべきだと気付いていない新規参入者を想像することができます。 このスターターキットなしでReduxを使おうとすると、誤解が激しく噛み付くと思います。

createNextStateはすでにエクスポートされているので、ユーザーに明示的に使用するように勧めてはどうでしょうか。

import {createReducer, createNextState} from "@acemarke/redux-starter-kit";

function addTodo(state, newTodo) {
    return createNextState(state, draftState => {
        draftState.push({...newTodo, completed : false});
    });
}

（ createNextStateがどのように使用されるのかを誤解した場合は、お詫びします！まったく掘り下げていません）

https://github.com/markerikson/redux-starter-kit/issues/5を参照して

APIの現在の外観では、redux状態が不変であるべきだと気付いていない新規参入者を想像することができます。 このスターターキットなしでReduxを使おうとすると、誤解が激しく噛み付くと思います。

私の意見では、 https：//github.com/reactjs/redux/issues/2858があるため、このパッケージが完成したら、Reduxを直接使用しないことをお勧めし

createNextStateはすでにエクスポートされているので、ユーザーに明示的に使用するように勧めてはどうでしょうか。

悪い考えではありませんが、特にソースコードを生成しておらず、immerの追加に下位互換性があるため、ここで暗黙的に使用する方が有利だと思います。

私は多くの人が使用することを推奨参照libsのようにimmer.js私の愚見から知らず知らずのうちに学び、尊重のモチベーション逸脱することからなる、 store要件を。

ストアを変更できないことは誰もが知っているので、 newStateインスタンスを（ === ）に対してpreviousStateに対してチェックする検証メカニズムが必要です。同じインスタンスの場合はエラーをスローします。

このようにして、誰もがstoreのルールと要件を学ぶように強制されます。

PS：私はimmerの利点を本当に理解しており、それに反対することはまったくありませんが、人々が最終的に概念を理解するようになり、それは大きな混乱の原因となり、技術的には次のように述べています。ベンチマークを行うと、ライブラリを緩めるためだけに複雑さの層を追加するだけです。

個人的な提案：

logger 、 devTools 、 Thunkは、 Starterデフォルトとして追加する必要がありますが、残りは個人的な選択だと思います。

ストアを変更できないことは誰もが知っているので、newStateインスタンスをpreviousState（===）と照合し、同じインスタンスの場合はエラーをスローする検証メカニズムが必要です。

アクションによっては、状態を変更したくない場合があるため、同じストアインスタンスを返してメモリを節約し、誤検知の差分を防ぎます。 この問題を回避したとしても、Reduxはコアにバリデーターを必要としないようであり、Immerは個人的にはこれに対する大丈夫な保護手段だと思います。 Reduxを学ぶという目的をある程度損なうことには同意しますが、純粋なFPを学びたくない、または気づいていない多くの開発者がReduxを学んでいるのを目にします。

ベンチマークを行うと、ライブラリを緩めるためだけに複雑さの層を追加するだけです。

私の知る限り、Immerの実装方法では、プロキシが実際に変更されている場合にのみパフォーマンスオーバーヘッドが発生するため、通常の不変の更新リデューサーにパフォーマンスオーバーヘッドが発生することはありません。 これは大丈夫だと思います。

スターターのデフォルトとしてロガー、devTools、Thunkを追加する必要がありますが、残りは個人的な選択だと思います。

削除することを検討したいことが他にもいくつかあります（個人的には、パフォーマンスのオーバーヘッドを補う開発者ツールよりもロガーに大きな利点はありませんが）、 https：//github.com/markerikson/を参照して

アクションによっては、状態を変更したくない場合があるため、同じストアインスタンスを返してメモリを節約し、誤検知の差分を防ぎます。 この問題を回避したとしても、Reduxはコアにバリデーターを必要としないようであり、Immerは個人的にはこれに対する大丈夫な保護手段だと思います。 Reduxを学ぶという目的をある程度損なうことには同意しますが、純粋なFPを学びたくない、または気づいていない多くの開発者がReduxを学んでいるのを目にします。

@nickmccurdy私はあなたの見解を完全に理解しています、そして私はFP、突然変異などのいくつかの概念のために学習の障害があってはならないことに同意します...しかし教育者として私は見習いを砂糖でコーティングしないことを強く信じていますそれらから複雑さを隠します。 とにかく、それは好みの問題です。私はプロの学習と前向きであり、この提案を見ると、私の本能は、私たちが受け入れて前進するが、標準で後退するだろうとどういうわけか私に教えてくれます。 念のために言っておきますが、現在Redux Standardsを教えているウェブ上のすべてのコンテンツと、それが最終的にどのように採用されているかを考えてみてください。

私の知る限り、Immerの実装方法では、プロキシが実際に変更されている場合にのみパフォーマンスオーバーヘッドが発生するため、通常の不変の更新リデューサーにパフォーマンスオーバーヘッドが発生することはありません。 これは大丈夫だと思います。

複雑さの層を追加するということは、 Immerが一度も存在したことがなく、おそらく存在する可能性があることを意味します。ライブラリでサポートし、テストし、パフォーマンスの問題を評価し、最後に重要なことです。ここのこのセクションは、私を不安にさせます：

Immer.js-自動フリーズ
Immerは、produceを使用して変更された状態ツリーを自動的にフリーズします。 これにより、プロデューサーの外部で状態ツリーが誤って変更されるのを防ぐことができます。 これにはパフォーマンスへの影響があるため、本番環境ではこのオプションを無効にすることをお勧めします。 デフォルトで有効になっています。 デフォルトでは、ローカル開発中にオンになり、本番環境ではオフになります。 setAutoFreeze（true / false）を使用して、この機能を明示的にオンまたはオフにします。

そして突然、 Development / Prod追加された機能もサポートする必要があります。 かなりの量の作業であり、トレードオフがあまりないので心配ですが、これも私の個人的な意見です。

@codedavinci ：このredux-starter-kitライブラリのポイントは、「基本的な」Reduxストアのセットアッププロセスに便利なツールと抽象化を追加することです。 また、これはReduxコア自体に入るのではなく、最終的にRedux組織の「公式」部分にしたいと考えている別のライブラリに入ることに注意してください。

既存のReduxコードはすべて機能します。 既存のチュートリアルはすべて問題ありません。 Reduxをセットアップして使用するために、公式にサポートされているより簡単なアプローチを追加しようとしています。

@markeriksonスターターキットを満足しています。ライブラリの概念を変更するImmer.jsようなライブラリを用意することに少し抵抗があり、最終的には人々がstarter-kitパターンであり、コアコンセプトを完全に無視します。 店舗の突然変異はモットーではありません。Reduxは常にそれを販売しており、ブランドの一部です。

PS： Immer.jsは何も変更しないことを完全に理解していますが、変更しないように支援します。私はpush 、 spliceなどの構文上の標準について話しているだけです。 ..。。

たぶん、それは私自身が変化に抵抗しているだけです:)

@codedavinci ：ええ、私は懸念のポイントを理解しています。 それでも、Reduxに関する一般的な不満の1つは、適切な不変の更新コードを書くことの苦痛であり、Immerは、これらの更新を簡素化するために私が見た中で最高のライブラリです。

@markerikson 、私は実際にimmerを掘り下げてみましたが、非常に軽く、シンプルで効率的であることに気づきました。 私は実際に売られています:)。

どのリポジトリを作成していますか？ それらの：

https://github.com/markerikson/redux-starter-kit
https://www.npmjs.com/package/@acemarke/redux -starter-kit
https://unpkg.com/@acemarke/redux [email protected]/

うん、それだけです。

@nickmccurdyには、主にツールに関する議論と合併を待っているPRがたくさんありますが、プロジェクトをより長期的にどのように集中させたいかについての議論もあります。 私はそれらを見て回る必要がありますが、ここ数週間は他のもので忙しかったです（明日行う会議の話を含む）。

大きな進歩@ nickmccurdy ＆ @markerikson👍私はそれのシンプルさと効果が大好きです。 @nickmccurdyは、あなたがプロジェクトに非常に積極的に

確かに、新しい号でオープンディスカッションを開始するのがおそらく最善ですが、 nick @ nickmccurdy.comまたはDiscordから直接私に連絡することができます。

combineReducersを分割するための+1。 一番長く使っていたのですが、店の運営についてはあまり深く考えていなかったからです。

私は現在、次のようにレデューサー機能を設定するのが好きです。

function reducer(prevState, event, handledNavigation = false) {
  if (event.type === 'NAVIGATION' && !handledNavigation) {
    return reducer(onNavigate(prevState, event), event, true);
  }

  const pageReducer = pageReducers[prevState.activePage];

  const nextSessionState = sessionReducer(prevState.sessionState, event);
  const nextPageState = pageReducer(prevState.pageState, nextSessionState, event);

  return {
    activePage: prevState.activePage,
    pageState: nextPageState,
    sessionState: nextSessionState,
  };
}

これはcombineReducersでは実際にはできません。

@ abradley2 ：あなたが求めているのであれば、ReduxコアからcombineReducersを削除する予定はありません。 しかし、はい、私たちは常にcombineReducersが最も一般的なユースケースのユーティリティであり、自分の状況に合わせてカスタムレデューサーロジックを作成することをお勧めします。

redux-starter-kitパッケージ名があり、リポジトリはhttps://github.com/reduxjs/redux-starter-kitの組織に移動されました。 このスレッドを閉じます。 それ以上の議論は、そのレポで行われる可能性があります。

また、デフォルトでミューテーションと直列化可能性のチェックを追加する作業を始めています。