ذلك مثير للاهتمام. يسعدني التراجع عن الجزء واختيار جزء من التغيير

سأقول إن ما تبلغ عنه يبدو وكأنه خطأ في TS ، على وجه التحديد:

اكتب '{baseProp: "foobar" ؛ } 'غير قابل للتخصيص لكتابة' جزئي

على ما يرام. ربما لا يعرف TS ما الأمر لأنه لا توجد علاقة بين S و baseProp.

يمكن للمرء أن يمرر S من النوع { baseProp: number } وفي هذه الحالة يكون من الصحيح أنه لا يمكنك تعيين سلسلة إلى baseProp.

ربما إذا مددت S إصدار baseProp؟

لقد جربت شيئًا كهذا من قبل:

interface BaseState_t
{
    baseProp: string
}

export abstract class ComponentBaseClass<P, S extends BaseState_t> extends React.Component<P, S >
{
    foo()
    {
        this.state.baseProp;
        this.setState( { baseProp: 'foobar' } );
    }
}

عندما يكون الوصول على ما يرام ، فإن استدعاء setState به نفس الخطأ:

وسيطة من النوع '{baseProp: "foobar"؛ } 'غير قابل للتخصيص إلى معلمة من النوع' ((prevState: Readonly \ ، props: P) => Pick & Partial \ ) |
} 'غير قابل للتخصيص لكتابة' Pick & Partial \ '.اكتب '{baseProp: "foobar" ؛

ربما لا تكون طريقة جيدة لهيكلة - بعد كل شيء ، يمكن لبعض الفئات الفرعية أن تعلن عن متغيرات الحالة التي تصطدم بمتغيرات في الفئة الأساسية. لذا ، قد يكون من الصواب أن يشتكي من أنه لا يمكن أن يكون متأكدًا مما سيحدث هناك. من الغريب أنه ليس لديه مشكلة في الوصول إلى تلك الدعائم بالرغم من ذلك.

همم. هذا بالتأكيد يبدو وكأنه خطأ في TS الآن.

سوف ألعب بهذا اليوم وربما أخرج الجزئي &.

سأضيف هذا كحالة اختبار أيضًا وأجرّب فكرة أخرى لإسعاد التحسس

أهلا،
نفس المشكلة هنا...

export interface ISomeComponent {
    field1: string;
    field2: string;
}

interface SomeComponentState {
    field: string;
}

export class SomeComponent<
    TProps extends ISomeComponent = ISomeComponent,
    TState extends SomeComponentState = SomeComponentState> extends React.Component<TProps, TState>{

    doSomething() {
        this.setState({ field: 'test' });
    }

    render() {
        return (
            <div onClick={this.doSomething.bind(this)}>
                {this.state.field}
            </div>
        );
    }
}

خطأ في setState:
TS2345 (TS) Argument of type '{ field: "test"; }' is not assignable to parameter of type '((prevState: Readonly<TState>, props: TProps) => Pick<TState, "field"> & Partial<TState>) | (Pick...'. Type '{ field: "test"; }' is not assignable to type 'Pick<TState, "field"> & Partial<TState>'. Type '{ field: "test"; }' is not assignable to type 'Partial<TState>'.

بدأ الخطأ للتو بعد هذا التغيير. في الإصدار 16.0.10 كان يعمل بشكل جيد.

يحتوي الطباعي على العديد من المشكلات ذات الصلة ، وقد أغلقوها على أنها تعمل كما تم تصميمها:

https://github.com/Microsoft/TypeScript/issues/19388

لقد قدمت موجزًا ​​لبعض الأمثلة هنا: https://gist.github.com/afarnsworth-valve/93d1096d1410b0f2efb2c94f86de9c84

على الرغم من أن السلوك لا يزال يبدو غريبا. على وجه الخصوص ، يمكنك التخصيص إلى متغير مكتوب كفئة أساسية بدون إرسال ، ثم إجراء نفس الاستدعاءات مع ذلك بدون مشكلة. يبدو أن هذه المشكلة تشير إلى أن التخصيص والمقارنة شيئان مختلفان.

لم أنساكم يا رفاق. سوف يصلح قريبا

يجب أن يحل العلاقات العامة المشار إليها هذه المشكلة. لقد أضفت أيضًا اختبارات يجب أن تحمي من كسر هذه الحالة الحادة مرة أخرى.

ericanderson شكرا على الرد السريع :)

