React: Apakah ada cara untuk mengakses api konteks baru di dalam ComponentDidMount?

Menambahkan contoh yang saya coba agar ini berfungsi: https://codesandbox.io/s/l20yn296w7

EDIT: Mengikuti pedoman dari https://github.com/reactjs/rfcs/blob/master/text/0002-new-version-of-context.md#class -based-api

Beginilah cara melakukannya dengan api baru.

class BaseMapElement extends React.Component {
  componentDidMount() {
    console.log(this.props.context);
  }

  render() {
    return null;
  }
}

const MapElement = () => (
  <Context.Consumer>
    {context =>
      <BaseMapElement context={context} />
    }
  </Context.Consumer>
)

Jadi satu-satunya cara untuk mengakses melalui componentDidMount adalah dengan mengalihkan ke Props?

Edit: Diubah menjadi componentDidMount

Komponen urutan yang lebih tinggi yang dialihkan ke props adalah pola yang baik, tetapi untuk kasus di mana tidak menginginkan komponen tambahan biasanya yang saya lakukan adalah menyimpan nilai konteks pada contoh komponen seperti: this.contextValue = value lalu akses di kait siklus hidup. Agak jelek tapi tidak apa-apa secara umum menurut saya karena Anda memilih keluar dari pola yang lebih baik, hoc, sebagai pengoptimalan

Saya menghadapi dilema yang sama.
Harus ada cara mudah untuk mengakses atau memanggil konteks dalam metode siklus hidup.
Kami mungkin perlu menginisialisasi barang, memeriksa dan mengambil data atau bahkan membersihkan saat melepas.
Orang-orang melakukannya sekarang dengan konteks yang seharusnya rusak saat ini.
Ya, itu bisa diselesaikan dengan membungkus komponen kita dengan komponen lain! Tapi terasa seperti solusi lebih dari sekedar solusi.

simpan nilai konteks pada contoh komponen seperti: this.contextValue = value lalu akses di hook siklus hidup

Saya cukup yakin ini tidak aman dalam mode async. Tolong jangan lakukan ini. cc @

Ya, itu bisa diselesaikan dengan membungkus komponen kita dengan komponen lain! Tapi terasa seperti solusi lebih dari sekedar solusi.

Saya setuju dengan itu. Alangkah baiknya untuk mengakses secara native melalui componentDidMount dan componentWillUnmount untuk dapat menginisialisasi / membersihkan sesuatu,

Secara umum, menggunakan instance vars untuk menjadi pintar dan menipu aliran data normal akan menyebabkan masalah pada asinkron. Jangan. Agak membingungkan hari ini, karena instance vars adalah satu -

tl; dr: Gunakan alat peraga tipuan. Dan jangan terlalu khawatir tentang komponen tambahan.

Saya cukup yakin ini tidak aman dalam mode async. Tolong jangan lakukan ini.

Bagaimana hal ini tidak aman (dan dengan cara apa)? Tidak jelas dalam semua pembicaraan tentang mode async ini, apa artinya "tidak aman". Ini mulai terasa seperti seorang boogyman yang perilakunya tidak rasional dan tidak dapat diprediksi, yang tidak memberi orang banyak jaminan dalam sistem yang umumnya disukai karena model aliran data yang lugas dan mudah dimengerti. Saya merasa seperti komponen kembali ke tanah sebelum 0,13 di mana mereka adalah objek ajaib lagi.

Juga mudah untuk mengatakan "Cukup tambahkan komponen lain", tetapi itu sering kali memberatkan, dan memperkenalkan kategori bug dan tantangannya sendiri. Saya tidak mulai merasa seperti orang harus menciptakan abstraksi melalui API reaksi agar "aman".

maaf ^ jika yang di atas terdengar kesal / marah, saya tidak bermaksud nada itu! di phhhhooone

Kedengarannya marah haha ​​tapi saya mengerti maksud Anda dan saya membagikan pertanyaan Anda tentang bagaimana / mengapa ini tidak aman

Ini mulai terasa seperti orang gila yang perilakunya tidak rasional dan tidak dapat diprediksi

