Redux: आरएफसी: रेडक्स स्टार्टर किट

हाँ हाँ हाँ! मेरे पास इसके लिए कई राय और शुभकामनाएं हैं! लेकिन मैं खुद को संयमित रखूंगा और पहले चर्चा को आगे बढ़ने दूंगा।

एक इच्छा सूची आइटम जो मेरे पास होगा वह मुझे यकीन नहीं है कि संभव है अंतर्निहित एचएमआर रेड्यूसर के लिए स्वचालित रूप से createReduxStore() फ़ंक्शन में जोड़ा जाता है। दुर्भाग्य से, वेबपैक के बारे में मेरा ज्ञान और कुछ प्रयोग कहते हैं कि यह बहुत संभव नहीं है, क्योंकि आपके पास वेबपैक module.hot.accept() कॉलबैक में फ़ाइलों को कम करने के लिए हार्डकोडेड पथ होना चाहिए। सुनिश्चित नहीं है कि पार्सल या अन्य बंडलर इसे कैसे संभालते हैं।

इसलिए, सभी से प्रतिक्रिया के लिए प्रारंभिक अनुरोध:

• इस पैकेज से हम किन प्रमुख आवश्यकताओं को पूरा करना चाहेंगे?
• उन आवश्यकताओं को पूरा करने में सहायता के लिए आप कौन से _मौजूदा_ पैकेज सुझाएंगे?
• अंतिम उपयोगकर्ता के लिए चीजों को सरल रखने के लिए हम उन पैकेजों को सर्वोत्तम तरीके से कैसे जोड़ सकते हैं?

आइए 3 प्रमुख बिंदुओं को नाम दें, जहां संभावित रूप एक दूसरे से _isolated_ होंगे।

1. पहला बिंदु। रेड्यूसर प्रबंधक
   1.0 वेनिला (यह यहाँ मामला है?)
   १.१ इमर.जेएस
   १.२ कोर्डक्स
   १.३ १००५०० अधिक पैकेज

2. दूसरा बिंदु। मिडलवेयर्स
   2.0 वेनिला (क्या यह मामला है?)
   २.१ साग
   २.२ महाकाव्य
   2.3 100500 अधिक पैकेज।

3. तीसरा बिंदु। प्रतिक्रिया एकीकरण
   3.0. वेनिला (यह यहाँ मामला है?)
   ३.१. उपस्पेस
   ३.२ पुनर्विक्रय
   3.3 100500 अधिक पैकेज।

चौथा, बोनस, बिंदु
४.० एक _बॉयलरप्लेट_ में इन सभी चीजों का परीक्षण करना।

"चुने हुए लोगों" को चुनना असंभव है, उदाहरण के लिए मैं साग और महाकाव्य दोनों को प्यार करता हूं और उनका उपयोग करता हूं, लेकिन कुछ "खाना पकाने की रसीदें" और संयोजनों के लिए सिफारिशें प्रदान करना संभव है।

उदाहरण के लिए अधिकांश रेडक्स उपयोगकर्ता मिडलवेयर के बारे में __only__ जानते हैं। एक छोटा सा हिस्सा भी रेड्यूसर के साथ कुछ कर रहा है (ठीक है _heard_ अपरिवर्तनीय.जेएस के बारे में), बस कुछ ही रिएक्ट एकीकरण को बढ़ाते हैं।

स्टार्टर किट शुरुआत से ही पूर्ण और _rich_ दृष्टिकोण बनाने में मदद कर सकता है। या किसी को और अधिक चाहिए कि एक स्टार्टर किट।

ट्विटर पर सेटअप/बॉयलरप्लेट दर्द बिंदुओं पर प्रतिक्रिया मांगी: https://twitter.com/acemarke/status/969040835508604929

ट्विटर पर मेरी प्रतिक्रिया की प्रतिलिपि बनाना:

मैं स्पष्ट रूप से रेडक्स बॉयलरप्लेट को आईएमओ के रूप में जोड़ने से दूर रहा हूं, यह किसी अन्य व्यक्ति को रेडक्स करने का 'अपना तरीका' पेश करते समय जटिलता जोड़ता है। मैं रेडक्स को अधिक पोर्टेबल कौशल बनाने के लिए कोड के माध्यम से लागू किए गए अधिक अनुवांशिक सम्मेलनों को पसंद करूंगा।