هل هناك أي قيود / جوانب سلبية للإصلاح الجديد؟

لا شيء أعرفه حاليًا. لقد تمكنت من الحفاظ على التحسس (في الواقع أفضل من ذي قبل ، لأنه يحل بعض الحالات الحادة).

للتوضيح ، كان الحل & Partial<S> هو خداع intellisense للكشف عن المعلمات المحتملة ، لكنها فعلت ذلك بالقول إنها X | undefined . هذا بالطبع سيفشل في التجميع ولكنه كان مربكًا بعض الشيء. يؤدي الحصول على | S إصلاح intellisense بحيث يقترح جميع المعلمات الصحيحة ولا يُظهر الآن نوعًا خاطئًا.

لقد حاولت النظر في إضافة null كقيمة إرجاع محتملة من رد الاتصال setState (ما يمكنك إرجاعه إلى الحالة لا تريد تغيير أي حالة ، دون جعل return; صالح أيضًا) ، ولكن هذا بدلاً من ذلك جعل الاستدلال من النوع يستسلم تمامًا واختر never كمفاتيح 😢

في الوقت الحالي ، في عمليات الاسترجاعات حيث أرغب بالفعل في تخطي حالة التحديث ، كنت أستخدم return null! . النوع never لهذا الإرجاع يجعل TypeScript يتجاهل إرجاع نوع الاستدلال العام.

اهلا ياجماعة...

آخر التزام أصلح مشكلتي.
شكرا على الاستجابة السريعة :)

ما هو الإصدار الذي يحتوي على الإصلاح؟ هل تم نشره حتى npm؟ لقد وصلت إلى الحالة التي يخبرني فيها إصدار رد الاتصال من setState أن هناك عدم تطابق في الخاصية في قيمة الإرجاع ، تمامًا مثل UselessPickles الذي تم العثور عليه.

يجب أن يكون جيدًا في أحدث أنواع @ / رد فعل

لقد أصلحته لسلسلة 15 و 16

import produce from 'immer';

interface IComponentState
{
    numberList: number[];
}

export class HomeComponent extends React.Component<ComponentProps, IComponentState>

تعريف نوع React القديم ..

// We MUST keep setState() as a unified signature because it allows proper checking of the method return type.
// See: https://github.com/DefinitelyTyped/DefinitelyTyped/issues/18365#issuecomment-351013257
// Also, the ` | S` allows intellisense to not be dumbisense
setState<K extends keyof S>(
    state: ((prevState: Readonly<S>, props: P) => (Pick<S, K> | S)) | (Pick<S, K> | S),
    callback?: () => void
): void;

.. ينتج هذا الخطأ:

لقد جربت هذا الاقتراح:

setState<K extends keyof S>(
    state:
        ((prevState: Readonly<S>, props: P) => (Partial<S> & Pick<S, K>))
        | (Partial<S> & Pick<S, K>),
    callback?: () => any
): void;

يمكن أن يشعر Intellisense الآن بالممتلكات من حالة React. ومع ذلك ، يُنظر الآن إلى الخاصية المحسوسة على أنها possibly undefined .

سيتعين عليك استخدام عامل التوكيد الفارغ على الرغم من أن numberList ليست undefined أو nullable:

سأبقى فقط على تعريف النوع القديم حتى يتم تحسين استشعار الكتابة. في هذه الأثناء ، سأذكر صراحة النوع في المعلمة العامة الخاصة بالمنتج الغامر. produce<IComponentState> الأسهل تفسير list! .

خطأك الأول هو أنك لا تعيد أي شيء. هذه ليست الطريقة التي يعمل بها setState.

يعمل حتى عند عدم إرجاع متغير في المنتج. لقد اتبعت للتو المثال هنا (بدون TypeScript):

https://github.com/mweststrate/immer

onBirthDayClick2 = () => {
    this.setState(
        produce(draft => {
            draft.user.age += 1
            // no need to return draft
        })
    )
}

