Itu menarik. Saya senang untuk memutar kembali sebagian dan memilih bagian dari perubahan

Saya akan mengatakan bahwa apa yang Anda laporkan terdengar seperti bug di TS, khususnya:

Ketik '{ baseProp: "foobar"; }' tidak dapat ditetapkan untuk mengetik 'Sebagian

Baik. Mungkin TS tidak tahu ada apa karena tidak ada hubungan antara S dan baseProp.

Seseorang dapat melewati S yang bertipe { baseProp:number } dalam hal ini benar bahwa Anda tidak dapat menetapkan string ke baseProp.

Mungkin jika S memperpanjang versi baseProp?

Saya telah mencoba sesuatu seperti ini sebelumnya:

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' } );
    }
}

saat aksesnya ok, panggilan setState memiliki kesalahan yang sama:

Argumen tipe '{ baseProp: "foobar"; }' tidak dapat ditetapkan ke parameter tipe '((prevState: Readonly\ , props: P) => Pick & Partial\ ) |
}' tidak dapat ditetapkan untuk mengetik 'Pilih & Sebagian\ '.Ketik '{ baseProp: "foobar";

Ini mungkin bukan cara yang baik untuk menyusunnya - lagi pula, beberapa kelas anak dapat mendeklarasikan variabel status yang bertabrakan dengan variabel di kelas dasar. Jadi TypeScript mungkin benar untuk mengeluh bahwa tidak pasti apa yang akan terjadi di sana. Aneh bahwa tidak ada masalah dengan mengakses alat peraga itu.

Hmm. Ini pasti terasa seperti bug di TS sekarang.

Saya akan bermain dengan ini hari ini dan mungkin mengambil & Partial.

Saya akan menambahkan ini sebagai kasus percobaan juga dan mencoba ide lain untuk membuat intellisense senang

Hai,
Masalah yang sama disini...

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

Kesalahan di 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>'.

Kesalahan baru saja mulai terjadi setelah perubahan ini. Dalam versi 16.0.10 itu bekerja dengan baik.

TypeScript memiliki beberapa masalah terkait, mereka telah menutupnya sebagai bekerja seperti yang dirancang:

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

Saya membuat intisari dari beberapa contoh di sini: https://Gist.github.com/afarnsworth-valve/93d1096d1410b0f2efb2c94f86de9c84

Meski tingkahnya masih terlihat aneh. Secara khusus, Anda dapat menetapkan ke variabel yang diketik sebagai kelas dasar tanpa pemeran, dan kemudian melakukan panggilan yang sama dengan itu tanpa masalah. Masalah ini tampaknya menunjukkan penugasan dan perbandingan adalah dua hal yang berbeda.

Tidak melupakan kalian. Akan segera diperbaiki

PR yang dirujuk harus menyelesaikan masalah ini. Saya juga menambahkan tes yang seharusnya melindungi dari kerusakan casing tepi ini lagi.

@ericanderson Terima kasih atas tanggapan cepatnya :)

Apakah perbaikan baru memiliki batasan/kelemahan?

Tidak ada yang saya ketahui saat ini. Saya dapat menjaga intellisense (sebenarnya lebih baik dari sebelumnya, karena ini menyelesaikan beberapa kasus Edge).

Untuk menguraikan, solusi & Partial<S> adalah mengelabui intellisense untuk mengungkapkan kemungkinan params, tetapi ia melakukannya dengan menyatakan mereka X | undefined . Ini tentu saja akan gagal untuk dikompilasi tetapi agak membingungkan. Mendapatkan | S memperbaiki intellisense sehingga menyarankan semua parameter yang benar dan sekarang tidak menunjukkan tipe yang salah.

Saya mencoba mencari untuk menambahkan null sebagai nilai pengembalian yang mungkin dari panggilan balik setState (apa yang dapat Anda kembalikan ke status Anda tidak ingin mengubah status apa pun, tanpa membuat return; juga valid), tetapi itu malah membuat inferensi tipe benar-benar menyerah dan memilih never sebagai kuncinya

