Відсутня панель розширення # 17

Коментарі

Копіювати посилання Цитувати відповідь

кароль-202 прокоментував 18 липня 2019 р

Я помітив, що для компонента ExpansionPanel (поряд із ExpansionPanelDetails тощо) у muirwik немає прив’язки.

Мені потрібно було ним скористатися, тому я застосував його у своєму форку, однак не впевнений, чи варто створювати PR, оскільки:

Я написав компонент відповідно до найновішого API v4 (я не знаю, наскільки змінився API порівняно з версією, яку використовує muirwik),
Я зробив усі змінні реквізиту для цих компонентів нульовими, оскільки я думаю, що це більш безпечно (подумайте про спробу отримати значення невизначеного prop:
mExpansionPanel < attrs.expanded.doSomething() // Will fail >,
використовуючи обнулюваний реквізит, який він не компілює), але це несумісно з рештою muirwik з іншого боку,
Я опустив реквізити TransitionComponent та TransitionProps ExpansionPanel, оскільки я не був впевнений, як реалізувати TransitionComponent (наскільки я пам’ятаю, інші компоненти в muirwik теж не мають цих реквізитів, тому я думаю, що це не велика проблема)

Якщо ви знайдете це нормально, я буду радий створити PR.

Текст успішно оновлено, але виявлені такі помилки:

cfnz прокоментував 18 липня 2019 р

Привіт, так, я був би радий поглянути на код. може не включати його до випуску версії 4, але буде добре отримати деякі ідеї.

Я готуюсь випустити випуск v3.9.3 Material Design, в основному деякі зміни в процесі збірки та оновлення версії lodash, яка використовується через проблему безпеки.

Але тоді я почну розглядати версію 4 і, можливо, внесу деякі інші важкі зміни, тому було б добре переглянути варіанти (наприклад, я подивлюсь на те, про що ви говорите, буде обнулюваний реквізит), а також я думаю зменшити кількість конструкторів, маючи один основний конструктор, який приймає найпоширеніші варіанти, але не маючи всіх окремих властивостей в альтернативному конструкторі, оскільки ви все одно можете перейти attrs.property = x згодом. Чому? Просто знаходження обсягу інформації, представленої в IDE, при побудові деяких елементів трохи переважає. але було б добре спочатку трохи відбити ці ідеї і подивитися, що думають інші люди. це може порушити якийсь код, тому знову було б добре почути будь-які думки.

кароль-202 прокоментував 19 липня 2019 р

Привіт, отже, ось код панелей розширення. Коли ви будете готові включити зміни, скажіть мені, щоб я перебазував гілку панелі розширення та зробив запит на витягування.

Що стосується неприпустимості реквізитів, я не впевнений на 100%, що є правильним рішенням, оскільки проблема, про яку я писав, є частиною більшої проблеми з дозвільністю в Kotlin/JS. У Kotlin/JVM єдиний спосіб створити об'єкт - це створити новий екземпляр, що викликає конструктор, і це фактично унеможливлює вам не присвоювати значення ненульовій змінній. І в Kotlin/JS ніщо не заважає вам створити порожній об'єкт, використовуючи або jsObject <>, або js ("<>"), а потім передати в даний клас або інтерфейс. І як ви знаєте, React створює властивості для нових компонентів. Тож вибір між нульовим або ненульовим реквізитом не є простим завданням. З одного боку, створення реквізиту, який може бути анульований, захищає вас від потенційних помилок при доступі до невизначеного реквізиту, але з іншого боку, перевірка на нуль кожного разу при доступі до реквізиту трохи громіздка, якщо потрібен реквізит. Отже, мій спосіб - зробити всі необхідні реквізити ненульовими, щоб не змушувати кожного разу перевіряти наявність null, використовуючи prop у моєму компоненті (все ще існує небезпека, пов’язана з не передачею prop-компоненту, але це можна вирішити змушуючи передавати їх через аргументи методу створення (

)) і зробити всі додаткові реквізити нульовими.
Більшість реквізитів у Material-UI є необов’язковими (можливо, навіть усі, я не перевіряв це), що відображається у вихідних файлах Typescript у репозиторії MUI (приклад), тому, я думаю, найкращий спосіб зробити їх анульованими.

Щодо зменшення конструкторів для схуднення, аргументи ІМХО Котліна за замовчуванням роблять наявність великої кількості параметрів у конструкторі не великою проблемою. Можливо, просто переміщення найпоширеніших варіантів у верхню частину списку аргументів буде рішенням? Але я ще не надто про це думав.

cfnz прокоментував 23 липня 2019 р

Привіт, звучить добре. Я почав розглядати версію 4, у мене не було компіляції (остання інформація про jssprovider), але зараз я пройшов більшість питань. Майте наворочені версії більшості залежностей, і одна хороша річ - час від компіляції до оновлення інтерфейсу набагато швидший, не впевнений, це вдосконалення в Kotlin чи webpack чи що, але це велике покращення. Ще трохи роботи, але незабаром ми розглянемо включення панелі розширення.

Що стосується нульової здатності, це трохи складно. Мені подобається намір того, що ви заявляєте, і на перший погляд це звучить як шлях, але я трохи протестував.

Нулі та невизначені незначно відрізняються в javascript. У деяких частинах інтерфейсу матеріалу (не пам'ятаю, де зараз) я передавав нулі, і він не працював належним чином, але не передаючи нічого, змусило його працювати належним чином, отже, всі параметри? .Let < attrib.param = it>навколо місця.

Проблема з атрибутом, який може бути анульований у Kotlin, полягає в тому, що в javascript Котлін перетворює його на нуль, коли він не призначений, а не невизначений. Це відрізняється від визначень машинопису, де реквізити необов’язкові - що відсутнє або невизначене, а не нульове. Ви можете побачити це в наступному прикладі:

Тож спочатку це звучало як гарна ідея, і я насправді пішов і змінив кілька компонентів на нульові, і все, здавалося, працювало нормально, але потім я згадав про проблему, яку я десь надіслав як нуль, як і ці тести., а тести № 2 і 3 можуть викликати деякі проблеми.

Я також базував свій код на інших прикладах, таких як фактичні обгортки kotlin, наприклад. це де вони, здається, не використовують обнулюваний.

Так. Мені ця ідея подобається, але я не впевнений на 100%, якщо це відвідувач. Думаю, ти не часто заглядаєш у підвластивості реквізиту, ти, як правило, перевіряєш рівність його, але часто не йдеш набагато далі, все одно не для реквізиту Інтерфейсу матеріалу. Якщо ви створюєте власні компоненти, це може бути нормально, але передача реквізиту в іншу бібліотеку залежить від того, як вони обробляють реквізити, які є нульовими та невизначеними, і, як уже згадувалося, я знаю один випадок (хоча не знаю, де він: - )), що інтерфейсу матеріалу сподобався невизначений, а не нульовий.

Резюме. це було трохи розмито! Але я думаю, ви підняли важливий момент, який варто обговорити/розслідувати. Я хочу, щоб бібліотека обгортки була якомога кращою, тому, якщо зміна всіх реквізитів на обнулювані зробила б це кращим, я думаю, що це того варте (і це не зайняло багато часу, щоб змінити те, що я зробив до переосмислення) . але переосмисливши це. можливо, це не варто тому, що поведінка будь-якого реквізиту може бути анульована, це означає, що його більше не можна визначити - що спричинить деякі проблеми в інтерфейсі матеріалу (десь).