Выпилить material-ui

[sk1e]

Целевыми приложениями стартер кита являются сложные, кастомные решения которые часто предъявляют уникальные, несовместимые со сторонними решениями требования. Типичный сценарий работы с такими компонентами это подгонка (часто костыльная) под требования и в конечном счёте выкидывание с переписыванием на свои. Предлагаю не тратить в дальнейшем на это время и написать сразу свои компоненты.

[in19farkt]

Вот тут не согласен, я последний год работал в R&D, у нас всё максимально стандартно и на кастомизацию компонент тратится минимум усилий.

Тут можешь посмотреть демки на базе material-ui (я так понимаю от создателей mui) https://themes.material-ui.com. Я уверен, ты там найдешь много "уникальных, несовместимых со сторонними решениями требований".

Предлагаю не тратить в дальнейшем на это время и написать сразу свои компоненты.

Не очень понимаю чем твои компоненты будут отличаться от MUI. Придет бизнес, скажет у нас уникальные требования, и ты точно также эти компоненты отправишь в топку и будешь писать заново)) Поэтому предлагаю не тратить время на написание своих велосипедов, которые еще и поддерживать придется.

[sk1e]

Вот тут не согласен, я последний год работал в R&D, у нас всё максимально стандартно и на кастомизацию компонент тратится минимум усилий.

То что вам подходят эти компоненты не значит что они всем подходят.

Не очень понимаю чем твои компоненты будут отличаться от MUI.

Я буду иметь доступ к компонентам, и буду иметь возможность любым образом изменять внутренности вместо API который мне предоставят. Это совершенно разные вещи.

Придет бизнес, скажет у нас уникальные требования, и ты точно также эти компоненты отправишь в топку и будешь писать заново))

Не понял логики. Почему в топку? Я изменю код настолько насколько изменились требования, также как и с любыми другими компонентами. У mui я не смогу изменить код

Поэтому предлагаю не тратить время на написание своих велосипедов, которые еще и поддерживать придется.

Я больше времени тратить на кастомизацию, чем на написание нового. А писать и поддерживать там нечего особо, компоненты будут минималистичны и написать их за пару дней можно.

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

Свои компоненты - общее решение которое ты сможешь подогнать под любой дизайн. А стартер кит должен иметь возможность подойти именно под любой проект.

Сторонние компоненты ты не подгонишь под любой дизайн и под любые требования. То что был один положительный опыт ещё не значит что он будет таким всегда и у всех. Со своими компонентами у вас тоже был бы положительный опыт. А у меня с mui - нет.

Библиотечные компоненты можно только по согласованию с заказчиком использовать, я считаю. Если он захочет их - ради бога, но пусть в стартер ките лежат компоненты, за которые не будет страшно что в какой-то момент они поломают всё или начнут вести себя странно и я не смогу ничего с этим сделать.

[Znack]

Тут сложный очень вопрос. MUI удобен тогда, когда заказчикам не принципиален внешний вид, главное функциональность. часто у нас как раз такие проекты. Я сам с Ant работаю и рад, что там есть много приколюх, которые мне не надо самому ручками писать и тестировать, просто кинул проп loading, он сам в кнопку с анимацией свг вставил, которая крутится, все круто :) С другой стороны если нужны свои стили, то надо пострадать

[sk1e]

Я думаю что заказчики, которым не принципиален внешний вид не предложат интересные проекты, которые позволят нам развиваться и с гордостью кидать их в портфолио. Внешний вид довольно принципиальная вещь для приложения, которое позиционирует себя инновационным. Элементы интерфейса которые решают конкретные задачи бизнеса должны отдельно проектироваться дизайнером чтобы покрывать эти задачи с максимизацией UX. Элементы которые органично вписываются в дизайн приложения создают важный эффект качественности продукта для пользователей.

Ну и не понимаю страха перед писания руками: вёрстка элементарных компонентов - одна из самых простых вещей которые мы делаем. Я вот не знаю что я быстрее сделаю: напишу свой компонент или подгоню компонент из либы. Это было бы вызовом при использовании какого-нибудь jquery, но на реакте это максимально просто делается.

[in19farkt]