Untuk saat ini, dalam panggilan balik di mana saya benar-benar ingin melewati status pembaruan, saya telah menggunakan return null! . Tipe never dari pengembalian ini membuat TypeScript mengabaikan pengembalian untuk inferensi tipe generik.

Halo kawan-kawan...

Komit terakhir memperbaiki masalah saya.
Terima kasih atas respon cepatnya :)

Versi apa yang sudah diperbaiki? Apakah itu dipublikasikan ke npm? Saya menemukan kasus di mana versi panggilan balik dari setState memberi tahu saya bahwa ada ketidakcocokan properti dalam nilai pengembalian, seperti yang ditemukan @UselessPickles .

Harus bagus di @types/react terbaru

Saya memperbaikinya untuk seri 15 dan 16

import produce from 'immer';

interface IComponentState
{
    numberList: number[];
}

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

Definisi tipe lama 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;

..menghasilkan kesalahan ini:

Saya mencoba saran ini:

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 sekarang dapat merasakan properti dari status React. Namun, properti yang dirasakan sekarang dianggap sebagai possibly undefined .

Harus menggunakan operator pernyataan nol meskipun numberList tidak terdefinisi atau tidak dapat dibatalkan:

Saya hanya akan tetap pada definisi tipe lama sampai penginderaan tipe ditingkatkan. Untuk sementara, saya hanya akan secara eksplisit menyatakan tipe pada parameter generik produk immer. produce<IComponentState> lebih mudah untuk dipikirkan daripada list! .

Kesalahan pertama Anda adalah karena Anda tidak mengembalikan apa pun. Itu bukan cara kerja setState.

Ini berfungsi bahkan ketika tidak mengembalikan variabel dalam produksi. Saya baru saja mengikuti contoh di sini (non-TypeScript):

https://github.com/mweststrate/immer

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

Satu-satunya hal yang mencegah TypeScript untuk dapat menjalankan kode itu adalah ia memiliki tipe yang salah disimpulkan dari definisi tipe React. Definisi tipe melaporkan kesalahan numberList does not exist on type Pick<IComponentState, never> . Hanya dapat membuat kesalahan kompilasi hilang dengan secara eksplisit meneruskan tipe pada parameter generik produk, yaitu produce<IComponentState> .

Saya bahkan mencoba mengembalikan variabel dalam produksi dan melihat apakah itu akan membantu definisi tipe React menyimpulkan tipe (masalah cewek-dan-telur), tetapi tetap tidak ada cara untuk definisi tipe React untuk mendeteksi tipe yang benar dari keadaan. Karenanya intellisense untuk draf tidak muncul:

Atau mungkin saya memiliki harapan yang salah dari kompiler :) Kompilator tidak dapat membuat tipe untuk variabel draf berdasarkan tipe setState karena kompilator memproses kode dari dalam ke luar. Namun, definisi tipe yang disarankan entah bagaimana membuat saya berpikir bahwa kompiler dapat memproses kode dari luar ke dalam, bahwa ia dapat memilih tipe terbaik yang dapat diteruskan dari kode luar ( setState ) ke kode dalam ( 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;

Dengan definisi tipe di atas, kompiler dapat mendeteksi bahwa draf memiliki properti numberList . Ini mendeteksinya sebagai possibly undefined meskipun:

Setelah mengutak-atik lebih lanjut, saya membuat kompiler dapat meneruskan tipe status untuk menghasilkan draf dengan menambahkan S ke definisi tipe 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;

Kode sedang dikompilasi sekarang :)

Kesalahan Anda bukan dengan setState, kesalahan Anda ada di dalam produk. Apa definisi tipe Anda untuk produk?

PR saya di atas ada kesalahan pada skrip pengujian PastiTyped, saya tidak menguji secara lokal. Jadi saya mengujinya secara lokal sekarang.

Inilah definisi tipe immer/hasilkan.

