Выпилить material-ui #136
Comments
|
Вот тут не согласен, я последний год работал в R&D, у нас всё максимально стандартно и на кастомизацию компонент тратится минимум усилий. Тут можешь посмотреть демки на базе material-ui (я так понимаю от создателей mui) https://themes.material-ui.com. Я уверен, ты там найдешь много "уникальных, несовместимых со сторонними решениями требований".
Не очень понимаю чем твои компоненты будут отличаться от MUI. Придет бизнес, скажет у нас уникальные требования, и ты точно также эти компоненты отправишь в топку и будешь писать заново)) Поэтому предлагаю не тратить время на написание своих велосипедов, которые еще и поддерживать придется. |
То что вам подходят эти компоненты не значит что они всем подходят.
Я буду иметь доступ к компонентам, и буду иметь возможность любым образом изменять внутренности вместо API который мне предоставят. Это совершенно разные вещи.
Не понял логики. Почему в топку? Я изменю код настолько насколько изменились требования, также как и с любыми другими компонентами. У mui я не смогу изменить код
Я больше времени тратить на кастомизацию, чем на написание нового. А писать и поддерживать там нечего особо, компоненты будут минималистичны и написать их за пару дней можно. Помимо этого, сторонние компоненты, как правило имеют локальный стейт, раздутое апи, большое количество вёрстки учитывающее все кейсы на которые рассчитаны и потенциальные баги которые ты не сможешь решить самостоятельно. Свои компоненты - общее решение которое ты сможешь подогнать под любой дизайн. А стартер кит должен иметь возможность подойти именно под любой проект. Сторонние компоненты ты не подгонишь под любой дизайн и под любые требования. То что был один положительный опыт ещё не значит что он будет таким всегда и у всех. Со своими компонентами у вас тоже был бы положительный опыт. А у меня с mui - нет. Библиотечные компоненты можно только по согласованию с заказчиком использовать, я считаю. Если он захочет их - ради бога, но пусть в стартер ките лежат компоненты, за которые не будет страшно что в какой-то момент они поломают всё или начнут вести себя странно и я не смогу ничего с этим сделать. |
|
Тут сложный очень вопрос. MUI удобен тогда, когда заказчикам не принципиален внешний вид, главное функциональность. часто у нас как раз такие проекты. Я сам с Ant работаю и рад, что там есть много приколюх, которые мне не надо самому ручками писать и тестировать, просто кинул проп |
|
Я думаю что заказчики, которым не принципиален внешний вид не предложат интересные проекты, которые позволят нам развиваться и с гордостью кидать их в портфолио. Внешний вид довольно принципиальная вещь для приложения, которое позиционирует себя инновационным. Элементы интерфейса которые решают конкретные задачи бизнеса должны отдельно проектироваться дизайнером чтобы покрывать эти задачи с максимизацией UX. Элементы которые органично вписываются в дизайн приложения создают важный эффект качественности продукта для пользователей. Ну и не понимаю страха перед писания руками: вёрстка элементарных компонентов - одна из самых простых вещей которые мы делаем. Я вот не знаю что я быстрее сделаю: напишу свой компонент или подгоню компонент из либы. Это было бы вызовом при использовании какого-нибудь jquery, но на реакте это максимально просто делается. |
И одна из самых скучных задач, очень быстро надоедает и с каждым новым проектом всё больше демотивирует. Речь именно о базовых компонентах - инпуты/кнопки/табы/сетки и т.д. |
на акрополе за базу взят материал, и я бы не сказал, что у нас проекты не интересные, а интерфейсы убогие, потому что из материала взяты базовые компоненты и принципы, и куча интересных компонент написана уже нами. |
Меня не демотивирует. Меня демотивируют костыли, которые обрастают вокруг них, рано или поздно, раздутая и ненужная для меня сложность, локальный стейт, который мешает и который нужно учитывать, неследование такими компонентов БЭМу и особенно демотивируют непонятные странности в работе которые становятся понятны только когда залезешь внутрь, что совершенно ломает задачу таких компонентов - абстрагирование от принципа работы компонентов. |
тут можно поподробнее? :) |
|
Если на проекте есть какие то кастомные части интерфейса будь то кнопки или инпуты, мы все равно будем пилить эти кастомные вещи. Тут речь идет именно о быстром старте MVP на мой взгляд. И тут как раз хорошо показывают себя готовые либы, с помощью них мы быстро соберем начальный интерфейс. По поводу своих, я к этой идеи отношусь скептически, так как потратится куча времени на написание компонент, которые в конечном итоге(при условии не тривиального проекта) прийдется перепиливать. А если супер пупер универсальные писать то получится лапша на мой взгляд) |
абсолютно тоже самое очень часто происходит когда ты пытаешь использовать локально написанную компоненту, чтобы понять что именно делает и на что влияет тот или иной пропс, время от времени приходится подглядывать в реализацию компоненты)) Это норма, когда у тебя нет нормальной доки на твои компоненты. В случае если мы используем сторонний юи кит таких подглядываний в сорцы становится наоборот меньше, т.к. обычно есть нормальная дока с примерами использования. |
ну вот меня заставили недавно использовать элементы из semantic ui. Я взял там попап который за каким то хером позиционировался с уходом его части за страницу при изменении контента этого попапа. Вот что мне делать в таких случаях? Если бы это был мой компонент я бы легко нашёл проблему и решил бы. А лезть в чужой гораздо сложнее: он тяжёлый, без бэма, без тайпскрипта, без нашего стиля написания кода. |
Я писал уже про вёрстку, для меня нет ничего сложно сверстать с нуля. Мне может быть сложнее и дольше подогнать в некоторых случаях имеющийся компонент. Я как раз хочу не универсальные, а самые базовые компоненты написать. А все детали уже дописывать на реальных проектах. |
Это зависит от того какой интерфейс спроектирован, если пропсы говорят сами за себя, то никуда лезть не надо будет. Мне вот не нравится интерфейс от других либ. С доками проще, да, но с самоговорящими пропсами ещё проще. |
ну тут тогда вообще не вижу смысла, сначала тратить время для написания базы, плюс время потом на "подгонку" базы под конкретный проект. Еще раз повторюсь, цель материала не жить с ним, а просто запилить базовую версию на коленке. А для сложных проектов он выкидывается и пишется кастом. То же самое будет и с базой. Поэтому не вижу смысла в этом) |
База не будет выкинута, ты из базы быстро сделаешь кастомное. И сделаешь это быстрее по сравнению с использованием mui. То есть ты запилишь этот MVP быстрее: без использования mui и одновременно сделав нормальные компоненты |
А для меня нет ничего сложного кастомизировать муи. Мне может быть сложнее и дольше верстать компонент с нуля или как-то изменять что-то уже написанное 😂 |
|
Когда перед тобой стоит задача за пару дней накидать рабочий прототип, последнее чем ты хочешь заниматься это колупаться в кем-то написанных базовых компонентах, которые к тому же пердоставляют минимальное API, нормально не отлажены и не задокументированы (т.к. на каждом проекте приходится их переписывать/дописывать). Желательно даже обойтись без написания стилей, и иметь возможность собрать практически всё на предоставленных компонентах. Да, API компонент МУИ избыточен, но он покрывает бОльшую часть возможных потребностей, все компоненты отлажены и задокументированы. |
Ну видимо мы по-разному код пишем. Я пишу так чтобы мог разобраться в этом максимально быстро и также максимально быстро накинуть туда сверху. Без какой-либо документации. |
Подозреваю что это понятно только тебе, т.к. ты этот код пишешь и уже привык к своему стилю именования/формирования API. Но я напомню, что мы код пишем не для себя, а для того чтобы этот код поддерживали другие программисты, и далеко не каждый из присутствующих в нашей команде настолько постиг дзен именования как ты, чтобы с первого раза и безошибочно по имени пропса понять логику привязанную к нему. Считать что ты формируешь API компонент и именуешь аки боженька, во-первых - это сильно, во-вторых - мне кажется не корректно, нет одного единственно правильного стиля, не возможно сформировать API так, чтобы поняли абсолютно все и без документации. P.S. надеюсь понятно, что я не имею ввиду какие-то тривиальные вещи, типа disabled у кнопки |
Вот тут очень сильное заявление :) Это нормально, что заказчикам нужно запустить какой-то нетривиальный продукт, и нормально, что на первый год-два там будет относительно стандартный дизайн, который в любом случае будет современно выглядеть. Да, он будет некастомизированный, но он будет решать свою задачу и не будет отвлекать на себя лишнее внимание. |
не согласен. В современном мире, когда в условиях жёсткой конкуренции стартапы выносит за обочину за малейший просчёт, выкатывать приложение со стандартным дизайном на год-два это самоубийство (пруфов конечно не будет). Если идея не совершенно новая. В чём проблема нормальный дизайн сделать? Это недорого же. |
|
На самом деле долго и дорого :)
ну во многих сферах ты пруфов и не найдешь :) Достаточно будет одного примера успешного стартапа, который юзал MUI или что-то подобное, чтобы твои пруфы опровергнуть |
Почему это? Всё что нужно - это один толковый дизайнер. С нашей стороны, наоборот, дешевле в средней и дальней перспективе будет, когда костыли сказываться начнут.
ну ок, переформулирую: стартапы, не имеющие уникальной идеи и незаморачивающиеся над дизайном будут иметь большую тенденцию к разорению по сравнению со стартапами, которые заморочились над дизайном. Исключения возможны конечно. |
|
Ну вот одного толкового дизайнера в команду подключить — это уже долго и дорого. И не факт, что этого будет достаточно. По стартапам теперь формулировка такая, что "если делать лучше, то шансов на успех больше, чем когда ты делаешь хуже" — в целом я с этим согласен :) Проблема только в приоритетах осталась. Действительно ли сосредоточенность на уникальном дизайне, который не основан ни на MUI, ни на других подобных решениях, сильнее поможет достичь успеха, чем остальные |
|
Я вот не понимаю чем Наш уникальный дизайн в стартер ките, поможет при старте каких-то проектов заказчика, в которых есть Свой уникальный дизайн? Уникальный дизайн наверное подразумевает какие-то не стандартные дизайнерские решения, которых ты не найдешь в UI-библиотеках, соответственно чтобы мы не написали, нам придется писать всё заново. Если клиент хочет уникальный дизайн, значит он готов платить за реализацию этого дизайна, готов тратить на это время и деньги, значит мы спокойно можем напилить ui kit с нуля, так как нам этого хочется. В таком случае просто выпиливаем MUI из проекта (10 минут) и пишем с нуля, возможно сразу в отдельном репозитории создаем UI кит, который можно будет переиспользовать в других проектах клиента. А вот если сроки жмут или дизайн не уникальный и совместим с MUI мы можем выделить одного человека, который все основные элементы закостомизирует за пару дней и дальше вся команда сможет на их основе напиливать функционал. Даже не так, выделяем одного человека, который кастомизирует, а остальная команда используя пока еще не кастомизированные элементы параллельно начинаю пилить функционал. |
|
А рассуждать по поводу эффективности запуска каких-то там стартапов в зависимости от дизайна их продукта, мне кажется может человек, обладающий таким опытом и запустивший как минимум штук 10 разных стартапов с разным подходом к разработке фронта, при этом подход ко всему остальному должен быть идентичным, для чистоты эксперимента (возможно конечно, Серег, мы что-то про тебя не знаем, и у тебя такой опыт имеется 🙂). По мне так дизайн фронта далеко не самая важная вещь при запуске продукта, есть огромное кол-во других факторов из-за которых проект может прогореть. |
так я ж писал два раза уже, что не уникальный, а базовый. Надо было в исходном тексте конечно это написать. Т.е. в компонентах есть состояния которые будут в любом дизайне, обработка событий которая будет в любом дизайне. hover, disabled, active в кнопках, работа с DOMом связанная с состояниям селекта, бегунок со своим состоянием и рельса в слайдере, группа табов с состоянием выбранного, событием выбора нового. Всё то, без чего такие элементы не имеют смысл и что является частью их определения. Имея базовую реализацию, где всё это реализовано хорошо, дописать недостающие части будет намного проще.
вот для таких случаев и нужны эти компоненты, чтобы с нуля не писать
И для таких случаев можно использовать. Также можно выделить одного человека, который кастомизирует, пока остальная команда использует некастомизированные. Посыл в том что усилия по кастомизации примерно равны будут, но вероятность сесть в лужу со своими - ноль, с MUI - больше нуля.
не согласен. Достаточно понимать основы понятия конкуренция и основы психологии пользователя при работе с приложением. Необязательно запускать стартапы, чтобы понять, что при прочих равных пользователь выберет продукт, где ему удобней работать и где глазам приятней смотреть. И запуск 10 разных стартапов никак не проверит эту гипотезу, потому что стартап характеризуется множеством других переменных, которые нельзя оценить количественно. Стартапов я не открывал и не позиционирую себя специалистом в этой области, но к таким основам несложно прийти, я считаю. И вообще, обсуждение по стартапам не имеет смысла. В любом случае не нам определять стратегию развития. Если нам скажут «хотим много кастомного» то реализация своих компонентов с базовой функциональностью отлично поможет. Если скажут «хотим быстрее», то тут уже можно выбрать. Что тут лучше выбрать - вопрос. Мне бы точно проще со своими было. Другим возможно будет проще c MUI. Но свои компоненты покрывают все случаи и являются универсальным решением, в отличие от MUI. Я бы выпилил MUI, но можно и продублировать эти компоненты и решать уже самостоятельно от проекта к проекту. |
|
А можем ли мы вынести набор базовых компонент просто в отдельную импортируемую библиотеку? Нам точно надо это именно в starter kit держать? Если нужно будет, кто-то потом себе её скопирует в проект и будет там перелопачивать как удобно. А у нас будет отдельная репа, где чисто эти базовые компоненты, отдельный набор ишьюсов и пулл реквестов по ним (а я думаю, что там много этого понадобится). И чтобы это как отдельный проект начинать, нам надо внутри команды чётко проанализировать, насколько в этом есть потребность — на каких проектах требовался кастомный дизайн и какие там были сроки (во внутреннем чате обсудим) |
Делать ее импортируемой наверное нет смысла, т.к. возникнут всё те же проблемы с
А вот это уже ближе к правде)) получается нужен репозиторий с драфтами компонент, кому какую компоненту нужно, тот ту компоненту копипастит в свой проект. Там же можно настроить какой-нибудь react-styleguidist или что-то подобное, чтобы можно было быстро поклацать имеющиеся компоненты. |
Их смысл именно в том чтобы можно было лезть в код. Вне стартер кита это неудобно разрабатывать и поддерживать будет: на них же смотреть нужно. Есть вариант с двумя ветками стартеркита: с MUI и с базовыми. В мастере можно оставить MUI, т.к. он симпатичнее. Если ветки только на эти компоненты различаться будут то проблем с поддержкой двух веток не должно возникнуть. |
Так Storybook же :) |
ветки поддерживать больно, я сразу вангую, что это провальная стратегия. Все ПР будут делать в мастер и все будут забывать про вторую ветку, и никто не будет хотеть её поддерживать :) |
Ну и пусть. Кому нужно - тот просто вмержит мастер. Значительных конфликтов при минимальной разнице быть не должно |
Да, так и есть, уже был такой опыт, лучше этого избежать :) |
|
Я отлично понимаю боль Сереги Петрова при работе с такими либами: я, например, недавно на даталайте рефакторил селекты, и действительно бывают случаи, когда какая-то нужная тебе кастомизация делается через какие-то уродские костыли, притом эти костыли не всегда удается использовать в контексте проекта, и в итоге приходится один фиг с нуля писать. Плюс, недавно был баг в MUI, фикс-костыль для которого мне другую фигню ломал, у меня тоже из-за этого дырка в стуле была. Теперь часть с НО: мне кажется, что учитывая жопоболь, которая действительно может возникать и иногда возникает, надо все равно взвешивать + и -, и, пока что, если у людей в целом положительных впечатлений больше от использования таких библиотек, чем отрицательных, то смотреть на такие проблемы стоит как на трейдоффы. Я считаю, что подобная боль возникает достаточно редко для того, чтобы такие проблемы точечно решать (писать свои компоненты, как вариант), а не заведомо добавлять себе кучу работы, отказываясь от муи, потому что один фиг, чтобы написать более универсальную библиотеку - это надо гору времени потратить, и один фиг, там в итоге все те же проблемы останутся, что в каких-то случаях универсальности недостаточно. |
|
Я поддерживаю такой вариант: оставляем mui, Серега пишет самостоятельно несколько компонент (кнопка, селект, поповер, что у нас тут самое заменяемое?) и оформляет их отдельным пакетом/репой для того чтобы люди, у которых возникнет потребность в написании своей компоненты могли изи взять и заюзать ее, тем самым получим фидбэк от тех кто использовал самописные компоненты |
тут еще стоит отметить рофл с тем, что на даталайте версия mui 1.4.2, а актуальная 4.5.1, потенциально не было бы тех костылей, если бы чуваки обновлялись своевременно, и тут это еще один минус в копилку готовых либ, что их надо обновлять))) не видел еще людей, которые бы обновляли либы с компонентами/готовыми графиками и прочими штуками на которых обычно держится проект. Не обновлять такие core либы - как бомба замедленного действия, когда понадобится что-то подправить - тайпинги старые, апи изменилось, все плохо, обновляешься - все падает :( |
Целевыми приложениями стартер кита являются сложные, кастомные решения которые часто предъявляют уникальные, несовместимые со сторонними решениями требования. Типичный сценарий работы с такими компонентами это подгонка (часто костыльная) под требования и в конечном счёте выкидывание с переписыванием на свои. Предлагаю не тратить в дальнейшем на это время и написать сразу свои компоненты.
The text was updated successfully, but these errors were encountered: