Redux: RFC: Redux 스타터 키트

예 예 예! 나는 이것에 대해 많은 의견과 소망을 가지고 있습니다! 그러나 나는 자제하고 토론이 먼저 진행되도록 할 것입니다.

실현 가능성이 확실하지 않은 위시리스트 항목 중 하나는 createReduxStore() 함수에 자동으로 추가되는 감속기용 내장 HMR입니다. 불행히도 Webpack에 대한 지식과 몇 가지 실험에 따르면 Webpack module.hot.accept() 콜백에서 리듀서 파일에 대한 하드코딩된 경로가 있어야 하기 때문에 이것이 실현 가능하지 않다고 합니다. Parcel 또는 다른 번들러가 이를 어떻게 처리하는지 확실하지 않습니다.

따라서 모든 사람의 초기 피드백 요청:

• 이 패키지로 충족시키고 싶은 핵심 요구 사항은 무엇입니까?
• 이러한 요구 사항을 충족하기 위해 어떤 _기존_ 패키지를 제안하시겠습니까?
• 최종 사용자를 위해 일을 단순하게 유지하기 위해 이러한 패키지를 가장 잘 결합할 수 있는 방법은 무엇입니까?

가능한 변형이 서로 _격리_되는 3가지 핵심 포인트를 지정하겠습니다.

1. 첫 번째 요점. 감속기 관리자
   1.0 바닐라(여기가 맞나요?)
   1.1 Immer.js
   1.2 코어덕스
   1.3 100500 더 많은 패키지

2. 두 번째 포인트. 미들웨어
   2.0 바닐라(사실인가요?)
   2.1 사가
   2.2 에픽
   2.3 100500개 이상의 패키지.

3. 세 번째 포인트. 반응 통합
   3.0. 바닐라(여기서 그런가요?)
   3.1. 부분공간
   3.2 재작성
   3.3 100500개 이상의 패키지.

4위, 보너스, 포인트
4.0 _boilerplate_에서 이 모든 것을 테스트합니다.

"선택한 것"을 선택하는 것은 불가능합니다. 예를 들어 저는 사가와 에픽을 모두 좋아하고 사용하지만 일부 "요리 영수증"과 조합에 대한 권장 사항을 제공할

예를 들어 대부분의 redux 사용자는 미들웨어에 대해 __only__ 알고 있습니다. 또한 리듀서로 무언가를 하는 작은 부분(immutable.js에 대해 많이 _들음_), 몇 가지만 React 통합을 향상시킵니다.

스타터 키트는 처음부터 완전하고 _풍부한_ 접근 방식을 구축하는 데 도움이 될 수 있습니다. 또는 하나 이상의 스타터 키트가 필요합니다.

Twitter에서 setup/boilerplate의 문제점에 대한 피드백을 요청했습니다. https://twitter.com/acemarke/status/969040835508604929

트위터에서 내 응답 복사:

나는 다른 사람에게 redux를 수행하는 '당신의 방식'을 도입할 때 복잡성을 더하기 때문에 redux 상용구를 추가하는 것을 명시적으로 피했습니다. redux를 더 이식 가능한 기술로 만들기 위해 코드를 통해 시행되는 더 규범적인 규칙을 원합니다.

이를 위해 create-redux-app 스타일 리포지토리를 갖는 것은 - 그러나 프레임워크보다 라이브러리로 더 많이 설계됨 - 특히 Redux 유지 관리자가 권장하는 모범 사례 및 권장 사례를 명시적으로 보증하는 저장소를 갖는 것은 명확성을 강화하고 추가하는 데 먼 길을 갈 것이라고 생각합니다. 적절한 Redux 사용에.

우리는 Reactiflux에서 이것에 대해 약간 이야기했고 이 스레드에 포함되기를 원하는 통합을 복사하고 싶었습니다. 이 중 일부는 이미 @timdorr에 나열한 요점과 겹칩니다(그래서 열광적인 확인입니다).

1. 더 나은 기본값, 즉 미들웨어, redux 개발 도구를 추가하는 더 쉬운 방법을 사용하여 createStore 주변 래퍼
2. 내장 불변 도우미(immer?)
3. createReducer 내장(표준 "리듀서 조회 테이블" 유틸리티)
4. 내장 재선택
5. FSA를 준수하는 액션 크리에이터
6. 비동기 작업 지원/부작용 지원(플럭스, 사가, 무엇?)

Henrik Joreteg의 redux-bundler와 같이 이미 존재하는 것을 공식적으로 지원하지 않는 이유는 무엇입니까?

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

간결하고 (좋은 방식으로) 독단적이며 애플리케이션 전반에서 redux 관련 기능을 재사용할 수 있으며 여전히 비동기 처리를 위한 훌륭한 솔루션을 제공합니다.

그것은 매혹적으로 보이는 프로젝트이며, 더 자세히 조사하고 싶지만 이 작업으로 내가 하고 싶은 것의 범위를 벗어났습니다.

여기서 내가 정말로 달성하고 싶은 것은 다음과 같습니다.

• 몇 줄의 코드와 필요한 최소한의 구성 선택으로 Redux 저장소 설정("zero-config JS" 태그라인 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};

그리고 필수 예제 할일 앱:

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!'))

싱글톤 저장

이것은 내가 어떤 방식으로든 판매되지는 않지만 React Router에 히스토리 싱글톤이 있었던 시절을 생각하고 있었습니다. 완벽하지는 않았지만 어느 정도 가치를 제공했습니다.

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'

두 번째 예에서는 빌드 도구에서 해당 패키지에 별칭을 지정하거나 React가 하는

좋아, 지금은 그게 나부터야. 다시 말하지만 저는 사용자를 먼저 생각하고 싶습니다. 이것을 구현하기 위해 우리가 해야 하는 더럽고 추악한 핵은 무엇이든 관련이 없습니다. 요점은 작성된 코드가 적고 구성이 덜 필요한 훌륭한 DX입니다.

지금까지 이러한 아이디어를 사랑합니다. 이것이 밝혀진 것이 무엇이든 나의 유일한 소원은 더 낮은 수준의 표준 Redux API에 대한 우아한 액세스입니다. 사람들이 맞춤화하거나 배출할 수 있는 자연스러운 경로가 필요합니다. 그것이 며칠이든 1년이든 2년이든 간에 간단해야 합니다. Lock-in은 내가 본 문제 중 하나입니다(Jumpstate를 사용한 내 자신의 시도와 Rematch와 같은 최신 라이브러리에서). 우리가 그것을 피할 수있을수록 사람들의 입에 더 좋은 맛을 갖게 될 것입니다 :)

예, "액션 팩"과 같은 작업을 수행하는 꽤 많은 유틸리티 라이브러리를 보았고(적어도 "리듀서 작성, 키를 액션 유형 및 액션 생성기로 전환" 측면에서) 던지기를 고려하고 있었습니다. 추가 항목으로 - 아직 거기에 도달하지 못했습니다. "combineActionPack" 측면이 확실하지 않습니다.

어젯밤 @hswolff 와 추가 토론을 선택기 라이브러리를 추가/다시 내보내는 것을 고려하고 싶습니다.

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 에 설치해야 하는 항목이 하나 줄어들기 때문에 적어도 부분적으로 그렇습니다.

선택기 라이브러리가 훌륭할 것이라고 생각합니다.

관련성: apollo-boost 스타터 키트 에 대한 최근 기사

mapStateToProps 가 Array 일 때 reselect (또는 유사한 선택기 라이브러리)를 사용하도록 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. 또한 리듀서, 액션 생성기 및 선택기를 생성하는 것이 훨씬 더 즐겁고 사용하기 쉬운 경험이 되도록 redux 모듈(일명 오리 패턴)을 더 쉽게 생성할 수 있는 방법을 소개하고 싶습니다.

대부분의 사람들을 행복하게 하는 그 문제에 대한 해결책을 찾기 위해서는 조금 더 많은 자전거 이탈이 필요하며 후속 버전에 추가할 수 있는지 궁금합니다. 풀어 주다.