उस अंत तक, create-redux-app स्टाइल रेपो - हालांकि एक ढांचे की तुलना में एक पुस्तकालय के रूप में अधिक डिज़ाइन किया गया है - विशेष रूप से सर्वोत्तम और अनुशंसित प्रथाओं के Redux अनुरक्षकों द्वारा स्पष्ट रूप से समर्थन किया गया है, मुझे लगता है कि स्पष्टता को मजबूत करने और जोड़ने के लिए एक लंबा रास्ता तय करना होगा उचित Redux उपयोग पर।

हम रिएक्टिफ्लक्स पर इसके बारे में थोड़ी बात कर रहे हैं, इस धागे में शामिल करने के लिए इच्छाओं के समेकन पर प्रतिलिपि बनाना चाहते हैं, इनमें से कुछ उन बिंदुओं के साथ ओवरलैप होते हैं जिन्हें आपने पहले ही सूचीबद्ध किया है @timdorr (इसलिए यह एक उत्साही पुष्टि है)।

1. बेहतर डिफॉल्ट के साथ createStore के चारों ओर रैपर, यानी मिडलवेयर जोड़ने का आसान तरीका, redux dev tools
2. अपरिवर्तनीय सहायक में निर्मित (इमर?)
3. createReducer में निर्मित (मानक "reducer लुकअप टेबल" उपयोगिता)
4. बिल्ट-इन को फिर से चुनें
5. एक्शन क्रिएटर जो एफएसए का पालन करता है
6. async एक्शन सपोर्ट / साइड इफेक्ट सपोर्ट (फ्लक्स, सागा, व्हाट?)

आधिकारिक तौर पर हेनरिक जोरेटेग के रेडक्स-बंडलर की तरह पहले से मौजूद किसी चीज़ का समर्थन क्यों नहीं किया जाता है?

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

यह संक्षिप्त है, राय है (अच्छे तरीके से), अनुप्रयोगों में redux-संबंधित कार्यक्षमता के पुन: उपयोग की अनुमति देता है और अभी भी async हैंडलिंग के लिए एक अच्छा समाधान देता है।

यह एक आकर्षक दिखने वाली परियोजना है, और एक जिसे मैं वास्तव में आगे जांचना चाहता हूं, लेकिन इस कार्य के साथ मैं जो करना चाहता हूं उसके दायरे से भी बाहर है।

मैं वास्तव में यहाँ क्या हासिल करना चाहता हूँ:

• कोड की कुछ पंक्तियों और आवश्यक न्यूनतम कॉन्फ़िगरेशन विकल्पों के साथ एक Redux स्टोर की स्थापना करना ("शून्य-कॉन्फ़िगरेशन JS" टैगलाइन वेबपैक और पार्सल के Redux समतुल्य का उपयोग किया गया है)।
• सीआरए के समान, कॉन्फ़िगरेशन सामग्री मूल रूप से छिपी हुई है, बॉक्स के बाहर अच्छे डिफ़ॉल्ट के साथ
• देव अनुभव को बेहतर बनाने के लिए सावधानीपूर्वक चयनित पैकेजों को शामिल करना और हां, "बॉयलरप्लेट को कम करें"। उदाहरण के लिए, इमर एक बढ़िया विकल्प होगा क्योंकि यह अपरिवर्तनीय रेड्यूसर लॉजिक लिखने को बहुत सरल करता है _and_ आपके राज्य को देव में जमा देता है। (मेरी एकमात्र झिझक यह है कि "म्यूटेटिंग" कोड की उपस्थिति भ्रमित करने वाली होगी।)

मैं इस प्रयास को काफी हद तक सीमित रखना चाहता हूं। मैं पिछले कुछ घंटों में रिएक्टिफ्लक्स में @hswolff और @nickmccurdy के साथ चैट कर रहा हूं, और जबकि चर्चा बहुत अच्छी रही है, हम पहले से ही एक दर्जन अतिव्यापी उपयोग के मामलों और विचारों से गुजर चुके हैं जो वास्तव में चीजों को अधिक जटिल कर सकते हैं।

मैं _something_ उपयोगी, मूल्यवान, और व्यवहार्य को बहुत अधिक बाइकशेडिंग के बिना एक साथ रखना चाहता हूं, और उसके बाद अन्य चर्चाएं करना चाहता हूं (जैसे रेडक्स "बंडल" या "मॉड्यूल" बनाने के लिए एक एपीआई)।

एपीआई के कुछ प्रारंभिक बॉयलरप्लेटिंग को बंद करने के लिए यहां मेरी सूची के 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());

