Panou de extindere lipsă · Numărul nr. 17 · cfnzmuirwik · GitHub

Comentarii

Copiați linkul Citat răspuns

panou

karol-202 comentat 18 iulie 2019

Am observat că nu există nicio legare pentru componenta ExpansionPanel (împreună cu ExpansionPanelDetails etc.) în muirwik.

Trebuia să-l folosesc, așa că l-am implementat în furculița mea, totuși nu sunt sigur dacă ar trebui să creez PR, deoarece:

  • Am scris componenta conform celei mai noi API v4 (nu știu cât s-a schimbat API în comparație cu versiunea pe care o folosește muirwik),
  • Am anulat toate variabilele de recuzită pentru aceste componente, deoarece cred că este mai sigură (gândiți-vă să încercați să obțineți valoarea prop-ului nedefinit:
    mExpansionPanel < attrs.expanded.doSomething() // Will fail >,
    folosind recuzite nullable nu se va compila), dar este incompatibil cu restul muirwik de cealaltă parte,
  • Am omis accesoriile TransitionComponent și TransitionProps ale ExpansionPanel pentru că nu eram sigur cum să implementez TransitionComponent (din câte îmi amintesc, și alte componente din muirwik nu au aceste recuzite, așa că cred că nu este o mare problemă)

Dacă vi se pare ok, voi fi fericit să creez un PR.

Textul a fost actualizat cu succes, dar s-au întâlnit aceste erori:

cfnz comentat 18 iulie 2019

Bună, da, aș fi fericit să arunc o privire asupra codului. s-ar putea să nu o încorporeze până la lansarea versiunii 4, dar va fi bine să obțineți câteva idei.

Mă pregătesc să fac o versiune pentru v3.9.3 a Material Design, în principal unele modificări în procesul de compilare și să actualizez versiunea lodash utilizată din cauza unei probleme de securitate.

Dar apoi voi începe să mă uit la versiunea 4 și s-ar putea să fac alte schimbări, așa că ar fi bine să mă uit la opțiuni (de exemplu, voi arunca o privire la ceea ce vorbiți despre recuzita nulă) și, de asemenea, mă gândesc să reduc numărul de constructori, având un constructor principal care ia cele mai frecvente opțiuni, dar nu are fiecare proprietate într-un constructor alternativ, deoarece puteți merge la attrs.property = x după aceea. De ce? Doar găsind cantitatea de informații prezentate în IDE atunci când construiești unele elemente un pic copleșitoare. dar ar fi bine să respingem mai întâi acele idei și să vedem ce cred alții. s-ar putea sparge un anumit cod, așa că din nou ar fi bine să auziți orice opinie.

karol-202 comentat 19 iulie 2019

Bună, deci iată codul panourilor de expansiune. Când sunteți gata să încorporați modificările, spuneți-mi, așa că voi reinițializa ramura panoului de expansiune și voi face o cerere de extragere.

În ceea ce privește nulitatea recuzită, nu sunt 100% sigur care este o soluție adecvată, deoarece problema despre care scriau face parte dintr-o problemă mai mare cu nulitatea în Kotlin/JS. În Kotlin/JVM, singura modalitate de a crea un obiect este de a crea o nouă instanță care invocă constructorul și care vă permite efectiv să nu atribuiți valoare variabilei care nu este nulă. Și în Kotlin/JS nimic nu vă împiedică să creați obiect gol folosind fie jsObject <> fie js ("<>") și apoi să aruncați într-o anumită clasă sau interfață. Și, după cum știți, acesta este modul în care React creează recuzită pentru noi componente. Așadar, alegerea dintre recuzită nulă sau non-nulă nu este o nebunie. Pe de o parte, faptul că recuzita este nulă vă protejează de erori potențiale atunci când accesați recuzite nedefinite, dar pe de altă parte, verificarea nulității de fiecare dată când accesați recuzita este puțin greoaie dacă este necesară recuzita. Deci, drumul meu este să fac toate elementele de recuzită necesare să fie nule pentru a nu fi obligat să verific nul de fiecare dată când folosesc prop în componenta mea (există totuși pericolul legat de a nu trece recuzita la componentă, dar acest lucru poate fi rezolvat prin forțând să le treacă prin argumentele de creare a metodei (