@markerikson 이 그의 코멘트에서 작성한 것은 이미 상용구를 상당히 줄이고 훌륭한 초기 시험판을 만들 수 있을 것이라고 생각합니다.

그 후, 우리는 번거로운 Redux의 다른 측면(redux/action/selector 생성)을 다룰 수 있습니다.

모든 문제를 미리 해결하려고 하면 어떤 형태로든 가시적인 진전을 이루는 데 방해가 될 것이라고 생각합니다.

충분히 준비되었다고 생각되면 저장소를 시작하여 예제 코드로 이 설정을 테스트하고 약간의 dogfood(또는 monorepo의 기능 분기에 있는 패키지를 테스트할 수 있습니다. PR을 통해 협업).

확신하는. 오늘은 조금 있다가 정리할 수 있는지 알아보겠습니다.

다른 저장소가 필요하지 않습니다. 이것은 현재 것 안에 존재할 것입니다. 무엇이든 먼저 홍보하세요.

이것은 별도의 가져오기로 기본 redux 패키지의 일부여야 합니까(완전히 역호환 가능) 아니면 여러 패키지가 있는 단일 저장소를 선호합니까? 전자로 충분하다고 생각합니다. 파일이 너무 커지면 새 패키지를 만들지 않고 항상 다른 파일 내보내기를 사용할 수 있습니다.

나는 이것을 별도의 리포지토리/패키지로 시작하여 실제로 가지고 놀고 싶습니다.

나중에 다시 병합하면 오류가 발생하기 쉬우므로 이 리포지토리에서 기존 도구 설정을 사용하는 것이 더 쉬울 수 있습니다. 또한 이 React를 특정하게 만들지 않기 때문에 다른 구문 지원이 필요하지 않을 수도 있습니다.

사전 구성이 포함된 하나의 단일 파일인 경우 여기에 유지하는 것이 가장 쉽습니다. 종속성 때문에 별도의 패키지여야 합니다. 우리는 기존 앱을 그것들로 채우고 싶지 않습니다.

다시 말하지만, 모노레포로 갈 필요는 없다고 생각하지만 하나 이상의 빌드를 시작하면 특정 패키지 빌드용 폴더를 가질 수 있습니다. 현재로서는 자체 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)) 에 내장 함수를 추가합니다. 사람들이 더 나은 코드를 만들도록 격려하기 위해서입니다. 나는 이런 테스트를 본 적이 없지만 _순수하지 않은_ mapStateToProps는 redux 문제 중 하나입니다.

2. memoize-state 와 같은 채택을 고려하십시오. 선택자를 위한 Immer.js와 같습니다. 요점 - 고객은 선호하는 형식으로 mapStateToProps 또는 선택기를 작성하고 메모화할 수 있습니다. 인스턴스 간의 "공통" 메모를 잃지 않고 "여러 구성 요소 인스턴스에 걸쳐 소품과 선택기 공유"로 이 재선택 문제 를 해결할 수도 있습니다. 내용을 두 번 메모 하십시오.

1. 순수 선택자를 추천한다는 점에서 당신이 의미하는 바를 알지만 순수하지 않은 멱등 선택자는 여전히 그 테스트를 통과할 수 있습니다. 두 번째 제안이 더 마음에 듭니다.
2. 멋있게 들립니다. 그래서 우리는 immer 용 감속기를 래핑하는 것과 같은 방식으로 선택기를 래핑할 것입니다. 맞습니까?

그래도 위에서 논의한 것처럼 이것은 React와 무관한 스타터 패키지에 있는 것보다 react-redux에 가깝습니다.

이것은 정말 멋지다!

하지만 한 가지 요청/피드백이 있습니다. Immer가 암시적으로 사용되지 않았으면 좋겠습니다.

