Интересная статья, освежить универские давно забытые знания. На мой взгляд, лучше бы смотрелись графики вместо анимаций. На координатор оси оно нагляднее
через 5 лет может и проекта этого уже не будет, и состав команды сменится не один раз, а может быть вообще сменится вектор роста проекта и вся ваша дорогая архитектура улетит в трубу. И останутся только довольные разработчики с чистой совестью и инвестор с дыркой от бублика вместо бюджета. но зато в гите будет дорогой и идеально спроектированный код
Ты просишь реально вдумчивых доводов, упрекнул меня в том что я тебе выдал суповой набор клише, а сам аргументируешь свое мнение мемасами? Серьёзно? Я не вижу смысла дальше вести диалог.
Неужели это настолько неочевидно? Вспомнить хотя бы почему все mvp по качеству кода полная шляпа. У разрабов одна болезнь - технический перфекционизм, пока они строят абстракции и пишут эффективный код, время уходит, а кривущий кусок гавнакода уже проверяет бизнес идею на проде. Это что касается мешает. При этом так же не понятно как навык настройки кубернетиса может помочь в привлечении клиентов на продукт и построении воронки
самая большая проблема fsd, что он по своей сути идет от UI. т.е. текущий макет интерфейса диктует вам как и из чего будут состоять фичи. поэтому каждое изменение структуры макета ui интерфейса, делает ваши фичи и слайсы, виджеты не консистентными к приложению. Я сам с этим сталкивался, решается двумя путями - забить и страдать или овертаймами работ по синхронизации всего этого дела. Говоря математическим языком, core_logic = f(ui), что само по себе не лепо, тк это аналогично ситуации, когда выбор шаблонизатора, определял схему данных бд. FSD запрещает кроссфича импорты, заявляя что это как своего рода инкапсуляцию, но по факту одна фича в другую может проникнуть по средствам какого нибудь селектора слайса одной модели в другую. как пример - была форма многоэкранная, на первом экране была фича принимашая строковый адрес, на втором экране фича которая рисовала адрес на карте. и они были друг на друга завязаны, типы и селекторы приходилось дублировать, что бы соблюсти запрет кросс импртов, но это потом стрельнуло нам, когда мы забыли пофиксить один из селекторов, при смене справочника адресов. При переходе вашего проекта из состояния среднего к большому 100% будете резать свои фичи на микрофронты, и удивитесь что они не отрежутся, там будет сильная зависимость от окружения. Когда всеже в микрофронтах вы избавитесь от fsd, вы удивитесь что и на хостовом приложении от него ничего не осталось, тогда возникает вопрос - зачем оно все это нужно??? Зачем тащить на малые приложения фсд, если для личного блога или магазина хватит иерархии components, hooks, hocs, store. Мне не очень понятно ваше рвение защищать этот подход, он действительно мертворожденный и я считаю его выбор абсолютно безграмотным с точки зрения архитектуры, его выбор просто докажет что разработчик имеет узкий кругозор и мизерную насмотренность. Исключительно мое мнение, прошу не принимать его как оскорбление, а воспринимать как возможную зону роста в будущем. Вы можете возразить на каждый из тезисов, что нужно было бы в каждом случае делать то то или это, я категорически не согласен. Архитектура приложения должна быть интуитивно понятной, а не обьясняться документацией которая сама себе противоречит местами и живет в вакууме
Тут проблема не в FSD а диких требованиях бизнеса если вам понадобилось перемещать целый widget в features. Ну либо в изначальной ошибке. И подобные изменение в любой методологии потребуют кучу изменений
Как раз в этом и есть проблема FSD проектов находящихся на этапе перехода бизнеса от малого к среднему. FSD не адаптируем. Хорошая архитектура в буквальном смысле ждет изменений. фичи, слайсы, виджеты, как по мне это сущности приятнутые за уши и прибитые гвоздями к компонентам. Отсюда и проблема, что когда статус компонента меняется, становится непонятно что с ним делать. начинает или течь абстракция или лететь костыли. Слоистая архитектура в ствязке с атомик дизайном(как пример) в этом плане сильно гибче. Можете менять ядро системы, а ui и знать об этом не будет
Для малых проектов fsd это оверхед, для больших превращается в один большой головняк из за протекания абстракций и дублирования кода. Создаётся впечатление, что fsd придумали просто потому что нужно было что то придумать, для людей которые с трудом осилили(или нет) документацию своего стека, что бы они могли почувствовать себя архитектороми приложениий
Воспринимайте хуки не как конечную точку описания бизнеслогики, а как binder, или провайдер данных из ядра, на слой реакта. На реакт хорошо ложится паттерн mvvm или слоистая архитектура. Всё что вам нужно, это вытащить в хук readonly интерфейс и забиндить на стейт только то что нужно для отрисовки.
И начинается путь любого проекта в неподдердиваемого монстра, без архитектуры, договоренностей, границ ответственности и т.п. тащить туда fsd и ddd, по моему мнению, глупость полнейшая, у этих подходов разночтений столько, что люди внутри команды могут одно и тоже по разному сделать. Этим как раз ангуляр и хорошо, что в базовой своей поставке буквально пальцем тыкать, что где тодолжно быть. Плохо это или хорошо? На мой взгляд это хорошо, если кому то это мешает, то скорее всего ему нужно было выбрать реакт или вью
На самом деле меняется, классы, хуки, несколько смен алгоритмов работы апдейтов виртуального дома. А вот именно базового подхода к разработки в вебер нехватало, тут солидарен
Ангуляр вам буквально связывает руки требованием соблюдать его архитектуру, по сути, на нем трудно написать плохо. В то время как реакт это именно библиотека для обновления вьюхи вашего приложения. Вы можете вокруг этого построить любую архитектуру. Если вы делаете приложение корпоративного уровня на шару, без архитектуры и вам мешает реакт. То разочарую вас, мешает не реакт а отсутствие навыков
Хочу поинтересоваться, без агрессии, исключительно из любопытства. Зачем в вузе изучать то, что меняется с каждым повышением версии? Эти вещи самому при желании и наличии фундаментальный базы раскапываются за несколько недель ковыряния исходников
Игры знатно деградировали в целом. Запускал недавно asassins creed 2, боевка, а точнее фектование там ощущается как бой живых людей, ненавязчивые парирования и добивания не режут глаз, после этого мираж ощущается искусственно, какие то болванчики с заранее записаной анимацией и парированием в тайминг а-ля плохо собраный сосалик. Эталон физики был вообще в alone in the dark 2008 года, если правильно помню. Там огнём и огнетушителем можно было вынести любую закрытую дверь, а электричеством можно было замыкать электронику и воду как в биошоке. Иногда мне кажется, что для успеха в геймдеве, достаточно просто постараться скопировать механики игр 2004-2010 годов, и ты уже будешь выделяться на фоне всего конвеерного шлака
Мне больше интересно посмотреть на тесты, которые бы сравнивали скорость вмонтирования и отмонтирования узлов с большим количеством дочерних элементов. Например тех же списков фиксированной длинны. Т.к. большая часть задач, которые решают реакт либой это сайдбары, дропдауны, аккордеоны, модалки и т.п. Ваш пример про биржи, как мне кажется не совсем подходящий, потому что для максимальной скорости я бы выбрал кастомное решение заточенное на скорость или вообще canvas.
Любопытно сравнивать скорость работы фреймворков на синтетических тестах, которые неимеют отношения к реальной разработке. Неразу нехочу никого задеть, я за прогресс. Но как мне кажется, выбор способа сравнения неподходящий
Скажу одно не популярное мнение. Для людей которые топят за фреймворки, которые точечно работабт с Dom, не очевиден факт, что разметка меняется не точечными узлами, а блоками, и там уже не важно, работает там какой то умный алгоритм рассчета изменений или происходит маппинг с виртуального дома. Разница в перформансе в этом случае практически отсутствует для конечного пользователя приложения. Поэтому команды выбирают реакт по причине быстрого онбординга, простого апи и бесконечного количества готовых решений.
Интересная статья, освежить универские давно забытые знания. На мой взгляд, лучше бы смотрелись графики вместо анимаций. На координатор оси оно нагляднее
через 5 лет может и проекта этого уже не будет, и состав команды сменится не один раз, а может быть вообще сменится вектор роста проекта и вся ваша дорогая архитектура улетит в трубу. И останутся только довольные разработчики с чистой совестью и инвестор с дыркой от бублика вместо бюджета. но зато в гите будет дорогой и идеально спроектированный код
Ты просишь реально вдумчивых доводов, упрекнул меня в том что я тебе выдал суповой набор клише, а сам аргументируешь свое мнение мемасами? Серьёзно? Я не вижу смысла дальше вести диалог.
Неужели это настолько неочевидно? Вспомнить хотя бы почему все mvp по качеству кода полная шляпа. У разрабов одна болезнь - технический перфекционизм, пока они строят абстракции и пишут эффективный код, время уходит, а кривущий кусок гавнакода уже проверяет бизнес идею на проде. Это что касается мешает. При этом так же не понятно как навык настройки кубернетиса может помочь в привлечении клиентов на продукт и построении воронки
Не лень же было о весах селекторов целую статью навоять.
Видимо, залог успеха на хабре, это с серьёзным видом писать статью о распихивании пропсов по компонентам в реакте.
P.s. сарказм)))
самая большая проблема fsd, что он по своей сути идет от UI. т.е. текущий макет интерфейса диктует вам как и из чего будут состоять фичи. поэтому каждое изменение структуры макета ui интерфейса, делает ваши фичи и слайсы, виджеты не консистентными к приложению. Я сам с этим сталкивался, решается двумя путями - забить и страдать или овертаймами работ по синхронизации всего этого дела. Говоря математическим языком, core_logic = f(ui), что само по себе не лепо, тк это аналогично ситуации, когда выбор шаблонизатора, определял схему данных бд. FSD запрещает кроссфича импорты, заявляя что это как своего рода инкапсуляцию, но по факту одна фича в другую может проникнуть по средствам какого нибудь селектора слайса одной модели в другую. как пример - была форма многоэкранная, на первом экране была фича принимашая строковый адрес, на втором экране фича которая рисовала адрес на карте. и они были друг на друга завязаны, типы и селекторы приходилось дублировать, что бы соблюсти запрет кросс импртов, но это потом стрельнуло нам, когда мы забыли пофиксить один из селекторов, при смене справочника адресов. При переходе вашего проекта из состояния среднего к большому 100% будете резать свои фичи на микрофронты, и удивитесь что они не отрежутся, там будет сильная зависимость от окружения. Когда всеже в микрофронтах вы избавитесь от fsd, вы удивитесь что и на хостовом приложении от него ничего не осталось, тогда возникает вопрос - зачем оно все это нужно???
Зачем тащить на малые приложения фсд, если для личного блога или магазина хватит иерархии components, hooks, hocs, store.
Мне не очень понятно ваше рвение защищать этот подход, он действительно мертворожденный и я считаю его выбор абсолютно безграмотным с точки зрения архитектуры, его выбор просто докажет что разработчик имеет узкий кругозор и мизерную насмотренность. Исключительно мое мнение, прошу не принимать его как оскорбление, а воспринимать как возможную зону роста в будущем. Вы можете возразить на каждый из тезисов, что нужно было бы в каждом случае делать то то или это, я категорически не согласен. Архитектура приложения должна быть интуитивно понятной, а не обьясняться документацией которая сама себе противоречит местами и живет в вакууме
Как раз в этом и есть проблема FSD проектов находящихся на этапе перехода бизнеса от малого к среднему. FSD не адаптируем. Хорошая архитектура в буквальном смысле ждет изменений. фичи, слайсы, виджеты, как по мне это сущности приятнутые за уши и прибитые гвоздями к компонентам. Отсюда и проблема, что когда статус компонента меняется, становится непонятно что с ним делать. начинает или течь абстракция или лететь костыли. Слоистая архитектура в ствязке с атомик дизайном(как пример) в этом плане сильно гибче. Можете менять ядро системы, а ui и знать об этом не будет
Не смогу с вами согласиться, тк был опыт на разного масштаба проектах. Везде были проблемы и проблемы разные.
Для малых проектов fsd это оверхед, для больших превращается в один большой головняк из за протекания абстракций и дублирования кода. Создаётся впечатление, что fsd придумали просто потому что нужно было что то придумать, для людей которые с трудом осилили(или нет) документацию своего стека, что бы они могли почувствовать себя архитектороми приложениий
И что вам мешает использовать абсолютно любую?
Воспринимайте хуки не как конечную точку описания бизнеслогики, а как binder, или провайдер данных из ядра, на слой реакта. На реакт хорошо ложится паттерн mvvm или слоистая архитектура. Всё что вам нужно, это вытащить в хук readonly интерфейс и забиндить на стейт только то что нужно для отрисовки.
Как раз после
И начинается путь любого проекта в неподдердиваемого монстра, без архитектуры, договоренностей, границ ответственности и т.п. тащить туда fsd и ddd, по моему мнению, глупость полнейшая, у этих подходов разночтений столько, что люди внутри команды могут одно и тоже по разному сделать. Этим как раз ангуляр и хорошо, что в базовой своей поставке буквально пальцем тыкать, что где тодолжно быть. Плохо это или хорошо? На мой взгляд это хорошо, если кому то это мешает, то скорее всего ему нужно было выбрать реакт или вью
На самом деле меняется, классы, хуки, несколько смен алгоритмов работы апдейтов виртуального дома. А вот именно базового подхода к разработки в вебер нехватало, тут солидарен
Ангуляр вам буквально связывает руки требованием соблюдать его архитектуру, по сути, на нем трудно написать плохо. В то время как реакт это именно библиотека для обновления вьюхи вашего приложения. Вы можете вокруг этого построить любую архитектуру. Если вы делаете приложение корпоративного уровня на шару, без архитектуры и вам мешает реакт. То разочарую вас, мешает не реакт а отсутствие навыков
Хочу поинтересоваться, без агрессии, исключительно из любопытства. Зачем в вузе изучать то, что меняется с каждым повышением версии? Эти вещи самому при желании и наличии фундаментальный базы раскапываются за несколько недель ковыряния исходников
Игры знатно деградировали в целом. Запускал недавно asassins creed 2, боевка, а точнее фектование там ощущается как бой живых людей, ненавязчивые парирования и добивания не режут глаз, после этого мираж ощущается искусственно, какие то болванчики с заранее записаной анимацией и парированием в тайминг а-ля плохо собраный сосалик. Эталон физики был вообще в alone in the dark 2008 года, если правильно помню. Там огнём и огнетушителем можно было вынести любую закрытую дверь, а электричеством можно было замыкать электронику и воду как в биошоке. Иногда мне кажется, что для успеха в геймдеве, достаточно просто постараться скопировать механики игр 2004-2010 годов, и ты уже будешь выделяться на фоне всего конвеерного шлака
Мне больше интересно посмотреть на тесты, которые бы сравнивали скорость вмонтирования и отмонтирования узлов с большим количеством дочерних элементов. Например тех же списков фиксированной длинны. Т.к. большая часть задач, которые решают реакт либой это сайдбары, дропдауны, аккордеоны, модалки и т.п. Ваш пример про биржи, как мне кажется не совсем подходящий, потому что для максимальной скорости я бы выбрал кастомное решение заточенное на скорость или вообще canvas.
Любопытно сравнивать скорость работы фреймворков на синтетических тестах, которые неимеют отношения к реальной разработке. Неразу нехочу никого задеть, я за прогресс. Но как мне кажется, выбор способа сравнения неподходящий
Скажу одно не популярное мнение. Для людей которые топят за фреймворки, которые точечно работабт с Dom, не очевиден факт, что разметка меняется не точечными узлами, а блоками, и там уже не важно, работает там какой то умный алгоритм рассчета изменений или происходит маппинг с виртуального дома. Разница в перформансе в этом случае практически отсутствует для конечного пользователя приложения. Поэтому команды выбирают реакт по причине быстрого онбординга, простого апи и бесконечного количества готовых решений.