الشيء الوحيد الذي يمنع TypeScript من تشغيل هذا الرمز هو أنه يحتوي على نوع تم استنتاجه بشكل خاطئ من تعريف نوع React. يُبلغ تعريف النوع عن خطأ numberList does not exist on type Pick<IComponentState, never> . فقط قادر على جعل خطأ الترجمة يختفي عن طريق تمرير النوع صراحةً على المعامل العام للمنتج ، على سبيل المثال ، produce<IComponentState> .

حتى أنني حاولت إرجاع المتغير في الإنتاج ومعرفة ما إذا كان سيساعد تعريف نوع React في استنتاج النوع (مشكلة الفرخ والبيض رغم ذلك) ، ولكن لا تزال هناك طريقة لتعريف نوع React لاكتشاف النوع الصحيح للحالة. ومن ثم لا يظهر التحسس الخاص بالمسودة:

أو ربما لدي توقع خاطئ من المترجم :) لا يستطيع المترجم إنشاء نوع لمتغير المسودة بناءً على نوع setState حيث يقوم المترجم بمعالجة الشفرة من الداخل إلى الخارج. ومع ذلك ، فإن تعريف النوع المقترح جعلني أعتقد بطريقة ما أن المترجم يمكنه معالجة الكود من الخارج ، وأنه يمكنه اختيار أفضل نوع يمكنه تمريره من الكود الخارجي ( setState ) إلى الكود الداخلي ( produce ).

setState<K extends keyof S>(
    state:
        ((prevState: Readonly<S>, props: P) => (Partial<S> & Pick<S, K>))
        | (Partial<S> & Pick<S, K>),
    callback?: () => any
): void;

باستخدام تعريف النوع أعلاه ، يمكن للمجمع أن يكتشف أن المسودة لها خاصية numberList . يكتشفها على أنها possibly undefined الرغم من:

بعد إجراء المزيد من التعديلات ، جعلت المترجم قادرًا على تمرير نوع الحالة لإنتاج مسودة عن طريق إضافة S لتعريف نوع setState:

setState<K extends keyof S>(
    state:
        ((prevState: Readonly<S>, props: P) => (Partial<S> & Pick<S, K> & S))
        | (Partial<S> & Pick<S, K>),
    callback?: () => any
): void;

يتم تجميع الكود الآن :)

الخطأ الخاص بك ليس مع setState ، الخطأ الخاص بك داخل المنتج. ما هو تعريف نوع المنتج الخاص بك؟

يوجد خطأ في العلاقات العامة أعلاه في البرنامج النصي للاختبار من نوع DefinitelyTyped ، ولم أختبر محليًا. لذلك أنا أختبرها محليًا الآن.

إليك تعريف نوع immer / product.

/**
 * Immer takes a state, and runs a function against it.
 * That function can freely mutate the state, as it will create copies-on-write.
 * This means that the original state will stay unchanged, and once the function finishes, the modified state is returned.
 *
 * If the first argument is a function, this is interpreted as the recipe, and will create a curried function that will execute the recipe
 * any time it is called with the current state.
 *
 * <strong i="7">@param</strong> currentState - the state to start with
 * <strong i="8">@param</strong> recipe - function that receives a proxy of the current state as first argument and which can be freely modified
 * <strong i="9">@param</strong> initialState - if a curried function is created and this argument was given, it will be used as fallback if the curried function is called with a state of undefined
 * <strong i="10">@returns</strong> The next state: a new state, or the current state if nothing was modified
 */
export default function<S = any>(
    currentState: S,
    recipe: (this: S, draftState: S) => void | S
): S

// curried invocations with default initial state
// 0 additional arguments
export default function<S = any>(
    recipe: (this: S, draftState: S) => void | S,
    initialState: S
): (currentState: S | undefined) => S
// 1 additional argument of type A
export default function<S = any, A = any>(
    recipe: (this: S, draftState: S, a: A) => void | S,
    initialState: S
): (currentState: S | undefined, a: A) => S
// 2 additional arguments of types A and B
export default function<S = any, A = any, B = any>(
    recipe: (this: S, draftState: S, a: A, b: B) => void | S,
    initialState: S
): (currentState: S | undefined, a: A, b: B) => S
// 3 additional arguments of types A, B and C
export default function<S = any, A = any, B = any, C = any>(
    recipe: (this: S, draftState: S, a: A, b: B, c: C) => void | S,
    initialState: S
): (currentState: S | undefined, a: A, b: B, c: C) => S
// any number of additional arguments, but with loss of type safety
// this may be alleviated if "variadic kinds" makes it into Typescript:
// https://github.com/Microsoft/TypeScript/issues/5453
export default function<S = any>(
    recipe: (this: S, draftState: S, ...extraArgs: any[]) => void | S,
    initialState: S
): (currentState: S | undefined, ...extraArgs: any[]) => S

