Одно время я тоже ими пользовался, даже перевел статью про выход пятой версии. Однако, не очень гладкая интеграция с Mui четвертой версии заставила перейти на JSS объектный синтаксис. А сейчас, в пятой версии этой великолепной библиотеки, разработчики взяли emotion как решение по умолчанию.
Возможно, стоит задуматься о возврате к простому kebab-case синтаксису css без upperCase девиаций =)
От скриншота с "технологическими требованиями" повеяло Джумлой и 1С-Битриксом.
Неужели еще кто-то разрабатывает такие сайты по ТЗ? без Agile и прочих гибких методолгий.
Никогда ТЗ не может стать достаточным и необходимым условием для доставки качественного сайта, который еще и понравится заказчику/клиенту. Ну.. или на разработку ТЗ уйдет столько времени, что начнет попахивать бюрократией и госзакупками, где все равно все пойдет наперекосяк.
В приведенном коде хука все танцы с useCallback бесмысленны, так как функция setSearchQuery пересоздается каждый раз. А filter никаким образом не мемоизируется, и будет триггерить пересоздание, так как это объект, а массив из dependencies работает по принципу строгого сравнения.
Как результат, множество лишних рендеров и дополнительный оверхед в виде неработающей мемоизации.
Кстати, совершенно не обязательно добавлять функцию-сеттер из useState в массив dependencies у useMemo и useCallback.
P.S.: Комментарий написал исключительно, чтобы текущее решение не было скопировано в реальный проект один в один.
Ну да, их просто нужно резинками привязывать к стенке. В посте даже есть фотография с сетчатой решеткой. Однако, резинки будут пропадать в реалиях бескрайных просторов народного достояния. Полагаться на осведомленность пользователей нельзя: стандарта нет, везде все по-разному. Нужны неотсоединяемые резинки треугольной формы красного цвета =)
В Нидерландах, например. В вопросах велосипедов и поездов они впереди планеты всей. (а еще проектирования дорог, детских площадок, выращивания овощей, защиты от наводнений, и еще много чего).
Поднимать велосипед в вертикально действительно проблемно. Представьте, если велосипед электрический с мотором и батареей.
Самое главное в размещении велосипедов -- возможность крепежа обычными резинками.
Пазики под колеса не работают. Эту ошибку совершали 20-30 лет назад.
Неопытным разработчикам будет пофиг на отсутствие отображения фокуса и я считаю это маленькой ценой за отсутствие неожиданной разницы в отображении фокуса.
По факту это лишь инструмент подачи агрегированной информации. Того же самого можно добиться используя REST. Все те же идеи встраивания дополнительных сущностей в те или иные запросы, уменьшая их количество.
Однако самая проблема касается как раз построения этого графа/связей на бекенде.
Описанные проблемы множества эндпоинтов решаются с помощью встраивания (embedding), связей (references) и ссылок (links).
Это все реализовано в HATEOAS, HAL и JSON-API. А типизация может быть экстрактирована из Swagger.
Одно время я тоже ими пользовался, даже перевел статью про выход пятой версии. Однако, не очень гладкая интеграция с Mui четвертой версии заставила перейти на JSS объектный синтаксис. А сейчас, в пятой версии этой великолепной библиотеки, разработчики взяли emotion как решение по умолчанию.
Возможно, стоит задуматься о возврате к простому kebab-case синтаксису css без upperCase девиаций =)
Действительно. Полезная штуковина тогда. Было бы здорово иметь этот функционал встроенным в Реакт
А в чем "нормально построить строку" внутри
computedбудет фундаментально отличаться от приведенных выше примеров?Не могли бы вы привести пример того, как вы бы использовали
computedв случае приведенного примера из статьи?Все верно. И я так использовал во времена, когда прямой доступ к DOM был поведением по умолчанию, а Virtual DOM еще не популяризировали.
Свойство
HTMLElement.datasetвызывало чувства красоты, удобства и каноничности.Я был удивлен, когда в React и JSX не оказалось инструмента работы с этим API. Было бы здорово иметь
datasetнаряду сstateиpropsА, ну да. Тег "1С-битрикс" присутствует в статье. Интересно, когда он вымрет?
От скриншота с "технологическими требованиями" повеяло Джумлой и 1С-Битриксом.
Неужели еще кто-то разрабатывает такие сайты по ТЗ? без Agile и прочих гибких методолгий.
Никогда ТЗ не может стать достаточным и необходимым условием для доставки качественного сайта, который еще и понравится заказчику/клиенту. Ну.. или на разработку ТЗ уйдет столько времени, что начнет попахивать бюрократией и госзакупками, где все равно все пойдет наперекосяк.
В приведенном коде хука все танцы с
useCallbackбесмысленны, так как функцияsetSearchQueryпересоздается каждый раз. Аfilterникаким образом не мемоизируется, и будет триггерить пересоздание, так как это объект, а массив изdependenciesработает по принципу строгого сравнения.Как результат, множество лишних рендеров и дополнительный оверхед в виде неработающей мемоизации.
Кстати, совершенно не обязательно добавлять функцию-сеттер из
useStateв массивdependenciesуuseMemoиuseCallback.P.S.: Комментарий написал исключительно, чтобы текущее решение не было скопировано в реальный проект один в один.
Покопаться в голове, почему это приносит стресс. И решить эти проблемы.
А не могли бы вы сравнить производительность данного решения с текущими реализациями в
nodejs,webkit,gecko,blink?Возьмем, например, пример из жизни: таблица с 10к строками, данные в которой нужно отфильтровать на клиенте.
Конечно, на таких малых значениях использование альтернативных структур данных избыточно. Но в каких случаях это оправданно?
Спасибо!
Кликбейтно, но не лампово.
Работы, конечно, очень много. Даже сделать hi-res 2d картинку очень будет трудно, сохранив ламповость.
Это была ирония
Интересно, это такая скрытая ирония, показывать фотографии без людей, намекая на то, что такой урбанизм не пользуется популярностью?
Некоторые общественные пространства и архитектурные решения представленные на фотографиях лучше бы вовсе не показывать.
Складывается впечатление, что под видом качественных фотографий, "продается" весьма посредственный дизайн общественных пространств.
https://www.youtube.com/watch?v=MxY-9xB4a3s
Ну да, их просто нужно резинками привязывать к стенке. В посте даже есть фотография с сетчатой решеткой. Однако, резинки будут пропадать в реалиях бескрайных просторов народного достояния. Полагаться на осведомленность пользователей нельзя: стандарта нет, везде все по-разному. Нужны неотсоединяемые резинки треугольной формы красного цвета =)
В Нидерландах, например. В вопросах велосипедов и поездов они впереди планеты всей. (а еще проектирования дорог, детских площадок, выращивания овощей, защиты от наводнений, и еще много чего).
Поднимать велосипед в вертикально действительно проблемно. Представьте, если велосипед электрический с мотором и батареей.
Самое главное в размещении велосипедов -- возможность крепежа обычными резинками.
Пазики под колеса не работают. Эту ошибку совершали 20-30 лет назад.
Иногда люди платят за это. Ситуативно любая вещь может оказаться очень уместной :)
Они научатся тому, как делать неправильно.
По факту это лишь инструмент подачи агрегированной информации. Того же самого можно добиться используя REST. Все те же идеи встраивания дополнительных сущностей в те или иные запросы, уменьшая их количество.
Однако самая проблема касается как раз построения этого графа/связей на бекенде.
Описанные проблемы множества эндпоинтов решаются с помощью встраивания (embedding), связей (references) и ссылок (links).
Это все реализовано в HATEOAS, HAL и JSON-API. А типизация может быть экстрактирована из Swagger.
Почему вы выбрали именно GraphQL?
Наезды на JSX выглядят приблизительно так:
А в
$molвообще нет циклов! Посмотрите, как элегантно итерировать через хвостовую рекурсию!P.S.: Сколько постов не выходит, а вы все никак не уяснили. Ну нельзя продвигать свою технологию обсирая все и вся походу.