/**
 * 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 bisakah Anda mengarahkan saya ke diskusi tentang mengapa Pick digunakan alih-alih Partial ? Ini telah menyebabkan saya berjam-jam berduka (menggunakan setState(obj) , bukan versi panggilan balik), dan untuk saat ini saya menggunakan this.setState(newState as State) sebagai solusinya. Saya hanya ingin mengerti mengapa itu diubah, karena saya pasti melewatkan sesuatu.

Halo @ericanderson ,

Saya memiliki beberapa masalah dengan definisi terbaru.

Kasus penggunaan saya secara singkat seperti ini:

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
}

Pesan kesalahannya seperti:

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'.

Tampaknya Partial<AppState> tidak kompatibel dengan tanda tangan setState . Tentu saja saya bisa menyelesaikan ini dengan mengetikkan pernyataan seperti

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

tapi itu tidak ideal, karena:
1) sintaks ini sangat verbose
2) yang lebih penting, jenis pernyataan dapat melanggar data saya yang sebenarnya. Misalnya, newState as Pick<AppState, 'somethingElse'> juga lolos pemeriksaan, meskipun tidak sesuai dengan data saya.

Saya pikir Sebagianentah bagaimana harus kompatibel dengan Pick, karena Parsialhanya mengambil jumlah kunci yang tidak pasti dari T. Saya tidak yakin pemahaman saya jika akurat. Bagaimanapun penggunaan yang ideal dari sudut pandang saya adalah saya dapat melewati variabel yang diketik Parsiallangsung ke setState.

Bisakah Anda mempertimbangkan saran saya atau menunjukkan kesalahpahaman saya jika ada? Terima kasih!

Ini adalah perubahan yang sangat lama. Jadi kecuali orang lain baru saja mengubah ini, Anda mungkin menggonggong pohon yang salah.

Yang mengatakan. Parsial memungkinkan nilai yang tidak ditentukan.

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

a valid tetapi jelas hasil pembaruan ke status Anda membuat status Anda dengan foo tidak terdefinisi meskipun Anda menyatakan itu tidak mungkin.

Oleh karena itu sebagian tidak dapat ditetapkan ke Pick. Dan Pick adalah jawaban yang tepat untuk memastikan tipe Anda tidak berbohong

Saya merasa tidak mengizinkan:

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

super restriktif.

Solusi @Kovensky adalah satu-satunya solusi yang masuk akal yang saya ketahui, tetapi masih menyakitkan untuk ditulis.

Apakah ada yang bisa dilakukan untuk mendukung pola yang cukup umum ini (menurut saya)?

Satu-satunya hal yang bisa dilakukan adalah menghapus typesafety

Adakah yang bisa menjelaskan alasan 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 Saya bahkan tidak tahu sekarang mengapa tanda tangan di atas bahkan berfungsi untuk pembaruan status sebagian karena K didefinisikan sebagai keyof S jadi Pick<S, K> pada dasarnya membuat ulang S ?

bukankah seharusnya Partial<S> | null melakukan pekerjaan itu juga?

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

Adakah yang bisa menjelaskan...

Sudah dijelaskan dengan jelas beberapa balasan up.

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

super restriktif.

Solusi @Kovensky adalah satu-satunya solusi yang masuk akal yang saya ketahui, tetapi masih menyakitkan untuk ditulis.

Saya baru saja menemukan masalah yang tepat ini, tetapi saya tidak dapat melihat referensi ke Kovensky di utas (mungkin seseorang mengubah nama pengguna mereka?). Adakah yang bisa mengarahkan saya ke solusi yang direkomendasikan saat ini?

@timrobinson33 Komentar ini menjelaskan solusinya https://github.com/DefinitelyTyped/DefinitelyTyped/issues/18365#issuecomment -351884578

Dan untungnya kita tidak perlu khawatir tentang ini lagi dengan kait

@timrobinson33 Komentar ini menjelaskan solusi #18365 (komentar)

Terima kasih banyak untuk itu. Pada akhirnya saya pikir kode saya terlihat lebih bagus karena beberapa panggilan setState kecil dengan pernyataan If luarnya, meskipun ini berarti beberapa jalur akan memanggil setState lebih dari sekali.

Saya kira ini sebenarnya mirip dengan cara kami bekerja dengan kait, melihat keadaan sebagai beberapa hal kecil yang kami perbarui secara mandiri.