Maaf, kami telah mengerjakan panduan dengan saran khusus selama lebih dari sebulan sekarang. Tolong beri kami waktu untuk mengumpulkan dan menerbitkannya sebagai entri blog. Sulit juga untuk berdiskusi tanpa alpha yang sebenarnya untuk dimainkan, yang juga merupakan sesuatu yang telah kami kerjakan dengan keras.

Jadi kita harus tidak mengatakan apapun sama sekali, atau memperingatkan sebelumnya tentang hal-hal yang tidak akan bekerja dengan baik. Kami keliru di sisi peringatan, tetapi saya dapat melihat bagaimana kelihatannya kami mempersulit Anda. Saya yakin bahwa setelah kode keluar dan Anda dapat memainkannya, Anda akan mengerti maksud kami, dan itu akan lebih masuk akal.

Bagaimana hal ini tidak aman (dan dengan cara apa)?

Apakah Anda mendapat kesempatan untuk menonton pembicaraan saya ? Ini akan sedikit sulit dijelaskan jika Anda belum melihat bagian kedua, karena tidak jelas mengapa kami melakukan ini. Jadi saya meminta Anda untuk menontonnya. Saya harap ceramah saya akan meyakinkan Anda bahwa kami bertujuan untuk memecahkan berbagai masalah yang melanda React sejak awal, dan bahwa fitur-fitur ini layak untuk meninjau kembali beberapa asumsi yang mungkin biasa kami lakukan.

Dengan asumsi Anda telah melihat ceramahnya, berikut adalah penjelasan yang lebih spesifik tentang kasus khusus ini. Untuk dapat "menangguhkan" rendering seperti yang saya tunjukkan di demo, React harus dapat memanggil render() kapan saja, berpotensi dengan props yang berbeda. Misalnya, jika dapat menyetel this.props dan this.state ke properti dari layar baru (yang sedang dimuat), panggil render , tetapi kemudian setel ke this.props dan this.state saat rendering sebagai tanggapan atas interaksi pada versi pohon saat ini (misalnya jika saya menekan sesuatu saat layar baru sedang dimuat).

Di asinkron, aturan praktisnya adalah: hanya siklus hidup seperti componentDidMount , componentDidUpdate , dan componentWillUnmount dan panggilan balik ref dijalankan pada titik waktu yang ditentukan dengan baik dengan props dan status yang sesuai ke apa yang ada di layar. Untungnya kami hanya memiliki beberapa siklus hidup lain yang tidak cocok dengan gambar ini, dan kami memperkenalkan alternatif yang lebih baik untuk mereka ( getDerivedPropsFromState , getSnapshotBeforeUpdate ). Ini akan menjadi migrasi bertahap. Sekali lagi, semuanya akan ada di posting blog.

Sekarang ke akar masalah ini. Dalam mode async, React tidak menjamin tentang kapan dan bagaimana urutannya memanggil metode render . Sesuatu yang pada awalnya tidak pernah dijamin oleh React — urutannya selalu sama setiap saat. Menyimpan bidang di render dan kemudian membacanya dalam siklus hidup tidak “aman” karena Anda mungkin menyimpan bidang pada saat React memanggil render dengan alat peraga yang berbeda (seperti untuk pohon yang belum siap).

Harus ada cara mudah untuk mengakses atau memanggil konteks dalam metode siklus hidup.
Ya, itu bisa diselesaikan dengan membungkus komponen kita dengan komponen lain! Tapi terasa seperti solusi lebih dari sekedar solusi.

Saya mengerti ini terasa seperti pembungkus ekstra, tetapi itulah yang membuat konteks baru cepat . Jika kita tidak memiliki node pembungkus eksplisit di pohon, kita tidak akan dapat dengan cepat "menemukan" komponen yang perlu diperbarui.

Jika Anda perlu mengakses konteks dalam siklus hidup, anggap itu sebagai prop.

class Button extends React.Component {
  componentDidMount() {
    alert(this.props.theme);
  }

  render() {
    const { theme, children } = this.props;
    return (
      <button className={theme ? 'dark' : 'light'}>
        {children}
      </button>
    );
  }
}

export default React.forwardRef((props, ref) => (
  <ThemeContext.Consumer>
    {theme => <Button {...props} theme={theme} ref={ref} />}
  </ThemeContext.Consumer>
));

Jumlah baris ini hampir sama dengan definisi contextTypes .

Ya, itu bisa diselesaikan dengan membungkus komponen kita dengan komponen lain! Tapi terasa seperti solusi lebih dari sekedar solusi.

Hanya ingin menjelaskan apa yang Dan katakan bahwa pendekatan child function / render prop adalah _official API_ untuk konteks baru- jadi silakan gunakan dan biarkan React khawatir tentang memastikannya cepat. (Itu akan terjadi!)

Bagaimana hal ini tidak aman (dan dengan cara apa)?

Draf dokumen Mode Ketat juga membahas beberapa alasan mengapa mutasi instans (yang hanya merupakan jenis efek samping lain) berbahaya dalam mode asinkron.

Kami memiliki cabang percobaan yang mengikuti pedoman yang diusulkan di sini. Adakah yang bisa melihat apakah ini masuk akal? https://github.com/omodityvectors/react-mapbox-gl/pull/11

Saya tidak terbiasa dengan pustaka ini, jadi saya tidak tahu apakah orang pernah menggunakan referensi dengan komponennya- tetapi jika mereka melakukannya, withContext mixin pada PR itu mungkin merupakan kasus penggunaan yang baik untuk API forwardRef .

Masuk akal. Terima kasih atas referensinya. Saya akan menutup masalah ini sekarang.

Baru saja mengalami masalah ini karena saya telah mencoba melihat apakah saya dapat mencapai hal yang sama.

Jadi, dari apa yang dapat saya kumpulkan dari semua ini, tidak mungkin dalam komponen yang menggunakan Context.Consumer untuk mengakses API di luar fungsi render anak. Saya telah menemukan sesuatu yang mungkin berhasil untuk membuat semua ini sedikit lebih mudah (akan sangat menghargai beberapa umpan balik jika ini bukan praktik yang baik karena alasan apa pun):

const MapElement = (props) => (
  <Context.Consumer>
    {context =>
      <RunOnLifecycle
        runOnMount={() => { /*use context*/ }}
        runOnUnMount={() => { /*use context*/ }}
        runOnUpdate={(prevProps) => { /*use context - compare prevProps with props */ }}
        { ...props }
      />
    }
  </Context.Consumer>
)

Dan komponen pembantu itu <RunOnLifecycle/> :

export interface IPropsRunOnLifecycle {
  runOnMount?: () => void;
  runOnUpdate?: (prevProps: object) => void;
  runOnUnMount?: () => void;
  children?: JSX.Element | ReactNode;
  [prop: string]: any;
}

export class RunOnLifecycle extends React.Component<IPropsRunOnLifecycle> {
  componentDidUpdate(prevProps, prevState, snapshot) {
    if (this.props.runOnUpdate != null) {
      this.props.runOnUpdate(prevProps);
    }
  }

  componentDidMount() {
    if (this.props.runOnMount != null) {
      this.props.runOnMount();
    }
  }

  componentWillUnmount() {
    if (this.props.runOnUnMount != null) {
      this.props.runOnUnMount();
    }
  }

  render() { return this.props.children || null; }
}

Bertanya-tanya apakah ini akan menyebabkan sakit kepala di telepon. Masih terasa seperti React standar yang cukup, jika agak hack.

Ada beberapa perbedaan halus yang mungkin membuat pendekatan itu menjadi ide yang buruk. Sebagai contoh, jika MapElement adalah komponen kelas yang menggunakan ref, ref tidak akan diset ketika callback runOnMount dijalankan.

😄 Saya akan menyarankan menggunakan pendekatan HOC untuk ini sebagai gantinya:
https://reactjs.org/docs/context.html#consuming -context-with-a-hoc

Satu-satunya downside nyata untuk menggunakan HOC untuk hal semacam ini telah dikurangi oleh forwardRef API:
https://reactjs.org/docs/react-api.html#reactforwardref

Kami mengambil pendekatan seperti dokumen react dan apa yang dikatakan orang di sini. Sejauh ini, ini bekerja dengan baik untuk kami.

https://github.com/omodityvectors/react-mapbox-gl/blob/master/src/Map.js#L63

Ada beberapa perbedaan halus yang mungkin membuat pendekatan itu menjadi ide yang buruk. Misalnya, jika MapElement adalah komponen kelas yang menggunakan ref, ref tidak akan disetel saat callback runOnMount dijalankan.

Terima kasih atas umpan baliknya @bvaughn . Saat ini saya menggunakannya murni sebagai semacam komponen proxy status yang menambahkan / menghapus sesuatu dari UI tergantung pada apa yang dipasang di dalam pohon konteks. Jenis portal serupa tetapi di dalam pohon komponen React. Jadi tidak benar-benar menyerahkan anak-anak atau berurusan dengan wasit sama sekali.

Akan diingat jika saya perlu melakukan sesuatu yang berinteraksi dengan wasit.

Hai semuanya,

Saya membutuhkan data konteks dalam metode siklus hidup. jadi, saya mengikuti pendekatan HOC setelah melihat beberapa komentar pertama dan meneruskan data konteks sebagai alat peraga.
Semuanya bekerja seperti yang diharapkan. Tetapi sekarang, saya ingin menulis kasus pengujian unit untuk komponen tetapi saya tidak dapat melakukannya.

Saya akan sangat menghargai jika seseorang dapat berbagi bagaimana saya dapat menulis kasus uji untuk skenario ini.

Saya menggunakan enzyme, enzyme-adapter-react-16 dan jest tetapi mengalami beberapa masalah dalam melakukannya.

@Arema

Di perusahaan tempat saya bekerja, kami melakukan hal berikut (perhatikan, ini mungkin bukan konsensus), kami mengekspor komponen "telanjang" juga, lalu mengimpornya dalam pengujian kami dan meneruskan props secara manual.

Misalnya

// MyComponent.js
export class MyComponent extends Component { /* ... */ }
export default HOC()(MyComponent)

// MyComponent.spec.js
import { MyComponent } from '...'

// OtherComponents.js
import MyComponent from '...'

Selain itu, menambah diskusi ini, kami mengalami masalah yang sama dan membuat https://www.npmjs.com/package/react-context-consumer-hoc ini yang menggunakan banyak konteks.

Semuanya bekerja seperti yang diharapkan. Tetapi sekarang, saya ingin menulis kasus pengujian unit untuk komponen tetapi saya tidak dapat melakukannya.

@AmnArora Mengapa Anda tidak dapat menulis tes unit? Apa yang sudah kamu coba? Kesalahan apa yang Anda lihat?

@pgarciacamou Terima kasih atas balasan cepatnya. Nah, setelah tidak menemukan apa pun di web dan memposting kueri di sini. Saya datang dengan solusi yang sama yang Anda sebutkan.

Kasus Uji bekerja sekarang tetapi ini sepertinya berhasil. Saya akan melihat di https://www.npmjs.com/package/react-context-consumer-hoc dan berdiskusi dengan tim saya.

Terima kasih. : 100:

@bvaughn Masalahnya adalah sebelumnya ketika saya menggunakan redux untuk manajemen negara, saya dangkal menyalin Komponen dan menggunakan metode dive () dan instance () untuk mendapatkan instance dari komponen.

Tetapi tidak satu pun dari metode ini tersedia saat menggunakan API konteks.

Dan ketika saya tidak menggunakan salah satu metode ini, saya mendapatkan kesalahan berikut: _unknown node with tag 12_

Kena kau.

Kedua hal ini terdengar seperti masalah dengan versi Enzim yang Anda gunakan tidak mendukung API konteks baru dengan benar. Itu sangat disayangkan.

Saya mendapat ketidaksukaan besar untuk redux dan unistore (banyak polusi kode / imo bagian yang bergerak ekstra) yang membawa saya ke pengaturan berikut yang memungkinkan komponen bersarang kami mengakses satu status global. Semua hal lain yang tidak boleh dalam status global (mis. Nilai input teks, nilai toggle) disimpan dalam status lokal setiap komponen bersarang.

https://github.com/davalapar/session-context

Hai,

apakah masalah ini terpecahkan?

Saya memiliki skenario di mana saya memiliki 3 komponen. Pencipta, Tampilan, Sel.
Sel memiliki logika render saya yang digunakan di Pencipta dan Tampilan.