одна из самых простых вещей которые мы делаем

И одна из самых скучных задач, очень быстро надоедает и с каждым новым проектом всё больше демотивирует. Речь именно о базовых компонентах - инпуты/кнопки/табы/сетки и т.д.

[in19farkt]

заказчики, которым не принципиален внешний вид не предложат интересные проекты

на акрополе за базу взят материал, и я бы не сказал, что у нас проекты не интересные, а интерфейсы убогие, потому что из материала взяты базовые компоненты и принципы, и куча интересных компонент написана уже нами.

[sk1e]

одна из самых простых вещей которые мы делаем

И одна из самых скучных задач, очень быстро надоедает и с каждым новым проектом всё больше демотивирует. Речь именно о базовых компонентах - инпуты/кнопки/табы/сетки и т.д.

Меня не демотивирует. Меня демотивируют костыли, которые обрастают вокруг них, рано или поздно, раздутая и ненужная для меня сложность, локальный стейт, который мешает и который нужно учитывать, неследование такими компонентов БЭМу и особенно демотивируют непонятные странности в работе которые становятся понятны только когда залезешь внутрь, что совершенно ломает задачу таких компонентов - абстрагирование от принципа работы компонентов.

[in19farkt]

непонятные странности в работе

тут можно поподробнее? :)

[krashaen]

Если на проекте есть какие то кастомные части интерфейса будь то кнопки или инпуты, мы все равно будем пилить эти кастомные вещи. Тут речь идет именно о быстром старте MVP на мой взгляд. И тут как раз хорошо показывают себя готовые либы, с помощью них мы быстро соберем начальный интерфейс. По поводу своих, я к этой идеи отношусь скептически, так как потратится куча времени на написание компонент, которые в конечном итоге(при условии не тривиального проекта) прийдется перепиливать. А если супер пупер универсальные писать то получится лапша на мой взгляд)

[in19farkt]

которые становятся понятны только когда залезешь внутрь

абсолютно тоже самое очень часто происходит когда ты пытаешь использовать локально написанную компоненту, чтобы понять что именно делает и на что влияет тот или иной пропс, время от времени приходится подглядывать в реализацию компоненты)) Это норма, когда у тебя нет нормальной доки на твои компоненты. В случае если мы используем сторонний юи кит таких подглядываний в сорцы становится наоборот меньше, т.к. обычно есть нормальная дока с примерами использования.

[sk1e]

непонятные странности в работе

тут можно поподробнее? :)

ну вот меня заставили недавно использовать элементы из semantic ui. Я взял там попап который за каким то хером позиционировался с уходом его части за страницу при изменении контента этого попапа. Вот что мне делать в таких случаях? Если бы это был мой компонент я бы легко нашёл проблему и решил бы. А лезть в чужой гораздо сложнее: он тяжёлый, без бэма, без тайпскрипта, без нашего стиля написания кода.

[sk1e]

Если на проекте есть какие то кастомные части интерфейса будь то кнопки или инпуты, мы все равно будем пилить эти кастомные вещи. Тут речь идет именно о быстром старте MVP на мой взгляд. И тут как раз хорошо показывают себя готовые либы, с помощью них мы быстро соберем начальный интерфейс. По поводу своих, я к этой идеи отношусь скептически, так как потратится куча времени на написание компонент, которые в конечном итоге(при условии не тривиального проекта) прийдется перепиливать. А если супер пупер универсальные писать то получится лапша на мой взгляд)

Я писал уже про вёрстку, для меня нет ничего сложно сверстать с нуля. Мне может быть сложнее и дольше подогнать в некоторых случаях имеющийся компонент.

Я как раз хочу не универсальные, а самые базовые компоненты написать. А все детали уже дописывать на реальных проектах.

[sk1e]

абсолютно тоже самое очень часто происходит когда ты пытаешь использовать локально написанную компоненту, чтобы понять что именно делает и на что влияет тот или иной пропс, время от времени приходится подглядывать в реализацию компоненты))

Это зависит от того какой интерфейс спроектирован, если пропсы говорят сами за себя, то никуда лезть не надо будет. Мне вот не нравится интерфейс от других либ. С доками проще, да, но с самоговорящими пропсами ещё проще.