मुझे लगता है कि यह एक ठोस शुरुआत है और इस सूत्र में चर्चा की जा रही परिवाद की एक अच्छी शुरुआत है। यह ऊपर वांछित सुविधा की मेरी सूची से अंक

इसके ऊपर इटरेट करना बहुत अच्छा होगा, लेकिन यह एक ठोस आधार है।

कार्यान्वयन पर ध्यान केंद्रित करने के बजाय, मैं चाहता हूं कि हम डीएक्स पर ध्यान दें। निर्यात/एपीआई क्या हैं और उनका उपयोग कैसे किया जाता है? मुझे लगता है कि यह सिर्फ कॉन्फ़िगरेशन से आगे निकलने का एक शानदार मौका है और यह भी देखें कि लोग स्टोर का उपयोग कैसे करते हैं। कुछ यादृच्छिक विचार:

आसान रेड्यूसर/एक्शन जोड़े:

अपने रेड्यूसर और कार्यों को उनके राज्य आउटपुट के साथ जोड़ना बेहद आसान बनाएं। यह मोटा है, लेकिन यहाँ मूल विचार है:

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

स्टोर सिंगलटन

यह मैं किसी भी तरह से नहीं बेचा जाता है, लेकिन मैं उन दिनों के बारे में सोच रहा था जब हमारे पास रिएक्ट राउटर में इतिहास सिंगलेट थे। यह सही नहीं था, लेकिन इसने कुछ मूल्य प्रदान किया।

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'

उस दूसरे उदाहरण के लिए, मैं देख सकता हूं कि उपयोगकर्ता या तो उस पैकेज को उनके बिल्ड टूलिंग में अलियासिंग कर रहे हैं या कुछ ऐसा कर रहे

ठीक है, अभी के लिए बस इतना ही। दोबारा, मैं उपयोगकर्ता-पहले सोचना चाहता हूं। इसे लागू करने के लिए हमें जो भी गंदे, बदसूरत हैक करने पड़ते हैं, वह अप्रासंगिक है। पूरा बिंदु एक महान डीएक्स है जिसमें कम कोड लिखा गया है और कम कॉन्फ़िगरेशन की आवश्यकता है।

इन विचारों को अब तक प्यार करो। जो कुछ भी हो रहा है उसके लिए मेरी एकमात्र इच्छा निचले स्तर, मानक रेडक्स एपीआई तक सुंदर पहुंच होगी। लोगों को अनुकूलित या बेदखल करने के लिए एक प्राकृतिक मार्ग होने की आवश्यकता है। चाहे वह कुछ दिनों में हो, या एक या दो साल में, यह सरल होना चाहिए। लॉक-इन उन समस्याओं में से एक है जो मैं देखता हूं (जम्पस्टेट के साथ इस पर अपने स्वयं के प्रयास से और रीमैच जैसे हालिया पुस्तकालयों से)। जितना अधिक हम इससे बच सकते हैं, लोगों के मुंह में उतना ही बेहतर स्वाद होगा :)

हाँ, मैंने कुछ उपयोग के काम देखे हैं जो उस "एक्शन पैक" की तरह सामान करते हैं (कम से कम जहाँ तक "कुछ रेड्यूसर लिखें, कुंजियों को एक्शन टाइप और एक्शन क्रिएटर्स में बदल दें" पहलू), और मैं फेंकने पर विचार कर रहा था कि एक अतिरिक्त वस्तु के रूप में - अभी तक वहां नहीं पहुंचा था। "कॉम्बिनेशनपैक" पहलू के बारे में निश्चित नहीं है।

कल रात @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 स्टार्टर किट पर हाल का लेख

यदि हम react-redux के connect के एपीआई को रीसेलेक्ट (या एक समान चयनकर्ता पुस्तकालय) का उपयोग करने के लिए बढ़ा सकते हैं, जब mapStateToProps एक Array , तो हम कर सकते हैं चयनकर्ताओं के उपयोग को प्रोत्साहित करें और अनुकूलता को तोड़े बिना इसे बहुत सुविधाजनक बनाएं। मुझे नहीं लगता कि इस पुस्तकालय को रिएक्ट या react-redux के साथ जोड़ा जाना चाहिए, लेकिन हो सकता है कि हम react-redux विकल्प के माध्यम से उस विस्तारशीलता को संभाल सकें या स्टार्टर किट को react-redux साथ लपेटकर एक और पैकेज प्रदान कर सकें