Immer는 훌륭 합니다. 제가 가장 좋아하는 유틸리티 중 하나가 되었습니다. 하지만 명시적으로 사용할 때도( 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 libs 와 같이 store 요구 사항을 존중하는 것으로 구성되어 있습니다.

우리는 모두 저장소를 변경할 수 없다는 것을 알고 있으므로 newState 인스턴스를 previousState 대해 ( === ) 확인하는 유효성 검사 메커니즘을 훨씬 더 선호합니다. 동일한 인스턴스인 경우 오류가 발생합니다.

이런 식으로 모든 사람이 store 의 규칙과 요구 사항을 배우도록 강제됩니다.

추신: 저는 immer 의 이점을 진정으로 이해하고 있으며 그것에 대해 전혀 반대할 것이 없습니다. 그러나 우리는 사람들이 마침내 개념을 이해하는 시점에 도달하고 있습니다. 이는 혼란의 거대한 근원을 생성하고 기술적으로 다음과 같습니다. 벤치마킹하면 라이브러리를 느슨하게 하기 위해 복잡성을 추가하는 것 외에는 아무것도 하지 않을 것입니다.

개인적인 제안:

logger , devTools 및 Thunk 는 Starter 기본값으로 추가되어야 하며 나머지는 개인적인 선택이라고 생각합니다.

우리 모두는 저장소를 변경할 수 없다는 것을 알고 있으므로 newState 인스턴스를 previousState ( === )에 대해 확인하고 동일한 인스턴스인 경우 오류를 발생시키는 유효성 검사 메커니즘을 훨씬 더 선호합니다.

동작에 따라 상태를 변경하지 않으려는 경우가 있으므로 동일한 저장소 인스턴스를 반환하여 메모리를 절약하고 잘못된 긍정 차이를 방지합니다. 이 문제를 해결하더라도 Redux는 핵심 검증자를 원하지 않는 것처럼 보이며 Immer는 개인적으로 이에 대한 괜찮은 보호 장치라고 생각합니다. 나는 그것이 Redux를 배우는 목적을 어느 정도 무너뜨리는 것에 동의하지만 순수한 FP를 배우고 싶지 않거나 인식하지 못하는 Redux를 배우는 많은 개발자를 봅니다.

벤치마킹하면 라이브러리를 느슨하게 하기 위해 복잡성을 추가하는 것 외에는 아무것도 하지 않을 것입니다.

내가 아는 한, Immer가 Proxy를 구현하는 방식은 실제로 변경된 경우에만 성능 오버헤드가 있으므로 일반적인 변경 불가능한 업데이트 리듀서에는 성능 오버헤드가 없어야 합니다. 이 정도면 괜찮은 밸런스라고 생각합니다.

로거, devTools 및 Thunk는 Starter의 기본값으로 추가되어야 하며 나머지는 개인적인 선택에 더 가깝습니다.

제거를 고려하고 싶은 몇 가지 다른 사항이 있습니다(개인적으로 성능 오버헤드를 보완하는 개발자 도구에 비해 로거의 큰 이점을 보지는 못함), https://github.com/markerikson/ 참조 redux-starter-kit/issues/19. 그러나 Immer 및 Thunk의 현재 사용과 같이 다시 호환되는 경우 더 많은 것을 추가하는 것에 반대하지 않습니다.

동작에 따라 상태를 변경하지 않으려는 경우가 있으므로 동일한 저장소 인스턴스를 반환하여 메모리를 절약하고 잘못된 긍정 차이를 방지합니다. 이 문제를 해결하더라도 Redux는 핵심 검증자를 원하지 않는 것처럼 보이며 Immer는 개인적으로 이에 대한 괜찮은 보호 장치라고 생각합니다. 나는 그것이 Redux를 배우는 목적을 어느 정도 무너뜨리는 것에 동의하지만 순수한 FP를 배우고 싶지 않거나 인식하지 못하는 Redux를 배우는 많은 개발자를 봅니다.

@nickmccurdy 나는 당신의 관점을 완전히 이해하고 FP, 돌연변이 등의 일부 개념으로 인해 학습 장애가 없어야한다는 데 동의합니다. 그러나 교육자로서 나는 견습생에게 그들로부터 복잡성을 숨깁니다. 어쨌든, 그것은 단지 취향의 문제입니다. 저는 학습과 진보를 추구하는 프로입니다. 그리고 이 제안을 보고 있는 내 본능은 어떻게든 우리가 수용을 통해 앞으로 나아가지만 표준에 따라 퇴보할 것이라고 말합니다. 참고로 지금 Redux 표준을 가르치는 웹의 모든 콘텐츠와 그것이 마침내 어떻게 채택되고 있는지 생각해 보십시오.

내가 아는 한, Immer가 Proxy를 구현하는 방식은 실제로 변경된 경우에만 성능 오버헤드가 있으므로 일반적인 변경 불가능한 업데이트 리듀서에는 성능 오버헤드가 없어야 합니다. 이 정도면 괜찮은 밸런스라고 생각합니다.

복잡성 계층을 추가한다는 것은 Immer 가 한 번도 없었고 이제 그럴 수 있다는 뜻입니다. 라이브러리에서 이를 지원하고, 테스트하고, 성능 문제를 평가하고, 마지막으로 중요한 것은 여기 이 섹션은 저를 두렵게 만듭니다.

Immer.js - 자동 동결
Immer는 농산물을 사용하여 수정된 모든 상태 트리를 자동으로 동결합니다. 이렇게 하면 생산자 외부에서 상태 트리가 우발적으로 수정되는 것을 방지할 수 있습니다. 이것은 성능에 영향을 미치므로 프로덕션에서는 이 옵션을 비활성화하는 것이 좋습니다. 기본적으로 활성화되어 있습니다. 기본적으로 로컬 개발 중에는 켜져 있고 프로덕션에서는 꺼져 있습니다. 이 기능을 명시적으로 켜거나 끄려면 setAutoFreeze(true / false)를 사용하십시오.

그리고 갑자기 Development / Prod 추가된 기능도 지원해야 합니다. 그것은 단지 좋은 양의 작업이고 많은 것을 교환하지 않는 것에 대한 걱정입니다. 그러나 다시 말하지만 이것은 단지 제 개인적인 의견일 뿐입니다.

@codedavinci : 이 redux-starter-kit 라이브러리의 요점은 "기본" Redux 저장소 설정 프로세스 위에 유용한 도구와 추상화를 추가하는 것입니다. 또한 이것은 Redux 코어 자체로 들어가는 것이 _아닙니다_. 오히려 우리가 결국 Redux 조직의 "공식적인" 일부를 만들고자 하는 별도의 라이브러리로 들어가는 것입니다.

기존의 모든 Redux 코드가 작동합니다. 기존의 모든 튜토리얼은 여전히 ​​괜찮습니다. Redux를 설정하고 사용하기 위해 공식적으로 지원되는 더 간단한 접근 방식을 추가하려고 합니다.

@markerikson 나는 스타터 키트를 갖는 목표를 이해하고 위에서 언급한 모든 것에 대해 완전히 실망했습니다. Immer.js 와 같은 라이브러리를 사용하여 라이브러리의 개념을 바꾸는 것에 약간 저항합니다. 사람들은 결국 배울 것입니다 starter-kit 패턴을 사용하고 핵심 개념을 완전히 무시합니다. 상점 돌연변이가 없다는 것이 모토입니다. Redux는 항상 그것을 판매하고 있으며, 이는 브랜드의 일부입니다.

추신: Immer.js 가 아무 것도 변경하지 않는다는 것을 충분히 이해합니다. 오히려 변경하지 않도록 도와줍니다. 저는 push , splice 와 같이 허용되는 구문 표준에 대해서만 이야기하고 있습니다. ...

아마도, 그것은 나 자신이 변화에 저항하는 것뿐입니다 :)

@codedavinci : 예, 우려의 요점을 이해합니다. 그래도 Redux에 대한 일반적인 불만 중 하나는 적절한 변경 불가능한 업데이트 코드를 작성해야 하는 고통이며 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 는 당신이 프로젝트에 매우 적극적 그것을 원하는지 알려주세요! :)

물론 감사합니다. 새 문제 에서 공개 토론을 시작하는 것이 가장 좋지만 [email protected] 또는 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 의 조직으로 이동되었습니다. 이 스레드를 닫습니다. 해당 리포지토리에서 추가 토론이 발생할 수 있습니다.

또한 기본적으로 돌연변이 및 직렬화 검사를 추가하는 작업을 시작하고 있습니다.