Saat ini saya harus meneruskan status jika item sedang dibuat atau harus ditampilkan. Saya telah menggunakan Sel di lokasi yang berbeda jadi saya harus memberikan status sebagai alat peraga secara terpisah. Jadi saya ingin menggunakan konteks untuk status tetapi masalahnya adalah saya ingin mengubah konteks hanya jika komponen Tampilan dipasang. Bisakah kita mencapai ini adalah versi React saat ini? (Saya menggunakan React 16.7)

Ada beberapa komentar di atas yang menunjukkan cara mengakses nilai Context.Consumer dalam componentDidMount . Apakah Anda mencobanya? Apakah mereka tidak bekerja karena suatu alasan?

Perhatikan bahwa React 16.6 menambahkan API contextType untuk kelas yang membuat membaca konteks baru di componentDidMount mudah.

https://reactjs.org/docs/context.html#classcontexttype

Ya, asalkan Anda hanya perlu menggunakan satu konteks dalam komponen Anda– contextType adalah pilihan yang mudah.

Perhatikan bahwa React 16.6 menambahkan API contextType untuk kelas yang membuat membaca konteks baru di componentDidMount mudah.

Itu tidak. Bahkan jika satu tipe konteks sudah cukup, Class.contextType merusak pewarisan. Hal yang sama berlaku tentang HOC.

Kami cukup eksplisit dalam dokumen kami tentang merekomendasikan komposisi daripada warisan untuk menggunakan kembali kode antar komponen. Di luar itu, saya tidak begitu mengerti apa yang Anda katakan.

API contextType pasti _does_ membuatnya mudah untuk mengakses nilai konteks di componentDidMount (tentang topik ini).

Kami cukup eksplisit dalam dokumen kami tentang merekomendasikan komposisi daripada pewarisan ...

Itu terlalu luas ...

Kasus yang saya perjuangkan sekarang, adalah saya memiliki keluarga komponen dengan banyak fungsi umum yang diperlukan untuk mendukung penerapannya. Semuanya dimodelkan oleh warisan dengan sempurna, kecuali ... bit konteks!

Mengingat sepertinya saya mengacaukan konteks hanya dalam situasi seperti ini, API konteks cukup membuat frustrasi.

... tentang apa utas ini ...

Ya, komentar ini sedikit keluar dari topik.

Mengubah contextType dengan Kelas Konteks merusak penyimpanan redux: /

Perhatikan bahwa React 16.6 menambahkan API contextType baru untuk kelas yang membuat membaca konteks baru di componentDidMount menjadi mudah.

Ya, asalkan Anda hanya perlu menggunakan satu konteks dalam komponen Anda– contextType adalah opsi yang nyaman.

Apakah tidak ada cara untuk membuat konteks sebelum menetapkannya ke MyCoolComponent.contextType ?

Bacaan saya adalah untuk saat ini, jika kita menginginkan komponen yang dapat:

a) Menggunakan banyak konteks
b) Gunakan hal-hal dari konteks tersebut dalam metode selain render

Ini berarti kita terjebak dengan pola yang dideskripsikan di mana pembungkusnya menggunakan konteks dan meneruskan props ke anak.

Saya merasa bahwa situasi yang ideal adalah saya dapat menulis sesuatu seperti ini, dan mendapatkan yang terbaik dari kedua dunia (yaitu berbagai konteks tersedia di seluruh kelas):

MyCoolComponent.contextType =  composeContexts(OneContext, TwoContext, RedContext, BlueContext)

Apakah ada cara untuk melakukan ini?

Ia bekerja untuk metode render, tetapi tidak bekerja untuk metode lain .... ada ide ??

Hei yang disana.
Apakah ada kemungkinan untuk menggunakan api konteks baru dalam konstruktor komponen kelas?

Kami memigrasi proyek kami dari v15.x ke v16.x, salah satu tugasnya adalah menggunakan api konteks baru
Dalam proyek kami, kami menggunakan css-modules + isomorphic-style-loader, yang terakhir mengekspos beberapa API untuk memasukkan stylesheet komponen ke DOM.

