Мне кажется, что css-in-js был когда-то неплохим ответом на то, что в css не хватало фичей и тулинга вокруг. Например - не было css modules: в css приходилось руками фигачить БЭМ, с css-in-js это решалось. Или те же темы - по сравнению с лютыми миксинами на scss, делать функции на js выглядело норм идеей.
Сейчас и css modules есть, и в css много нужного появилось. И перестало быть понятно зачем так извращаться.
Мы у себя спрыгнули уже года четыре как на css modules, scss на минималках - почти без миксинов, много юзаем css variables. И довольны, и всем советуем.
Я для нашей библиотеки таблички и state managment к нему делаю. Там уже где-то 5 лет это все эволюционирует потихоньку.
Чтобы поддержать строки разной высоты - от контента зависящей - сделали свою виртуализацию. Все виртуализируют тупо расставляя строки абсолютом, и высчитывая координаты каждой - так не катит.
Загрузка данных с сервера - чтобы подгружало и вниз и «вглубь» - тоже ну очень непросто. Особенно если есть всякие cascade selection.
Редактирование - вроде и просто, но нюансов тьма. У нас многие компоненты умеют mode=cell, и можно всякие DatePicker-ы вставлять в ячейки.
Сейчас вот делаем копирование ячеек перетягиванием как в excel. И удобное API для subtotals.
И думаю еще раз попробовать переверстать все с флексбоксов на css grid - потому что народ начал хотеть мерджить ячейки вертикально, на текущей верстке это нормально не сделать.
К нему еще API чтобы на сервер ходить за результатами, еще подгрузку данных при скролле в выпадушке, еще деревья чтобы с фолдингом. А, да, еще и вариант с выбором нескольких элементов, и чтобы тегами еще выбранное показывать. Вот этого всего - наверное уже хватит, чтобы начинать думать о замене кастомных реализаций на нативные. Без этого - ну такое: все равно для всех случаев не пойдет, а если уж тащить кастомный - то чего уж его везде не использовать.
А еще вот интересно - нет ли каких-то техник рендера, принципиально не ложащихся на GPU? Если что-то такое заюзать - это может придать работе дополнительный смысл и шарм.
Например был во всяких magic carpet подход с рисованием ландшафта - когда используется карта высот, рисуются столбики снизу вверх, а для отсечение юзают что-то типа одномерного z-буфера. Вот что-то такое не придумывалось/вспоминалось/пробовалось?
Может выделять поверхности с отсутствующим отраженным светом, и их кешировать между кадрами? Например все эти камни-кирпичи на открытой сцене - не очень-то и блестят.
Сейчас продаются "удлинители" HDMI/USB по оптике. Ща погуглил - цены вроде терпимые. Но сам не пробовал.
У Linus Tech Tips была серия, где он мега-комп с 4-мя GeForce на всю семью собрал, и поставил в кладовке. Ну т.е. если заморочиться (например при ремонте) - можно сразу развести так, чтобы и с телека порубать, и с обустроенного рабочего места поработать, а комп будет жужжать на балконе/кладовке/подвале дома.
Там это и надо. То, что в статье называется "развернуть фазу" - это такое витиеватое название для "развернуть динамик в обратном звуку направлении". Т.е. чтобы он компенсировал сигнал в обратную сторону. Это как если две колонки напротив друг друга поставить.
Только, как заметили уже - это так просто не работает. В какой-нибудь условной трубе, звук может двигаться примерно прямо, и его можно компенсировать обратным действием. Например - в наушниках примерно такая история. Хотя там, конечно, в разы все хитрее - система микрофон-динамик-ухо имеет хитрую импульсную характеристику (типа АЧХ), ее надо как-то угадать, и цифровой обработкой делать на нее поправку.
Но, в целом, колебания распространяются в объеме. И там задача даже в теории не решается. Разве что, может быть, в теории можно заглушить звук из одной точки в какой-то другой одной точке. Снимают же импульсную характеристику помещения, а тут обратная задача.
С каким-то идеальным окном тоже может сработать - если сделать какие-нибудь допущения - типа что оно само идеально упругое, и движется строго по одной оси.
На практике, через всякие хитрые приемы, совместно с правильными материалами, активным шумоподавлением можно добиться ощутимых результатов. В машинах вон вроде делают.
Надо еще все API всех проектов сложить в одну репу. Туда же - генерацию кода с DTO и билд библиотек для используемых платформ. Туда же - документацию. И все это - через MR и ревью всех пользователей.
Не похоже чтобы спрайты как-то помогали с кучей повторяющихся иконок.
А у инлайна куча плюсов - он в CRA из коробки, ничего не моргает, грузится сразу все и только нужное. И даже подгружать можно по необходимости - через async-загрузку модулей у вебпака.
Там у тебя в JSON начнут появляться всякие locationID. И дальше будут проблемы с JOIN-ами, например.
Потом «все равно читаем весь документ» - тоже неправильная вводная. Например, может быть типичная схема с каталогом/списком (много фильтров, не все поля показываются) и страничкой документа (нужны все поля).
Короче, подход имеет смысл в каких-то случаях - не зря в той же пострге приделали такую хорошую поддержку jsonb. Но далеко не прям «всегда». Мы вот недавно буквально раскладывали такой JSON на десяток таблиц - потому что потребовалось работать с его кусочками отдельно.
Я бы добавил, что 808-й кик - это тот самый низкочастотный «бум» во всем репе и около. Он, конечно сильно обработанный, но часто - это реально записанный с 808го звук.
И это, наверное самый используемый семпл в музыке. С большим отрывом даже от amen loop.
Я вот не понимаю, почему enterprise - кровавый по-дефолту. Я вот наблюдаю совершенно не кровавый enterprise.
Половину гугла можно написать на ассемблере, и акции его - не колыхнуться даже. Пойди автоматизируй предприятие - с понятными, небольшими бюджетами. Вот где надо сильно думать, вот где надо суровые уровни абстракции, DSL, API. Чистое творчество же!
Да. Первым надо учить scheme по SICP. Правда, потом работать за деньги придется все равно на js, и полгода обниматься с тазиком. Но, хотя-бы вкус и понимание прекрасного сформируются.
А что такого есть в neo4j, чего нет в той же постгре? Там как-то хитро внутри данные лежат, индексы какие хитрые под транзитивные зависимости строятся? Никак не пойму зачем их брать, если есть полноценные бд - умеющие тоже самое, еще сверху мешок всего.
Мне кажется, что css-in-js был когда-то неплохим ответом на то, что в css не хватало фичей и тулинга вокруг. Например - не было css modules: в css приходилось руками фигачить БЭМ, с css-in-js это решалось. Или те же темы - по сравнению с лютыми миксинами на scss, делать функции на js выглядело норм идеей.
Сейчас и css modules есть, и в css много нужного появилось. И перестало быть понятно зачем так извращаться.
Мы у себя спрыгнули уже года четыре как на css modules, scss на минималках - почти без миксинов, много юзаем css variables. И довольны, и всем советуем.
Я для нашей библиотеки таблички и state managment к нему делаю. Там уже где-то 5 лет это все эволюционирует потихоньку.
Чтобы поддержать строки разной высоты - от контента зависящей - сделали свою виртуализацию. Все виртуализируют тупо расставляя строки абсолютом, и высчитывая координаты каждой - так не катит.
Загрузка данных с сервера - чтобы подгружало и вниз и «вглубь» - тоже ну очень непросто. Особенно если есть всякие cascade selection.
Редактирование - вроде и просто, но нюансов тьма. У нас многие компоненты умеют mode=cell, и можно всякие DatePicker-ы вставлять в ячейки.
Сейчас вот делаем копирование ячеек перетягиванием как в excel. И удобное API для subtotals.
И думаю еще раз попробовать переверстать все с флексбоксов на css grid - потому что народ начал хотеть мерджить ячейки вертикально, на текущей верстке это нормально не сделать.
Короче с таблицами большой опыт, могу поделиться.
К нему еще API чтобы на сервер ходить за результатами, еще подгрузку данных при скролле в выпадушке, еще деревья чтобы с фолдингом. А, да, еще и вариант с выбором нескольких элементов, и чтобы тегами еще выбранное показывать. Вот этого всего - наверное уже хватит, чтобы начинать думать о замене кастомных реализаций на нативные. Без этого - ну такое: все равно для всех случаев не пойдет, а если уж тащить кастомный - то чего уж его везде не использовать.
А еще вот интересно - нет ли каких-то техник рендера, принципиально не ложащихся на GPU? Если что-то такое заюзать - это может придать работе дополнительный смысл и шарм.
Например был во всяких magic carpet подход с рисованием ландшафта - когда используется карта высот, рисуются столбики снизу вверх, а для отсечение юзают что-то типа одномерного z-буфера. Вот что-то такое не придумывалось/вспоминалось/пробовалось?
Может выделять поверхности с отсутствующим отраженным светом, и их кешировать между кадрами? Например все эти камни-кирпичи на открытой сцене - не очень-то и блестят.
Я бы сейчас на месте всех продакт-менеджеров и около - сильно бы напрягся. Мало ли у Маска получится поувольнять половину - и станет только лучше.
Сейчас продаются "удлинители" HDMI/USB по оптике. Ща погуглил - цены вроде терпимые. Но сам не пробовал.
У Linus Tech Tips была серия, где он мега-комп с 4-мя GeForce на всю семью собрал, и поставил в кладовке. Ну т.е. если заморочиться (например при ремонте) - можно сразу развести так, чтобы и с телека порубать, и с обустроенного рабочего места поработать, а комп будет жужжать на балконе/кладовке/подвале дома.
Там это и надо. То, что в статье называется "развернуть фазу" - это такое витиеватое название для "развернуть динамик в обратном звуку направлении". Т.е. чтобы он компенсировал сигнал в обратную сторону. Это как если две колонки напротив друг друга поставить.
Только, как заметили уже - это так просто не работает. В какой-нибудь условной трубе, звук может двигаться примерно прямо, и его можно компенсировать обратным действием. Например - в наушниках примерно такая история. Хотя там, конечно, в разы все хитрее - система микрофон-динамик-ухо имеет хитрую импульсную характеристику (типа АЧХ), ее надо как-то угадать, и цифровой обработкой делать на нее поправку.
Но, в целом, колебания распространяются в объеме. И там задача даже в теории не решается. Разве что, может быть, в теории можно заглушить звук из одной точки в какой-то другой одной точке. Снимают же импульсную характеристику помещения, а тут обратная задача.
С каким-то идеальным окном тоже может сработать - если сделать какие-нибудь допущения - типа что оно само идеально упругое, и движется строго по одной оси.
На практике, через всякие хитрые приемы, совместно с правильными материалами, активным шумоподавлением можно добиться ощутимых результатов. В машинах вон вроде делают.
Чтобы «развернуть» сигнал, надо просто у динамика провода местами поменять.
Надо еще все API всех проектов сложить в одну репу. Туда же - генерацию кода с DTO и билд библиотек для используемых платформ. Туда же - документацию. И все это - через MR и ревью всех пользователей.
React Router - эталон как не надо вести проекты про библиотеки. 6-я версия уже, в каждой меняют api и всё ломают, без какого-то особого смысла.
А если кнопку ОК сделать прозрачной для кликов (pointer-events: none), и подставить над вашей кнопкой?
Вот тут сравнивают перформанс разных способов втыкать svg: https://cloudfour.com/thinks/svg-icon-stress-test/
Не похоже чтобы спрайты как-то помогали с кучей повторяющихся иконок.
А у инлайна куча плюсов - он в CRA из коробки, ничего не моргает, грузится сразу все и только нужное. И даже подгружать можно по необходимости - через async-загрузку модулей у вебпака.
Хотя я тоже был когда-то адептом спрайтов.
Там у тебя в JSON начнут появляться всякие locationID. И дальше будут проблемы с JOIN-ами, например.
Потом «все равно читаем весь документ» - тоже неправильная вводная. Например, может быть типичная схема с каталогом/списком (много фильтров, не все поля показываются) и страничкой документа (нужны все поля).
Короче, подход имеет смысл в каких-то случаях - не зря в той же пострге приделали такую хорошую поддержку jsonb. Но далеко не прям «всегда». Мы вот недавно буквально раскладывали такой JSON на десяток таблиц - потому что потребовалось работать с его кусочками отдельно.
Задачка с подвохом. По тексту, люди и кампании лежат в разных микросервисах и разных базах. А запрос должен включать обе базы сразу.
А что происходит, если от бизнеса приходит задача: хотим табличку всех пользователей, с пейджингом, и сортировкой по колонке company business name?
Я бы добавил, что 808-й кик - это тот самый низкочастотный «бум» во всем репе и около. Он, конечно сильно обработанный, но часто - это реально записанный с 808го звук.
И это, наверное самый используемый семпл в музыке. С большим отрывом даже от amen loop.
Я вот не понимаю, почему enterprise - кровавый по-дефолту. Я вот наблюдаю совершенно не кровавый enterprise.
Половину гугла можно написать на ассемблере, и акции его - не колыхнуться даже. Пойди автоматизируй предприятие - с понятными, небольшими бюджетами. Вот где надо сильно думать, вот где надо суровые уровни абстракции, DSL, API. Чистое творчество же!
А Faagn - ну сиди, данные перекладывай.
Enterprise - сила, Faagn - могила!
Да. Первым надо учить scheme по SICP. Правда, потом работать за деньги придется все равно на js, и полгода обниматься с тазиком. Но, хотя-бы вкус и понимание прекрасного сформируются.
А что такого есть в neo4j, чего нет в той же постгре? Там как-то хитро внутри данные лежат, индексы какие хитрые под транзитивные зависимости строятся? Никак не пойму зачем их брать, если есть полноценные бд - умеющие тоже самое, еще сверху мешок всего.