[krashaen]

Я как раз хочу не универсальные, а самые базовые компоненты написать. А все детали уже дописывать на реальных проектах.

ну тут тогда вообще не вижу смысла, сначала тратить время для написания базы, плюс время потом на "подгонку" базы под конкретный проект. Еще раз повторюсь, цель материала не жить с ним, а просто запилить базовую версию на коленке. А для сложных проектов он выкидывается и пишется кастом. То же самое будет и с базой. Поэтому не вижу смысла в этом)

[sk1e]

Я как раз хочу не универсальные, а самые базовые компоненты написать. А все детали уже дописывать на реальных проектах.

ну тут тогда вообще не вижу смысла, сначала тратить время для написания базы, плюс время потом на "подгонку" базы под конкретный проект. Еще раз повторюсь, цель материала не жить с ним, а просто запилить базовую версию на коленке. А для сложных проектов он выкидывается и пишется кастом. То же самое будет и с базой. Поэтому не вижу смысла в этом)

База не будет выкинута, ты из базы быстро сделаешь кастомное. И сделаешь это быстрее по сравнению с использованием mui. То есть ты запилишь этот MVP быстрее: без использования mui и одновременно сделав нормальные компоненты

[in19farkt]

Я писал уже про вёрстку, для меня нет ничего сложно сверстать с нуля. Мне может быть сложнее и дольше подогнать в некоторых случаях имеющийся компонент.

А для меня нет ничего сложного кастомизировать муи. Мне может быть сложнее и дольше верстать компонент с нуля или как-то изменять что-то уже написанное 😂

[in19farkt]

Когда перед тобой стоит задача за пару дней накидать рабочий прототип, последнее чем ты хочешь заниматься это колупаться в кем-то написанных базовых компонентах, которые к тому же пердоставляют минимальное API, нормально не отлажены и не задокументированы (т.к. на каждом проекте приходится их переписывать/дописывать). Желательно даже обойтись без написания стилей, и иметь возможность собрать практически всё на предоставленных компонентах.

Да, API компонент МУИ избыточен, но он покрывает бОльшую часть возможных потребностей, все компоненты отлажены и задокументированы.

[sk1e]

Когда перед тобой стоит задача за пару дней накидать рабочий прототип, последнее чем ты хочешь заниматься это колупаться в кем-то написанных базовых компонентах, которые к тому же пердоставляют минимальное API, нормально не отлажены и не задокументированы (т.к. на каждом проекте приходится их переписывать/дописывать). Желательно даже обойтись без написания стилей, и иметь возможность собрать практически всё на предоставленных компонентах.

Да, API компонент МУИ избыточен, но он покрывает бОльшую часть возможных потребностей, все компоненты отлажены и задокументированы.

Ну видимо мы по-разному код пишем. Я пишу так чтобы мог разобраться в этом максимально быстро и также максимально быстро накинуть туда сверху. Без какой-либо документации.

[in19farkt]

Ну видимо мы по-разному код пишем. Я пишу так чтобы мог разобраться в этом максимально быстро и также максимально быстро накинуть туда сверху. Без какой-либо документации.

Подозреваю что это понятно только тебе, т.к. ты этот код пишешь и уже привык к своему стилю именования/формирования API. Но я напомню, что мы код пишем не для себя, а для того чтобы этот код поддерживали другие программисты, и далеко не каждый из присутствующих в нашей команде настолько постиг дзен именования как ты, чтобы с первого раза и безошибочно по имени пропса понять логику привязанную к нему.

Считать что ты формируешь API компонент и именуешь аки боженька, во-первых - это сильно, во-вторых - мне кажется не корректно, нет одного единственно правильного стиля, не возможно сформировать API так, чтобы поняли абсолютно все и без документации.

P.S. надеюсь понятно, что я не имею ввиду какие-то тривиальные вещи, типа disabled у кнопки

[Znack]

которым не принципиален внешний вид не предложат интересные проекты, которые позволят нам развиваться и с гордостью кидать их в портфолио

Вот тут очень сильное заявление :) Это нормально, что заказчикам нужно запустить какой-то нетривиальный продукт, и нормально, что на первый год-два там будет относительно стандартный дизайн, который в любом случае будет современно выглядеть. Да, он будет некастомизированный, но он будет решать свою задачу и не будет отвлекать на себя лишнее внимание.

[sk1e]

и нормально, что на первый год-два там будет относительно стандартный дизайн, который в любом случае будет современно выглядеть

не согласен. В современном мире, когда в условиях жёсткой конкуренции стартапы выносит за обочину за малейший просчёт, выкатывать приложение со стандартным дизайном на год-два это самоубийство (пруфов конечно не будет). Если идея не совершенно новая. В чём проблема нормальный дизайн сделать? Это недорого же.

[Znack]

На самом деле долго и дорого :)

выкатывать приложение со стандартным дизайном на год-два это самоубийство (пруфов конечно не будет)

ну во многих сферах ты пруфов и не найдешь :) Достаточно будет одного примера успешного стартапа, который юзал MUI или что-то подобное, чтобы твои пруфы опровергнуть

[sk1e]

На самом деле долго и дорого :)

Почему это? Всё что нужно - это один толковый дизайнер. С нашей стороны, наоборот, дешевле в средней и дальней перспективе будет, когда костыли сказываться начнут.

Достаточно будет одного примера успешного стартапа, который юзал MUI или что-то подобное, чтобы твои пруфы опровергнуть

ну ок, переформулирую: стартапы, не имеющие уникальной идеи и незаморачивающиеся над дизайном будут иметь большую тенденцию к разорению по сравнению со стартапами, которые заморочились над дизайном. Исключения возможны конечно.

[Znack]

Ну вот одного толкового дизайнера в команду подключить — это уже долго и дорого. И не факт, что этого будет достаточно.

По стартапам теперь формулировка такая, что "если делать лучше, то шансов на успех больше, чем когда ты делаешь хуже" — в целом я с этим согласен :) Проблема только в приоритетах осталась. Действительно ли сосредоточенность на уникальном дизайне, который не основан ни на MUI, ни на других подобных решениях, сильнее поможет достичь успеха, чем остальные

[in19farkt]

Я вот не понимаю чем Наш уникальный дизайн в стартер ките, поможет при старте каких-то проектов заказчика, в которых есть Свой уникальный дизайн? Уникальный дизайн наверное подразумевает какие-то не стандартные дизайнерские решения, которых ты не найдешь в UI-библиотеках, соответственно чтобы мы не написали, нам придется писать всё заново.

Если клиент хочет уникальный дизайн, значит он готов платить за реализацию этого дизайна, готов тратить на это время и деньги, значит мы спокойно можем напилить ui kit с нуля, так как нам этого хочется. В таком случае просто выпиливаем MUI из проекта (10 минут) и пишем с нуля, возможно сразу в отдельном репозитории создаем UI кит, который можно будет переиспользовать в других проектах клиента.

А вот если сроки жмут или дизайн не уникальный и совместим с MUI мы можем выделить одного человека, который все основные элементы закостомизирует за пару дней и дальше вся команда сможет на их основе напиливать функционал. Даже не так, выделяем одного человека, который кастомизирует, а остальная команда используя пока еще не кастомизированные элементы параллельно начинаю пилить функционал.

[in19farkt]

А рассуждать по поводу эффективности запуска каких-то там стартапов в зависимости от дизайна их продукта, мне кажется может человек, обладающий таким опытом и запустивший как минимум штук 10 разных стартапов с разным подходом к разработке фронта, при этом подход ко всему остальному должен быть идентичным, для чистоты эксперимента (возможно конечно, Серег, мы что-то про тебя не знаем, и у тебя такой опыт имеется 🙂). По мне так дизайн фронта далеко не самая важная вещь при запуске продукта, есть огромное кол-во других факторов из-за которых проект может прогореть.

[sk1e]

Я вот не понимаю чем Наш уникальный дизайн в стартер ките, поможет при старте каких-то проектов заказчика, в которых есть Свой уникальный дизайн?

