Только есть нюанс. Программист тоже пользуется всеми этими инструментами. То есть сравнивать надо не программиста и chatgpt, а {программист + chatgpt} (за $4000) и просто chatgpt (за $20).
Пока что это как заменить водителя гужевого транспорта на автомобиль. Автомобилю тоже нужен водитель и притом ещё большей и квалификации.
Нет смысла пытаться отрицать очевидные преимущества мутабильности и императивном подходе в качестве кода, его читаемости, производительности и потреблению оперативной памяти.
Так же как и нет смысла отрицать очевидные недостатки мутабельности в качестве источника неочевидных ошибок в программе. Во втором варианте Вы мутируете parents. А ведь оно могло где-то еще использоваться в другой части программы.
Действительно, хоть субъективно и кажется, что рендер функция будет занимать меньше памяти, чем результат этой функции, но после проверки оказалось, что нет никакой разницы.
то само собой Reconciler будет ре-маунтить его на каждый рендер.
Что значит "само собой"? Так говорите как будто нет выхода. Я привел пример как это можно было сделать, чтобы не было пересоздания. И для этого не надо писать что-то сверхъестественное. Достаточно передавать не элемент, а рендер функцию
Библиотека занимается роутингом, а вы требуете у неё знать о существовании модулей
Я не требую знать о существовании модулей. Я предоставляю библиотеке конфиг с деревом роутов (не важно, через jsx или через useRouter). Этого должно быть достаточно, чтобы она вычислила абсолютный путь к элементу этого дерева.
Вы точно так же можете наворотить своих конфигов, но только для ссылок.
Могу, но зачем мне писать два конфига и следить чтобы они были консистентными? Чем больше кода, тем дороже его поддерживать.
не "каждый компонент обязан знать о хедере
Видимо тут у нас с вами основное различие во взглядах. Я считаю что каждая страница должна полностью определять весь лейаут страницы. Все остальные решения не универсальны. Вызвать в каждой странице свой лейаут (<Layout1><Page1Content/></Layout1>) практически ничего не усложняет, но увеличивает гибкость до максимума. Мы на любой каприз заказчика можем поменять хеадер, футер или сайдбар, поменяв Layout1 на Layout2.
То что у них в примере есть общий лейаут для внутренних роутов - это не универсально. Всегда есть вероятность, что заказчик попросит сделать одну из внутренних страниц по другому лейоуту. И тогда начнутся костыли.
ну имеется ввиду, что мы либо можем придумывать свой конфиг, а потом из него генерить JSX, либо сразу описывать (конфигурировать) программу с помощью jsx.
Касательно этой фразы - она не противоречит статье. Полностью с ней согласен и у меня даже была статья на эту тему. Те конвертации конфига в jsx, с которыми я работал, были не мной написаны. И я как раз против конвертации конфига в JSX. Я за то чтобы либо конфиг либо jsx.
Но мысль в этой статье была про то что роуты не удобно конфигурировать JSX-ом и почему - я аргументировал.
Вот как раз с библиотеками компонентов тут наоборот.
Если используется библиотечный компонент, то как правило он что-то да не умеет из того что нужно именно в этом проекте, и тогда наварачиваются костыли поверх него или находится другая библиотека но старый компонент не поменяешь, потому как пропсы разные - в итоге в проекте два (и более) одинаковых компонентов. Свой же велосипед можно модифицировать и наварачивать сколь угодно долго не меняя при этом интерфейс его использования. Основной же недостаток библиотек 1. то что они универсальны - добавляет тормознутости. Как правило в проекте нужна небольшая часть от всего функционала готового компонента. 2. то что они уже содержат стили - добавляет ненужный код в проект. Как правило в конкретном проекте нужны свои стили и стили библиотечного компонента просто напросто висят мертвым грузом.
Но я не за то чтобы писать все с нуля. Есть библиотеки из которых можно собрать компонент минимальными усилиями.
Самое рабочее решение - это портал, который работает в 100% случаев. И расчитывать координаты в момент отображения. И прятать в момент ресайза/скрола - иначе прийдется вдаваться в филосовские вопросы кто же должен быть выше - заголовок, сайдбар меню или выпадающий список.
Общие элементы можно вынести и переиспользовать их в этих двух компонентах. И скорее всего эти общие части понадабятся еще в других комонентах (например DatePicker, ColorPicker). Но зато в пропсах будет все однозначно с какими данными работает компонент.
да, но грузовик без водителя не сможет ничего.
все же думаю что с автопилотом еще рано сравнивать. Без водителя эти инструменты пока еще не умеют кодить.
Только есть нюанс. Программист тоже пользуется всеми этими инструментами. То есть сравнивать надо не программиста и chatgpt, а {программист + chatgpt} (за $4000) и просто chatgpt (за $20).
Пока что это как заменить водителя гужевого транспорта на автомобиль. Автомобилю тоже нужен водитель и притом ещё большей и квалификации.
Так же как и нет смысла отрицать очевидные недостатки мутабельности в качестве источника неочевидных ошибок в программе.
Во втором варианте Вы мутируете parents. А ведь оно могло где-то еще использоваться в другой части программы.
Если привести код к идентичному алгоритму, то по производительности одинаково. Разница в пределах погрешности:
https://stackblitz.com/edit/vitejs-vite-w8s7p9d6?file=main.js,javascript.svg&terminal=dev
То есть разрабатывая светильник мы придумываем свои уникальные параметры винтиков, а потом на заводе винтиков заказываем их изготовление?
Я почему то думал наоборот. Дизайнер светильника подбирает винтики из доступных в продаже.
Инверсия зависимостей классная штука для расширения мировоззрения, но я никак не могу согласится с автором этого принципа, что надо все инвертировать.
По логике дяди Боба нельзя использовать готовые библиотеки, т.к. оказывается что светильник зависит от винтиков, а не наоборот.
Спасибо за статью как за возможность задать такой вопрос )
https://www.npmjs.com/package/react-svg-sprite-generator - генерит svg спрайт и константы для JS
пользуйтесь )
Просто у chatgpt данные только до 2021-го года. Он мне тоже Formik советовал, но я бы не стал его использовать по той же причине (смотрел исходники)
Как у них с поддержкой Typescript?
Действительно, хоть субъективно и кажется, что рендер функция будет занимать меньше памяти, чем результат этой функции, но после проверки оказалось, что нет никакой разницы.
Не нашел в документации к 6-й версии чтобы можно было рендер функцию передавать. Можете показать место где про это написано?
Видимо мы с вами на разных уровнях. Не каждый готов решить проблему в корне написав свою библиотеку :)
Что значит "само собой"? Так говорите как будто нет выхода. Я привел пример как это можно было сделать, чтобы не было пересоздания. И для этого не надо писать что-то сверхъестественное. Достаточно передавать не элемент, а рендер функцию
Я не требую знать о существовании модулей. Я предоставляю библиотеке конфиг с деревом роутов (не важно, через jsx или через useRouter). Этого должно быть достаточно, чтобы она вычислила абсолютный путь к элементу этого дерева.
Могу, но зачем мне писать два конфига и следить чтобы они были консистентными? Чем больше кода, тем дороже его поддерживать.
Видимо тут у нас с вами основное различие во взглядах. Я считаю что каждая страница должна полностью определять весь лейаут страницы. Все остальные решения не универсальны. Вызвать в каждой странице свой лейаут (<Layout1><Page1Content/></Layout1>) практически ничего не усложняет, но увеличивает гибкость до максимума. Мы на любой каприз заказчика можем поменять хеадер, футер или сайдбар, поменяв Layout1 на Layout2.
То что у них в примере есть общий лейаут для внутренних роутов - это не универсально. Всегда есть вероятность, что заказчик попросит сделать одну из внутренних страниц по другому лейоуту. И тогда начнутся костыли.
ну имеется ввиду, что мы либо можем придумывать свой конфиг, а потом из него генерить JSX, либо сразу описывать (конфигурировать) программу с помощью jsx.
Касательно этой фразы - она не противоречит статье. Полностью с ней согласен и у меня даже была статья на эту тему.
Те конвертации конфига в jsx, с которыми я работал, были не мной написаны. И я как раз против конвертации конфига в JSX. Я за то чтобы либо конфиг либо jsx.
Но мысль в этой статье была про то что роуты не удобно конфигурировать JSX-ом и почему - я аргументировал.
Спасибо, вариант рабочий, ничего не пересоздается. Но вы же не предлагаете одновременно создать 50 страниц и держать их в памяти?
Вот как раз с библиотеками компонентов тут наоборот.
Если используется библиотечный компонент, то как правило он что-то да не умеет из того что нужно именно в этом проекте, и тогда наварачиваются костыли поверх него или находится другая библиотека но старый компонент не поменяешь, потому как пропсы разные - в итоге в проекте два (и более) одинаковых компонентов.
Свой же велосипед можно модифицировать и наварачивать сколь угодно долго не меняя при этом интерфейс его использования.
Основной же недостаток библиотек
1. то что они универсальны - добавляет тормознутости. Как правило в проекте нужна небольшая часть от всего функционала готового компонента.
2. то что они уже содержат стили - добавляет ненужный код в проект. Как правило в конкретном проекте нужны свои стили и стили библиотечного компонента просто напросто висят мертвым грузом.
Но я не за то чтобы писать все с нуля. Есть библиотеки из которых можно собрать компонент минимальными усилиями.
А в оставшихся 10% случаях что делать? :)
Самое рабочее решение - это портал, который работает в 100% случаев.
И расчитывать координаты в момент отображения.
И прятать в момент ресайза/скрола - иначе прийдется вдаваться в филосовские вопросы кто же должен быть выше - заголовок, сайдбар меню или выпадающий список.
Общие элементы можно вынести и переиспользовать их в этих двух компонентах. И скорее всего эти общие части понадабятся еще в других комонентах (например DatePicker, ColorPicker). Но зато в пропсах будет все однозначно с какими данными работает компонент.