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

Коментарі

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

відсутня

кароль-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-компоненту, але це можна вирішити змушуючи передавати їх через аргументи методу створення (