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 (

)) și să anuleze toate recuzita opțională.
Majoritatea elementelor de recuzită din Material-UI sunt opționale (poate chiar toate, nu l-am verificat), ceea ce se reflectă în fișierele sursă Typescript în repo MUI (exemplu), deci cred că cel mai bun mod este să le anulezi.

În ceea ce privește reducerea constructorilor în jos, argumentele implicite ale lui IMHO Kotlin fac ca având o mulțime de parametri într-un constructor să nu fie o problemă mare. Poate că doar mutarea celor mai frecvente opțiuni în partea de sus a listei de argumente ar fi o soluție? Dar încă nu m-am gândit prea mult la asta.

cfnz comentat 23 iulie 2019

Bună, sună bine. Am început să mă uit la versiunea 4, a mea nu a compilat bat (cele mai recente lucruri jssprovider), dar am trecut prin majoritatea problemelor acum. Aveți versiuni de mai multe dependențe și un lucru bun este că timpul de la compilare la reîncărcarea UI este mult mai rapid, nu sunt sigur dacă sunt îmbunătățirile din Kotlin sau webpack sau ce, dar este o mare îmbunătățire. Mai sunt încă ceva de făcut, dar vom analiza încorporarea panoului de expansiune în curând.

În ceea ce privește chestiunea cu abilități nule, este un pic dificil. Îmi place intenția a ceea ce afirmați și, la suprafață, sună ca drumul de parcurs, dar am făcut un pic de testare.

Nule și nedefinite sunt subtil diferite în javascript. În unele părți ale UI-ului material (nu-mi amintesc unde acum), treceam în valori nule și nu funcționa corect, dar dacă nu treceam nimic, acest lucru îl făcea să funcționeze corect, deci toți parametrii? < attrib.param = it>în jurul locului.

Problema cu un atribut care este nul în Kotlin este că în javascript, Kotlin îl transformă în nul atunci când nu este atribuit, mai degrabă decât să fie nedefinit. Acest lucru este diferit de definițiile dactilografiate în care recuzita este opțională - care lipsește sau este nedefinită decât să fie nulă. Puteți vedea acest lucru în următorul exemplu:

Așa că la început mi s-a părut o idee bună și am mers de fapt și am schimbat câteva componente în anulabile și totul părea să funcționeze OK, dar apoi mi-am amintit problema pe care am trimis-o într-un element nul ca un element de recuzită undeva, la fel și aceste teste, și testul numărul 2 și 3 sunt cele care ar putea cauza unele probleme.

De asemenea, mi-am bazat codul altor exemple, cum ar fi ambalajele kotlin reale, de ex. acest lucru în cazul în care nu par să folosească nul.

Asa de. Îmi place ideea, dar nu sunt 100% sigură dacă este o persoană interesată. Cred că nu te uiți des la proprietățile secundare ale unei recuzită, de obicei le-ai testa egalitatea, dar de multe ori nu mergi mult mai departe, oricum nu pentru recuzita materialului UI. Dacă vă creați propriile componente, poate că este OK, dar predarea accesoriilor către o altă bibliotecă, depinde de modul în care se ocupă de recuzită fiind nul față de nedefinit și, așa cum am menționat, știu un caz (deși nu știu unde este: - )) că UI-ului material îi plăcea mai degrabă nedefinit decât nul.

Rezumat. a fost cam cam blurb! Dar cred că ați ridicat un punct important care merită discutat/investigat. Vreau ca biblioteca de împachetări să fie cât mai bună posibil, așa că dacă schimbarea tuturor elementelor de recuzită la anulabilă ar face-o mai bună, cred că ar merita (și nu a durat mult să le schimb pe cele câteva pe care le-am făcut înainte să o regândesc) . dar după ce a regândit-o. poate că nu merită din cauză că comportamentul oricărui accesoriu este nul, înseamnă că nu mai poate fi nedefinit - ceea ce va cauza unele probleme în UI material (undeva).