так я ж писал два раза уже, что не уникальный, а базовый. Надо было в исходном тексте конечно это написать. Т.е. в компонентах есть состояния которые будут в любом дизайне, обработка событий которая будет в любом дизайне. hover, disabled, active в кнопках, работа с DOMом связанная с состояниям селекта, бегунок со своим состоянием и рельса в слайдере, группа табов с состоянием выбранного, событием выбора нового. Всё то, без чего такие элементы не имеют смысл и что является частью их определения. Имея базовую реализацию, где всё это реализовано хорошо, дописать недостающие части будет намного проще.

Если клиент хочет уникальный дизайн, значит он готов платить за реализацию этого дизайна, готов тратить на это время и деньги, значит мы спокойно можем напилить ui kit с нуля, так как нам этого хочется.

вот для таких случаев и нужны эти компоненты, чтобы с нуля не писать

А вот если сроки жмут или дизайн не уникальный и совместим с MUI мы можем выделить одного человека, который все основные элементы закостомизирует за пару дней и дальше вся команда сможет на их основе напиливать функционал. Даже не так, выделяем одного человека, который кастомизирует, а остальная команда используя пока еще не кастомизированные элементы параллельно начинаю пилить функционал.

И для таких случаев можно использовать. Также можно выделить одного человека, который кастомизирует, пока остальная команда использует некастомизированные. Посыл в том что усилия по кастомизации примерно равны будут, но вероятность сесть в лужу со своими - ноль, с MUI - больше нуля.

А рассуждать по поводу эффективности запуска каких-то там стартапов в зависимости от дизайна их продукта, мне кажется может человек, обладающий таким опытом и запустивший как минимум штук 10 разных стартапов с разным подходом к разработке фронта, при этом подход ко всему остальному должен быть идентичным

не согласен. Достаточно понимать основы понятия конкуренция и основы психологии пользователя при работе с приложением. Необязательно запускать стартапы, чтобы понять, что при прочих равных пользователь выберет продукт, где ему удобней работать и где глазам приятней смотреть. И запуск 10 разных стартапов никак не проверит эту гипотезу, потому что стартап характеризуется множеством других переменных, которые нельзя оценить количественно. Стартапов я не открывал и не позиционирую себя специалистом в этой области, но к таким основам несложно прийти, я считаю.

И вообще, обсуждение по стартапам не имеет смысла. В любом случае не нам определять стратегию развития. Если нам скажут «хотим много кастомного» то реализация своих компонентов с базовой функциональностью отлично поможет. Если скажут «хотим быстрее», то тут уже можно выбрать. Что тут лучше выбрать - вопрос. Мне бы точно проще со своими было. Другим возможно будет проще c MUI. Но свои компоненты покрывают все случаи и являются универсальным решением, в отличие от MUI. Я бы выпилил MUI, но можно и продублировать эти компоненты и решать уже самостоятельно от проекта к проекту.

[Znack]

А можем ли мы вынести набор базовых компонент просто в отдельную импортируемую библиотеку? Нам точно надо это именно в starter kit держать? Если нужно будет, кто-то потом себе её скопирует в проект и будет там перелопачивать как удобно. А у нас будет отдельная репа, где чисто эти базовые компоненты, отдельный набор ишьюсов и пулл реквестов по ним (а я думаю, что там много этого понадобится). И чтобы это как отдельный проект начинать, нам надо внутри команды чётко проанализировать, насколько в этом есть потребность — на каких проектах требовался кастомный дизайн и какие там были сроки (во внутреннем чате обсудим)

[in19farkt]

в отдельную импортируемую библиотеку

Делать ее импортируемой наверное нет смысла, т.к. возникнут всё те же проблемы с ~кастылизацией~ кастомизацией, а если базовые стили будут на scss, то эти проблемы будут намного более весомые.

Если нужно будет, кто-то потом себе её скопирует в проект и будет там перелопачивать как удобно

А вот это уже ближе к правде)) получается нужен репозиторий с драфтами компонент, кому какую компоненту нужно, тот ту компоненту копипастит в свой проект. Там же можно настроить какой-нибудь react-styleguidist или что-то подобное, чтобы можно было быстро поклацать имеющиеся компоненты.

[sk1e]

А можем ли мы вынести набор базовых компонент просто в отдельную импортируемую библиотеку? Нам точно надо это именно в starter kit держать?

Их смысл именно в том чтобы можно было лезть в код. Вне стартер кита это неудобно разрабатывать и поддерживать будет: на них же смотреть нужно.

Есть вариант с двумя ветками стартеркита: с MUI и с базовыми. В мастере можно оставить MUI, т.к. он симпатичнее. Если ветки только на эти компоненты различаться будут то проблем с поддержкой двух веток не должно возникнуть.

[Znack]

на них же смотреть нужно.

Так Storybook же :)

[Znack]

Есть вариант с двумя ветками стартеркита: с MUI и с базовыми

ветки поддерживать больно, я сразу вангую, что это провальная стратегия. Все ПР будут делать в мастер и все будут забывать про вторую ветку, и никто не будет хотеть её поддерживать :)

[sk1e]

Есть вариант с двумя ветками стартеркита: с MUI и с базовыми

ветки поддерживать больно, я сразу вангую, что это провальная стратегия. Все ПР будут делать в мастер и все будут забывать про вторую ветку, и никто не будет хотеть её поддерживать :)

Ну и пусть. Кому нужно - тот просто вмержит мастер. Значительных конфликтов при минимальной разнице быть не должно

[in19farkt]

ветки поддерживать больно, я сразу вангую, что это провальная стратегия.

Да, так и есть, уже был такой опыт, лучше этого избежать :)

[chmnkh]

Я отлично понимаю боль Сереги Петрова при работе с такими либами: я, например, недавно на даталайте рефакторил селекты, и действительно бывают случаи, когда какая-то нужная тебе кастомизация делается через какие-то уродские костыли, притом эти костыли не всегда удается использовать в контексте проекта, и в итоге приходится один фиг с нуля писать. Плюс, недавно был баг в MUI, фикс-костыль для которого мне другую фигню ломал, у меня тоже из-за этого дырка в стуле была.

Теперь часть с НО: мне кажется, что учитывая жопоболь, которая действительно может возникать и иногда возникает, надо все равно взвешивать + и -, и, пока что, если у людей в целом положительных впечатлений больше от использования таких библиотек, чем отрицательных, то смотреть на такие проблемы стоит как на трейдоффы. Я считаю, что подобная боль возникает достаточно редко для того, чтобы такие проблемы точечно решать (писать свои компоненты, как вариант), а не заведомо добавлять себе кучу работы, отказываясь от муи, потому что один фиг, чтобы написать более универсальную библиотеку - это надо гору времени потратить, и один фиг, там в итоге все те же проблемы останутся, что в каких-то случаях универсальности недостаточно.

[kinda-neat]

Я поддерживаю такой вариант: оставляем mui, Серега пишет самостоятельно несколько компонент (кнопка, селект, поповер, что у нас тут самое заменяемое?) и оформляет их отдельным пакетом/репой для того чтобы люди, у которых возникнет потребность в написании своей компоненты могли изи взять и заюзать ее, тем самым получим фидбэк от тех кто использовал самописные компоненты

[kinda-neat]

Я отлично понимаю боль Сереги Петрова при работе с такими либами: я, например, недавно на даталайте рефакторил селекты, и действительно бывают случаи, когда какая-то нужная тебе кастомизация делается через какие-то уродские костыли, притом эти костыли не всегда удается использовать в контексте проекта, и в итоге приходится один фиг с нуля писать. Плюс, недавно был баг в MUI, фикс-костыль для которого мне другую фигню ломал, у меня тоже из-за этого дырка в стуле была.

тут еще стоит отметить рофл с тем, что на даталайте версия mui 1.4.2, а актуальная 4.5.1, потенциально не было бы тех костылей, если бы чуваки обновлялись своевременно, и тут это еще один минус в копилку готовых либ, что их надо обновлять))) не видел еще людей, которые бы обновляли либы с компонентами/готовыми графиками и прочими штуками на которых обычно держится проект. Не обновлять такие core либы - как бомба замедленного действия, когда понадобится что-то подправить - тайпинги старые, апи изменилось, все плохо, обновляешься - все падает :(