// curried invocations without default initial state
// 0 additional arguments
export default function<S = any>(
    recipe: (this: S, draftState: S) => void | S
): (currentState: S) => S
// 1 additional argument of type A
export default function<S = any, A = any>(
    recipe: (this: S, draftState: S, a: A) => void | S
): (currentState: S, a: A) => S
// 2 additional arguments of types A and B
export default function<S = any, A = any, B = any>(
    recipe: (this: S, draftState: S, a: A, b: B) => void | S
): (currentState: S, a: A, b: B) => S
// 3 additional arguments of types A, B and C
export default function<S = any, A = any, B = any, C = any>(
    recipe: (this: S, draftState: S, a: A, b: B, c: C) => void | S
): (currentState: S, a: A, b: B, c: C) => S
// any number of additional arguments, but with loss of type safety
// this may be alleviated if "variadic kinds" makes it into Typescript:
// https://github.com/Microsoft/TypeScript/issues/5453
export default function<S = any>(
    recipe: (this: S, draftState: S, ...extraArgs: any[]) => void | S
): (currentState: S, ...extraArgs: any[]) => S
/**
 * Automatically freezes any state trees generated by immer.
 * This protects against accidental modifications of the state tree outside of an immer function.
 * This comes with a performance impact, so it is recommended to disable this option in production.
 * It is by default enabled.
 */
export function setAutoFreeze(autoFreeze: boolean): void

/**
 * Manually override whether proxies should be used.
 * By default done by using feature detection
 */
export function setUseProxies(useProxies: boolean): void

ericanderson هل يمكنك أن تدلني على المناقشة حول سبب استخدام Pick بدلاً من Partial ؟ لقد تسبب هذا في حزني لساعات (باستخدام setState(obj) ، وليس إصدار رد الاتصال) ، والآن سأستخدم this.setState(newState as State) كحل بديل. أريد فقط أن أفهم سبب تغييره ، لأنني يجب أن أفتقد شيئًا ما.

مرحبًا ericanderson ،

لدي بعض المشاكل مع أحدث تعريف.

حالة الاستخدام الخاصة بي هي باختصار مثل هذا:

interface AppState {
  valueA: string;
  valueB: string;
  // ... something else
} 
export default class App extends React.Component <{}, AppState> {
  onValueAChange (e:React.ChangeEvent<HTMLInputElement>) {
    const newState: Partial<AppState> = {valueA: e.target.value}
    if (this.shouldUpdateValueB()) {
      newState.valueB = e.target.value;
    }
    this.setState(newState); // <-- this leads to a compiling error
  }
  // ... other methods
}

رسالة الخطأ مثل:

Argument of type 'Partial<AppState>' is not assignable to parameter of type 'AppState | ((prevState: Readonly<AppState>, props: {}) => AppState | Pick<AppState, "valueA" | "v...'.
  Type 'Partial<AppState>' is not assignable to type 'Pick<AppState, "valueA" | "valueB" | "somethingElse">'.
    Types of property 'valueA' are incompatible.
      Type 'string | undefined' is not assignable to type 'string'.
        Type 'undefined' is not assignable to type 'string'.

يبدو أن Partial<AppState> غير متوافق مع توقيع setState . بالطبع يمكنني حل هذا عن طريق نوع التأكيد مثل

this.setState(newState as Pick<AppState, 'valueA' | 'valueB'>)

لكنها ليست مثالية لأن:
1) هذا النحو مطول للغاية
2) الأهم من ذلك ، يمكن أن ينتهك تأكيد النوع بياناتي الفعلية. على سبيل المثال ، يجتاز newState as Pick<AppState, 'somethingElse'> الاختبار أيضًا ، على الرغم من أنه لا يتناسب مع بياناتي.

