Comments 8
Дружище -- твой рисунок с подписью " Пример компонента с множеством зависимостей. Так — плохо " это отражение сути ООП и его базовой идеи на которой пляшет React, может ты перечитаешь ещё раз то? ради чего пришёл в отрасль, и перестанешь изгонять главную идею от которой всё идёт -- а подчинишь её себе и начнёшь использовать? Либо уж откажись, выкини ООП и сделай "классно" по-другому ( это возможно, только надо идеи понимать, а не убирать потому что "слооожнААА" )
Давно ли классные идеи, отличные идеи, идеи, просто, для аплодисментов появлялись корнем из бизнеса? Чёт ни одного примера не помню за 30 лет.
Очень надеялся увидеть исходя из заголовка: "Пишем хорошие компоненты, которые захочется переиспользовать, а плохие — не пишем"
Увидеть главное -- ПРИМЕРЫ, как плохо и главное ПОЧЕМУ плохо с ПРАКТИЧЕСКИМ обоснованием, и как ХОРОШО -- с той же базой обоснования. По факту зря потратил время на чтение.
Привет, не очень понял на какой сути ООП пляшет React)
Основная суть статьи в том, что то как ПЛОХО и как ХОРОШО зависит только от конкретного проекта, и выделены критерии по которым можно для себя этот вектор оценки построить. Я понимаю что очень хочется готового решения, но тут серебрянной пули нет, и надо думать в рамках конкретных проектов и задач.
BTW спасибо за коммент, он очень хорошо отражает ожидания :)
Очень полезно! Пошла менять флаги на маппинг и использовать Dependency Injection :)
Компонент сложный если у него нет тестов
Что, простите?! Как эти понятия вообще связаны?
Про Явность конечно в голосину.
Ведь разработчикам так сложно открыть дизайн систему и посмотреть что там за токеном скрывается, или провалиться в типы компонента и посмотреть описание пропа
Такое чувство что статья не дописана. Мне честно говоря тоже не хватило "Хороших" примеров. И если основная суть статьи что всё зависит от конкретного проекта, тогда думаю стоило бы более подробно расписать этот момент (тоже хотелось бы побольше примеров). Пример с ясностью тоже как-то триггернул #xz-cho-za-cvet, по любому лучше primary
Пишем хорошие компоненты, которые захочется переиспользовать, а плохие — не пишем