Di V15, kami menempatkan API tersebut ke dalam api konteks lama, dan membiarkan setiap komponen mendapatkannya melalui sesuatu seperti

    class MyComp extends Component {
        static contextTypes = {
                insertCss: PropTypes.func
           }
         ....
         componentWillMount () {
                // insert a style tag for this component
               this.removeCss = this.context.insertCss(myStyles)
         }
    }

Di V15, kita bisa meletakkan ini di componentWillMount. Ini akan memastikan komponen mendapatkan gaya yang benar sebelum rendering.

Namun, di V16, componentWillMount ditandai sebagai tidak aman dan akan dihentikan di masa mendatang.
Jadi pemikiran langsung kami adalah menempatkan panggilan context.insertCss kami ke konstruktor komponen.

Namun, dilihat dari dokumen tersebut ,

Jika contextTypes ditentukan dalam sebuah komponen, metode siklus hidup berikut akan menerima parameter tambahan, objek konteks:

konstruktor (alat peraga, konteks)

Penggunaan ini (dengan konteks sebagai parameter ke-2) juga tidak akan digunakan lagi.

Saya mencoba api konteks baru, menugaskan MyComp.contextType = StyleContext
Namun saya menemukan bahwa saya mendapatkan this.context is undefined in constructor.

    class MyComp extends Component {
        static contextType = StyleContext

         constructor (props) {
             super(props)
             console.log(this.context) // undefined
         }

    }

Apakah ada panduan praktis tentang cara menggunakan konteks dalam konstruktor?

Ada saran?

Hei yang disana.
Apakah ada kemungkinan untuk menggunakan api konteks baru dalam konstruktor komponen kelas?

Kami memigrasi proyek kami dari v15.x ke v16.x, salah satu tugasnya adalah menggunakan api konteks baru
Dalam proyek kami, kami menggunakan css-modules + isomorphic-style-loader, yang terakhir mengekspos beberapa API untuk memasukkan stylesheet komponen ke DOM.

Di V15, kami menempatkan API tersebut ke dalam api konteks lama, dan membiarkan setiap komponen mendapatkannya melalui sesuatu seperti

    class MyComp extends Component {
        static contextTypes = {
                insertCss: PropTypes.func
           }
         ....
         componentWillMount () {
                // insert a style tag for this component
               this.removeCss = this.context.insertCss(myStyles)
         }
    }

Di V15, kita bisa meletakkan ini di componentWillMount. Ini akan memastikan komponen mendapatkan gaya yang benar sebelum rendering.

Namun, di V16, componentWillMount ditandai sebagai tidak aman dan akan dihentikan di masa mendatang.
Jadi pemikiran langsung kami adalah menempatkan panggilan context.insertCss kami ke konstruktor komponen.

Namun, dilihat dari dokumen tersebut ,

Jika contextTypes ditentukan dalam sebuah komponen, metode siklus hidup berikut akan menerima parameter tambahan, objek konteks:

konstruktor (alat peraga, konteks)

Penggunaan ini (dengan konteks sebagai parameter ke-2) juga tidak akan digunakan lagi.

Saya mencoba api konteks baru, menugaskan MyComp.contextType = StyleContext
Namun saya menemukan bahwa saya mendapatkan this.context is undefined in constructor.

    class MyComp extends Component {
        static contextType = StyleContext

         constructor (props) {
             super(props)
             console.log(this.context) // undefined
         }

    }

Apakah ada panduan praktis tentang cara menggunakan konteks dalam konstruktor?

Ada saran?

Anda dapat melakukan seperti ini daripada menggunakan contextType

class MyComponent extends React.Component {
   render(){
       const {
         //props including context props
       } = this.props;
       return(<View />);
   }
};

const withContext = () => (
  <MyContext.Consumer>
    { (contextProps) => (<MyComponent {...contextProps}/>)}
  </MyContext.Consumer>
);

export default withContext;

Untuk siapa pun seperti saya yang berjuang untuk menggunakannya di luar fungsi render Anda, cukup gunakan yang berikut di sub-komponen Anda:

useContext ()

Sebagai contoh:

const context = useContext(yourContext)

MainComponent.Subcomponent = () => {
 const context = useContext(context)

  useEffect(()=> {
    console.log(context)
  })
}