हाँ, मैं इस प्रारंभिक एमवीपी के लिए रिएक्ट-रेडक्स के साथ कुछ भी नहीं करना चाहता हूं।

उस मामले में Redux स्तर पर चयनकर्ताओं के लिए एक अमूर्त जोड़ने का एक अच्छा तरीका है या यह कुछ ऐसा है जिसे हम केवल प्रतिक्रिया-रेडक्स के शीर्ष पर ही प्रभावी ढंग से कर सकते हैं? समस्या यह है कि हम नहीं चाहते कि यह प्रतिक्रिया-रेडक्स के साथ असंगत हो, इसलिए मुझे लगता है कि यदि यह संभव नहीं है तो हमें अभी चयनकर्ताओं को छोड़ देना चाहिए।

जब तक यह स्टोर एपीआई को लागू करता है, तब तक यह प्रतिक्रिया-रेडक्स के साथ संगत है। हम उस एपीआई को तोड़ने की तलाश नहीं कर रहे हैं, बस डीएक्स में सुधार करें।

यह समझ आता है। मैंने प्रतिक्रिया-रेडक्स के बाहर चयनकर्ताओं का उपयोग नहीं किया है, इसलिए मैं सोच रहा था कि क्या वे यहां रेडक्स को कॉन्फ़िगर करने के लिए लागू होंगे।

आसान रेड्यूसर /एक्शन जोड़े के साथ व्यक्त की गई इच्छा पर

मुझे लगता है कि उस समस्या का समाधान ढूंढना जो अधिकांश लोगों को खुश करता है, थोड़ा और बाइक शेडिंग की आवश्यकता होगी और मैं सोच रहा हूं कि क्या यह कुछ ऐसा है जिसे हम फॉलो-अप संस्करण में जोड़ सकते हैं ताकि यह प्रारंभिक को अवरुद्ध न करे रिहाई।

मुझे लगता है कि @markerikson ने अपनी टिप्पणी में जो बनाया है वह पहले से ही बॉयलरप्लेट के एक अच्छे सौदे को कम कर देता है और एक महान प्रारंभिक पूर्व-रिलीज़ के लिए तैयार होगा।

उसके बाद, हम Redux के अन्य पहलुओं से निपट सकते हैं जो बोझिल हैं (redux/क्रिया/चयनकर्ता निर्माण)।

मुझे लगता है कि सभी समस्याओं को सामने से हल करने का प्रयास किसी भी प्रकार की ठोस प्रगति के रास्ते में आने वाला है।

यदि आपको लगता है कि यह पर्याप्त रूप से तैयार है, तो मुझे लगता है कि एक रिपॉजिटरी शुरू करना एक अच्छा विचार होगा, इसलिए हम इस सेटअप को उदाहरण कोड और डॉगफूड के साथ थोड़ा सा (या शायद मोनोरेपो की फीचर शाखा में एक पैकेज, और हम कर सकते हैं) का परीक्षण कर सकते हैं। पीआर के माध्यम से सहयोग करें)।

ज़रूर। मैं देखूंगा कि क्या मुझे आज थोड़ी देर बाद कुछ सेट अप मिल सकता है।

हमें किसी अन्य भंडार की आवश्यकता नहीं है। यह वर्तमान के भीतर मौजूद होगा। कृपया पहले कुछ भी पीआर बनाएं।

क्या यह एक अलग आयात के रूप में मुख्य redux पैकेज का हिस्सा होना चाहिए (इसलिए यह पूरी तरह से संगत है) या क्या आप कई पैकेजों के साथ एक मोनोरेपो पसंद करेंगे? मुझे लगता है कि पूर्व पर्याप्त होगा, हम हमेशा एक नया पैकेज बनाए बिना किसी अन्य फ़ाइल निर्यात का उपयोग कर सकते हैं यदि यह बहुत बड़ा हो जाता है।

मैं वास्तव में इसके साथ शुरू करने के लिए एक अलग रेपो/पैकेज के रूप में इसके साथ खेलना चाहता हूं।

इस रेपो में मौजूदा टूलिंग सेटअप का उपयोग करना आसान हो सकता है क्योंकि भविष्य में इसे वापस मर्ज करने से त्रुटि हो सकती है। हमें शायद अलग-अलग सिंटैक्स समर्थन की भी आवश्यकता नहीं है क्योंकि हम इस प्रतिक्रिया को विशिष्ट नहीं बना रहे हैं।