أعتقد أن جزئيةيجب أن يتوافق بطريقة ما مع Pick، منذ جزئيفقط يختار عددًا غير مؤكد من المفاتيح من T. لست متأكدًا من فهمي لما إذا كان دقيقًا. على أي حال ، يجب أن يكون الاستخدام المثالي من وجهة نظري هو أنه يمكنني تمرير المتغير المكتوب جزئيًامباشرة في setState.

هل يمكنك التفضل بالنظر في اقتراحي أو الإشارة إلى سوء فهمي إذا كان هناك؟ شكرا لك!

هذا تغيير قديم حقًا أولاً. لذلك ما لم يغير شخص آخر هذا مؤخرًا ، فمن المحتمل أن تنبح الشجرة الخطأ.

هكذا قال. يسمح الجزئي بقيم غير محددة.

const a: Partial <{foo: string}> = {foo: undefined}

a صالح ولكن من الواضح أن نتيجة هذا التحديث لحالتك تضع حالتك مع foo غير محدد على الرغم من أنك أعلنت أن ذلك مستحيل.

لذلك لا يمكن تخصيص جزء لبيك. والاختيار هو الإجابة الصحيحة للتأكد من أن أنواعك لا تكذب

أشعر أن عدم السماح:

setState((prevState) => {
  if (prevState.xyz) {
    return { foo: "" };
  }
  return { bar: "" };
});

مقيد للغاية.

حلKovensky هو الحل المعقول الوحيد الذي أعرفه ، لكن الكتابة لا تزال مؤلمة.

هل هناك أي شيء يمكن القيام به لدعم هذا النمط الشائع (سأقول)؟

الشيء الوحيد الذي يمكن القيام به هو إزالة أمان الكتابة

هل يمكن لشخص أن يشرح أسباب Pick<S, K> | S | null ؟

        setState<K extends keyof S>(
            state: ((prevState: Readonly<S>, props: Readonly<P>) => (Pick<S, K> | S | null)) | (Pick<S, K> | S | null),
            callback?: () => void
        ): void;

Tbh أنا لا أعرف حتى الآن لماذا يعمل التوقيع أعلاه حتى مع تحديثات الحالة الجزئية حيث يتم تعريف K على أنه keyof S لذا فإن Pick<S, K> يعيد إنشاء S أساسي؟

ألا يجب أن يقوم Partial<S> | null بهذه المهمة أيضًا؟

        setState(
            state: ((prevState: Readonly<S>, props: Readonly<P>) => (Partial<S> | null)) | (Partial<S> | null),
            callback?: () => void
        ): void;

هل يستطيع أحد أن يشرح ...

لقد تم شرح بعض الردود بوضوح.

setState((prevState) => {
  if (prevState.xyz) {
    return { foo: "" };
  }
  return { bar: "" };
});

مقيد للغاية.

حلKovensky هو الحل المعقول الوحيد الذي أعرفه ، لكن الكتابة لا تزال مؤلمة.

لقد واجهت هذه المشكلة بالضبط ، لكن لا يمكنني رؤية أي إشارة إلى Kovensky في سلسلة الرسائل (ربما قام شخص ما بتغيير اسم المستخدم الخاص به؟). هل يمكن لأي شخص أن يوجهني إلى الحل البديل الموصى به حاليًا

@ timrobinson33 هذا التعليق يشرح الحل https://github.com/DefinitelyTyped/DefinitelyTyped/issues/18365#issuecomment -351884578

وهو أمر جيد لا داعي للقلق بشأن هذا بعد الآن باستخدام الخطافات 🙂

@ timrobinson33 هذا التعليق يشرح الحل # 18365 (تعليق)

شكرا جزيلا لذلك. في النهاية ، اعتقدت أن الكود الخاص بي يبدو أجمل حيث أن العديد من مكالمات setState الصغيرة مع بيانات If خارجها ، على الرغم من أن هذا يعني أن بعض المسارات ستستدعي setState أكثر من مرة.

أعتقد أن هذا في الواقع مشابه لكيفية عملنا مع الخطافات ، حيث نرى الحالة كعدة أشياء صغيرة نقوم بتحديثها بشكل مستقل.