Это интересно. Я счастлив отменить частичное и выбрать часть изменения

Я скажу, что то, что вы сообщаете, звучит как ошибка в 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 (Выбрать & ... '.Введите '{baseProp: "foobar";
} 'не может быть назначен типу' Частичный \ '.

Вероятно, это не лучший способ его структурировать - в конце концов, какой-то дочерний класс может объявлять переменные состояния, которые сталкиваются с переменными базового класса. Так что машинописный текст может быть прав, если жаловаться на то, что он не может быть уверен, что там произойдет. Странно, что у него нет проблем с доступом к этим реквизитам.

Хм. Сейчас это определенно похоже на ошибку в TS.

Я поиграю с этим сегодня и, возможно, вытащу & Partial.

Я добавлю это как тестовый пример и попробую другую идею, чтобы сделать intellisense счастливым.

Привет,
Такая же проблема здесь ...

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 все работало нормально.

У Typescript есть несколько связанных проблем, они закрыли их как работающие как задумано:

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

Я привел здесь несколько примеров: https://gist.github.com/afarnsworth-valve/93d1096d1410b0f2efb2c94f86de9c84

Хотя поведение по-прежнему кажется странным. В частности, вы можете присвоить переменной, типизированной как базовый класс, без приведения, а затем без проблем выполнять те же вызовы с этим. Эта проблема, кажется, предполагает, что присвоение и сравнение - это две разные вещи.

Не забыл вас, ребята. Скоро исправлю

Указанный PR должен решить эту проблему. Я также добавил тесты, которые должны защитить от повторного взлома этого крайнего случая.

@ericanderson Спасибо за быстрый ответ :)

Есть ли у нового исправления какие-либо ограничения / недостатки?

Ничего из того, о чем я сейчас знаю. Мне удалось сохранить intellisense (на самом деле лучше, чем раньше, поскольку он решает некоторые крайние случаи).

Чтобы уточнить, решение & Partial<S> заключалось в том, чтобы обмануть intellisense, чтобы выявить возможные параметры, но он сделал это, заявив, что они равны X | undefined . Это, конечно, не скомпилируется, но это немного сбивает с толку. Получение | S исправляет intellisense, так что он предлагает все правильные параметры, и теперь он не показывает ложный тип.

Я попытался добавить null в качестве возможного возвращаемого значения из обратного вызова setState (что вы можете вернуть в состояние, в котором вы не хотите изменять какое-либо состояние, не делая return; также действителен), но вместо этого вывод типа полностью отказался и выбрал never в качестве ключей 😢

На данный момент в обратных вызовах, где я действительно хочу пропустить состояние обновления, я использовал return null! . Тип never этого возврата заставляет TypeScript игнорировать возврат для вывода универсального типа.

Привет, народ...

Последняя фиксация устранила мою проблему.
Спасибо за быстрый ответ :)

В какой версии есть исправление? Это опубликовано в npm? Я попал в случай, когда версия обратного вызова setState сообщает мне о несоответствии свойств в возвращаемом значении, точно так же, как обнаружено @UselessPickles .

Должно быть хорошо на последних @ types / react

Я исправил это для 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 .

Придется использовать оператор утверждения NULL, даже если numberList не является неопределенным и не допускающим значения NULL:

Я просто останусь на старом определении типа, пока не улучшится распознавание типов. А пока я просто явно укажу тип в универсальном параметре immer productions. 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 не может определить правильный тип состояния. Следовательно, intellisense для черновика не отображается:

Или, возможно, у меня неправильные ожидания от компилятора :) Компилятор не может создать тип для переменной draft на основе типа 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, ваша ошибка находится внутри продукта. Каково ваше определение типа продукции?

В моем PR выше есть ошибка в тестовом сценарии ОпределенноТипед, я не тестировал локально. Так что сейчас тестирую локально.

Вот определение типа погружения / производства.

/**
 * 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. Я не уверен, что правильно понимаю. В любом случае идеальным использованием с моей точки зрения должно быть то, что я могу передать переменную типа Partialпрямо в setState.

Не могли бы вы рассмотреть мое предложение или указать на мое недоразумение, если оно есть? Спасибо!

Во-первых, это действительно старое изменение. Так что, если кто-то недавно это не изменил, вы, вероятно, лаете не на то дерево.

Тем не менее. Частично допускает неопределенные значения.

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

a действителен, но очевидно, что результат этого обновления вашего состояния ставит ваше состояние с foo как undefined, даже если вы заявили, что это невозможно.

Следовательно, частичное не может быть присвоено Пик. И Pick - правильный ответ, чтобы убедиться, что ваши типы не лгут

Я чувствую, что не позволяю:

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

супер ограничительный.

Обходной путь

Можно ли что-нибудь сделать для поддержки этого (я бы сказал) довольно распространенного шаблона?

Единственное, что можно сделать, это убрать безопасность типов.

Может кто-нибудь объяснить причину 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;

Я даже не понимаю, почему указанная выше подпись работает даже для частичных обновлений состояния, поскольку 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: "" };
});

супер ограничительный.

Обходной путь

Я только что столкнулся с этой проблемой, но я не вижу упоминания о Ковенском в теме (может быть, кто-то изменил свое имя пользователя?). Может ли кто-нибудь указать мне на рекомендуемый в настоящее время обходной путь

@ timrobinson33 Этот комментарий объясняет обходной путь https://github.com/DefinitiTyped/DefinitiTyped/issues/18365#issuecomment -351884578

И хорошо, что с крючками нам больше не нужно об этом беспокоиться 🙂

@ timrobinson33 Этот комментарий объясняет обходной путь # 18365 (комментарий)

Большое спасибо за это. В конце концов, я подумал, что мой код выглядел лучше в виде нескольких небольших вызовов setState с операторами If за их пределами, хотя это означает, что некоторые пути будут вызывать setState более одного раза.

Я предполагаю, что это на самом деле похоже на то, как мы работаем с хуками, рассматривая состояние как несколько мелких вещей, которые мы обновляем независимо.