यदि यह कुछ पूर्व-कॉन्फ़िगरेशन वाली एक एकल फ़ाइल होने जा रही है, तो इसे यहां रखना सबसे आसान होगा। निर्भरताओं के कारण, यह एक अलग पैकेज होना चाहिए। हम उन लोगों के साथ मौजूदा ऐप्स को जोड़ना नहीं चाहते हैं।

दोबारा, मुझे नहीं लगता कि हमें मोनोरेपो जाने की जरूरत है, लेकिन अगर हम एक से अधिक निर्माण शुरू करते हैं तो हमारे पास विशिष्ट पैकेज्ड बिल्ड के लिए एक फ़ोल्डर हो सकता है। अभी के लिए बस एक starter फोल्डर अपने खुद के package.json के साथ चाल चलनी चाहिए।

मुझे इस स्थानीय को मुख्य रेडक्स पैकेज में रखने का विचार पसंद है यदि यह केवल स्थानीय कोड का उपयोग रेडक्स के लिए कर रहा है। अगर हम यहां व्यक्त विचारों का समर्थन करने के लिए बाहरी निर्भरताओं को खींचना शुरू करते हैं तो मुझे और झिझक होती है।

मुझे लगता है कि कुछ बाहरी निर्भरताएं जैसे इमर, थंक/वादा/गाथा, और पुन: चयन यहां हमारे लक्ष्यों के लिए अमूल्य होंगे और स्टार्टर के लिए अतिरिक्त निर्भरताओं के लायक होंगे, हालांकि हम उन निर्भरताओं को मुख्य 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 (और प्रतिक्रिया) सिखाया है, मैं अंतिम उत्पाद को देखने के लिए इंतजार नहीं कर सकता। मुझे यकीन है कि मेरे कोड में साफ करने के लिए मेरे पास एक टन सामान होगा।

मैं

इसलिए, जब तक रेडक्स उपयोग को सरल बनाने का विचार है, मैं 2 क्षण प्रस्तावित कर सकता हूं:

1. बिल्ड-इन फ़ंक्शन को सचमुच expect(mapStateToProps(state)).toEqual(mapStateToProps(state)) । बस लोगों को एक बेहतर कोड बनाने के लिए प्रोत्साहित करने के लिए। मैंने इस तरह के परीक्षण कभी नहीं देखे, लेकिन _not-very-pure_ mapStateToProps redux समस्याओं में से एक है।

2. मेमोइज़-स्टेट जैसे कुछ गोद लेने पर विचार करें। यह चयनकर्ताओं के लिए Immer.js जैसा है। मुख्य बिंदु - ग्राहक केवल अपने पसंदीदा रूप में mapStateToProps या चयनकर्ता लिख ​​सकता है, और इसे याद कर सकता है। यह उदाहरणों के बीच "सामान्य" संस्मरण को खोए बिना "एकाधिक घटक उदाहरणों के साथ चयनकर्ताओं को साझा करना" के साथ इस पुनर्चयन मुद्दे को भी हल कर सकता है। बस सामान को दोबारा याद करें

1. मैं देखता हूं कि शुद्ध चयनकर्ताओं की सिफारिश करने के संदर्भ में आपका क्या मतलब है, लेकिन एक अशुद्ध निष्क्रिय चयनकर्ता अभी भी उस परीक्षा को पास कर सकता है। मुझे दूसरा सुझाव अधिक पसंद है।
2. यह अच्छा लगता है, इसलिए हम चयनकर्ताओं को उसी तरह लपेटेंगे जैसे हम रेड्यूसर को इमर के लिए लपेटेंगे, है ना?

फिर भी, जैसा कि हमने ऊपर चर्चा की, यह एक प्रतिक्रिया-रिडक्स चीज से अधिक है जो स्टार्टर पैकेज में होगी जो कि प्रतिक्रिया के लिए अज्ञेयवादी है।

यह वास्ताव में अच्छा है!

हालांकि, मेरे पास एक अनुरोध/प्रतिक्रिया का बिट है; मैं चाहूंगा कि अगर इमर को निहित रूप से इस्तेमाल नहीं किया गया था।

इमर बढ़िया है । यह मेरी पसंदीदा उपयोगिताओं में से एक बन गया है। लेकिन इसका स्पष्ट रूप से उपयोग करते हुए भी ( produce(baseState, draftState => ... ), मुझे इस बात की चिंता है कि जब अन्य लोग जो इससे परिचित नहीं हैं, वे मेरा कोड देखते हैं, और यह नहीं समझते कि मैं केवल इमर महाशक्तियों के कारण यह परिवर्तनशील सामान कर सकता हूं।

जिस तरह से एपीआई अब दिखता है, मैं कल्पना कर सकता हूं कि नवागंतुक यह महसूस नहीं कर रहे हैं कि रेडक्स राज्य अपरिवर्तनीय होना चाहिए। मुझे लगता है कि जब वे इस स्टार्टर किट के बिना 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 देखें

जिस तरह से एपीआई अब दिखता है, मैं कल्पना कर सकता हूं कि नवागंतुक यह महसूस नहीं कर रहे हैं कि रेडक्स राज्य अपरिवर्तनीय होना चाहिए। मुझे लगता है कि जब वे इस स्टार्टर किट के बिना Redux का उपयोग करने का प्रयास करते हैं तो गलतफहमी उन्हें कड़ी टक्कर देगी।

मेरी राय में, हमें https://github.com/reactjs/redux/issues/2858 के कारण पूर्ण होने पर सीधे इस पैकेज के पक्ष में Redux का उपयोग करने के खिलाफ अनुशंसा करनी चाहिए

मैं देखता हूं कि createNextState पहले से ही एक निर्यात है, तो क्यों न उपयोगकर्ताओं को इसे स्पष्ट रूप से उपयोग करने के लिए प्रोत्साहित किया जाए:

एक बुरा विचार नहीं है, लेकिन मुझे लगता है कि हम यहां निहित होने के पक्ष में हैं, खासकर क्योंकि हम स्रोत कोड नहीं बना रहे हैं और इमर का जोड़ वापस संगत है।

मैं देखता हूं कि बहुत से लोग libs जैसे immer.js का उपयोग करने की अनुशंसा करते हैं, जो मेरी विनम्र राय से अनजाने में सीखने की प्रेरणा को विचलित करने और store आवश्यकताओं का सम्मान करने में शामिल है।

हम सभी जानते हैं कि स्टोर को उत्परिवर्तित newState उदाहरण के खिलाफ जांच करता है ( === ) previousState और यदि यह वही उदाहरण है तो एक त्रुटि फेंक दें।

इस तरह सभी को store के नियमों और आवश्यकताओं को सीखने के लिए बाध्य किया जाएगा।

पुनश्च: मैं वास्तव में immer के लाभ को समझता हूं और मेरे पास इसके खिलाफ कुछ भी नहीं है, लेकिन हम ऐसे समय में पहुंच रहे हैं जहां लोग अंततः अवधारणा को समझ रहे हैं, यह भ्रम का एक बड़ा स्रोत उत्पन्न करेगा, और तकनीकी रूप से कह रहा है, अगर हम इसे बेंचमार्क करते हैं, तो हम पुस्तकालय को ढीला करने के लिए जटिलता की एक अतिरिक्त परत जोड़ने के अलावा कुछ नहीं करेंगे।

व्यक्तिगत सुझाव:

logger , devTools और Thunk को Starter डिफ़ॉल्ट के रूप में जोड़ा जाना चाहिए, बाकी मेरा मानना ​​​​है कि यह एक व्यक्तिगत पसंद है।

हम सभी जानते हैं कि स्टोर को उत्परिवर्तित नहीं किया जा सकता है, इस प्रकार, मेरे पास एक मान्य तंत्र होगा जहां यह पिछले स्टेट ( === ) के खिलाफ न्यूस्टेट इंस्टेंस की जांच करता है और यदि यह वही उदाहरण है तो एक त्रुटि फेंक दें।

ऐसे मामले हैं जहां कार्रवाई के आधार पर आप नहीं चाहते कि राज्य बदल जाए, इसलिए आप स्मृति को बचाने और किसी भी गलत सकारात्मक अंतर को रोकने के लिए उसी स्टोर इंस्टेंस को वापस कर देंगे। यहां तक ​​​​कि अगर हम इस मुद्दे के आसपास हो गए, तो ऐसा लगता है कि Redux कोर में एक सत्यापनकर्ता नहीं चाहता है और मुझे लगता है कि Immer व्यक्तिगत रूप से इसके लिए एक सुरक्षित सुरक्षा है। मैं सहमत हूं कि यह एक हद तक Redux सीखने के उद्देश्य को हराने जैसा है, लेकिन मैं Redux को सीखने वाले बहुत से डेवलपर्स को देखता हूं जो शुद्ध FP सीखना नहीं चाहते हैं या इसके बारे में नहीं जानते हैं।

अगर हम इसे बेंचमार्क करते हैं, तो हम पुस्तकालय को ढीला करने के लिए जटिलता की एक अतिरिक्त परत जोड़ने के अलावा कुछ नहीं करेंगे।

जहां तक ​​​​मुझे पता है, जिस तरह से Immer को लागू किया गया है, प्रॉक्सी में केवल प्रदर्शन ओवरहेड होता है यदि यह वास्तव में उत्परिवर्तित होता है, इसलिए विशिष्ट अपरिवर्तनीय अपडेट रिड्यूसर के पास प्रदर्शन ओवरहेड नहीं होना चाहिए। मुझे लगता है कि यह एक ठीक संतुलन है।

लकड़हारा, देवटूल और थंक को स्टार्टर के डिफ़ॉल्ट के रूप में जोड़ा जाना चाहिए, बाकी मेरा मानना ​​​​है कि यह एक व्यक्तिगत पसंद है।

कुछ अन्य चीजें हैं जिन्हें मैं हटाने पर विचार करना चाहता हूं (हालांकि मुझे व्यक्तिगत रूप से डेवलपर टूल्स पर लॉगर के लिए एक बड़ा लाभ नहीं दिखता है जो इसके प्रदर्शन ओवरहेड के लिए तैयार होता है), https://github.com/markerikson/ देखें redux-स्टार्टर-किट/मुद्दों/19. हालांकि, मैं और चीजों को जोड़ने के खिलाफ नहीं हूं अगर वे वापस संगत हैं जैसे कि इमर और थंक के हमारे वर्तमान उपयोग।

ऐसे मामले हैं जहां कार्रवाई के आधार पर आप नहीं चाहते कि राज्य बदल जाए, इसलिए आप स्मृति को बचाने और किसी भी गलत सकारात्मक अंतर को रोकने के लिए उसी स्टोर इंस्टेंस को वापस कर देंगे। यहां तक ​​​​कि अगर हम इस मुद्दे के आसपास हो गए, तो ऐसा लगता है कि Redux कोर में एक सत्यापनकर्ता नहीं चाहता है और मुझे लगता है कि Immer व्यक्तिगत रूप से इसके लिए एक सुरक्षित सुरक्षा है। मैं सहमत हूं कि यह एक हद तक Redux सीखने के उद्देश्य को हराने जैसा है, लेकिन मैं Redux को सीखने वाले बहुत से डेवलपर्स को देखता हूं जो शुद्ध FP सीखना नहीं चाहते हैं या इसके बारे में नहीं जानते हैं।

@nickmccurdy मैं आपके दृष्टिकोण को पूरी तरह से समझता हूं, और मैं इस बात से सहमत हूं कि एफपी, उत्परिवर्तन और आदि की कुछ अवधारणाओं के कारण हमें सीखने में बाधा नहीं होनी चाहिए ... उनसे जटिलता छिपा रहे हैं। वैसे भी, यह सिर्फ स्वाद की बात है, मैं एक समर्थक सीखने और आगे बढ़ने वाला हूं, और इस प्रस्ताव को देखकर, मेरी प्रवृत्ति किसी तरह मुझे बताती है कि हम स्वीकृति के साथ आगे बढ़ेंगे, लेकिन मानकों के साथ पीछे हटेंगे। बस ध्यान दें, वेब की सभी सामग्री के बारे में सोचें जो अभी Redux मानक सिखा रही है और यह अंततः कैसे उठा रही है।

जहां तक ​​​​मुझे पता है, जिस तरह से Immer को लागू किया गया है, प्रॉक्सी में केवल प्रदर्शन ओवरहेड होता है यदि यह वास्तव में उत्परिवर्तित होता है, इसलिए विशिष्ट अपरिवर्तनीय अपडेट रिड्यूसर के पास प्रदर्शन ओवरहेड नहीं होना चाहिए। मुझे लगता है कि यह एक ठीक संतुलन है।

जब मेरा मतलब जटिलता की एक परत जोड़ने से है, मेरा मतलब है कि Immer कभी नहीं रहा है और अब यह संभवतः हो सकता है, हमें पुस्तकालय में इसका समर्थन करना होगा, इसके खिलाफ परीक्षण करना होगा, प्रदर्शन के मुद्दों का मूल्यांकन करना होगा और अंतिम लेकिन कम से कम नहीं यहाँ यह खंड, मुझे आशंकित करता है:

Immer.js - ऑटो फ्रीजिंग
इमर स्वचालित रूप से किसी भी राज्य के पेड़ को जमा देता है जिसे उपज का उपयोग करके संशोधित किया जाता है। यह एक निर्माता के बाहर राज्य वृक्ष के आकस्मिक संशोधनों से बचाता है। यह एक प्रदर्शन प्रभाव के साथ आता है, इसलिए उत्पादन में इस विकल्प को अक्षम करने की अनुशंसा की जाती है। यह डिफ़ॉल्ट रूप से सक्षम है। डिफ़ॉल्ट रूप से इसे स्थानीय विकास के दौरान चालू किया जाता है, और उत्पादन में बंद कर दिया जाता है। इस सुविधा को स्पष्ट रूप से चालू या बंद करने के लिए setAutoFreeze(true / false) का उपयोग करें।

और अचानक अब हमें Development / Prod में जोड़ी गई सुविधाओं का भी समर्थन करने की आवश्यकता है। यह सिर्फ एक अच्छी मात्रा में काम है और ज्यादा व्यापार करने के लिए चिंताजनक नहीं है, लेकिन फिर से, यह सिर्फ मेरी व्यक्तिगत राय है।

@codedavinci : इस redux-starter-kit लाइब्रेरी का उद्देश्य "मूल" Redux स्टोर सेटअप प्रक्रिया के शीर्ष पर उपयोगी टूल और एब्स्ट्रैक्शन जोड़ना है। साथ ही, ध्यान दें कि यह _not_ Redux कोर में ही जा रहा है, बल्कि एक अलग पुस्तकालय में जा रहा है जिसे हम अंततः Redux org का "आधिकारिक" हिस्सा बनाना चाहते हैं।

आपका सभी मौजूदा Redux कोड काम करेगा। सभी मौजूदा ट्यूटोरियल अभी भी ठीक रहेंगे। हम Redux को स्थापित करने और उपयोग करने के लिए आधिकारिक तौर पर समर्थित सरल दृष्टिकोण जोड़ने का प्रयास कर रहे हैं।

@markerikson मैं स्टार्टर किट रखने के लक्ष्य को समझता हूं और मैं ऊपर वर्णित हर चीज के लिए पूरी तरह से नीचे हूं, पुस्तकालय की अवधारणा को बदलने वाले Immer.js जैसे lib होने का थोड़ा सा प्रतिरोधी, लोग अंततः सीखेंगे 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 के पास

शानदार प्रगति @nickmccurdy & @markerikson 👍 मुझे इसकी सादगी और प्रभावशीलता पसंद है। @nickmccurdy ने देखा कि आप इस परियोजना पर बहुत सक्रिय हैं, मुझे आपके साथ कुछ विचारों के बारे में बातचीत करना अच्छा लगेगा, अगर आप इसके लिए तैयार हैं तो मुझे बताएं! :)

निश्चित रूप से धन्यवाद, एक नए मुद्दे में खुली चर्चा शुरू करना शायद सबसे अच्छा है लेकिन आप सीधे [email protected] या डिस्कॉर्ड पर मुझ तक पहुंच सकते हैं।

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,
  };
}

जो कुछ है CombReducers वास्तव में मुझे ऐसा नहीं करने देता है।

@ abradley2 : यदि आप यही पूछ रहे हैं, तो हम Redux कोर से combineReducers को हटाने की योजना नहीं बना रहे हैं। लेकिन हां, हमने हमेशा कहा है कि combineReducers सबसे आम उपयोग के मामले के लिए एक उपयोगिता है, और आपको अपनी स्थिति के लिए कस्टम रेड्यूसर तर्क लिखने के लिए प्रोत्साहित किया जाता है।

हमें redux-starter-kit पैकेज नाम मिल गया है, और रेपो को https://github.com/reduxjs/redux-starter-kit पर संगठन में स्थानांतरित कर दिया गया है। इस धागे को बंद कर देंगे। उस रेपो में कोई और चर्चा हो सकती है।

साथ ही, मैं डिफ़ॉल्ट रूप से उत्परिवर्तन और क्रमिकता जांच जोड़ने पर काम करना शुरू कर रहा हूं।