ИМХО это звучит как редакторы и тп не заменимы, но на самом деле это означает, что редакторы хороший материал для обучения GPT, чтобы повышать вариативность и корректность «сгенерированных» ответов
Для webpack и vite достаточно использовать магические комментарии, чтобы запретить парсинг и разрешение зависимостей:
import(
/* webpackIgnore */
url
)
import(
// @vite-ignore
url
);
При этом мы не прибегаем к eval/new Function, не нарушаем CSP и тп.
Наверное, с вендор локом на технологиях MF, SSPA и тп можно согласиться, но аргументы против ИМХО несостоятельные, например, в официальной документации MF есть пример с указанием версий пакетов по semver, откуда появилась проблема в "новых версиях, в которых есть ломающие изменения" не понятно.
Когда мы говорим про микрофронты, без шаринга зависимостей и без коммуникации между микрофронтами, мы в сухом остатке получаем кучу независимых приложений на одной странице, со всеми вытекающими, ничем не отличающимися от того, как мы десяток лет назад встраивали разные виджеты, даже через те же iframe.
У меня нет цели кого-либо в чем-либо убеждать, достаточно зайти на главную страницу и посмотреть какие компании используют: spotify, airbnb, tinder, patreon и т.д.
Я имел ввиду в контексте CSS-in-JS решений, но не суть важно.
Пользовательский html, да и ещё с пользовательскими стилями штука достаточно, как минимум, странная, не говоря об XSS уязвимостях, легко привести пример когда без обработки этим можно выстрелить себе в ногу
Для начала хорошо бы привести пример из "глубин", но почему-то вы приводите невладение технологией как контраргумент ее использования. Не поймите меня неправильно, я тоже использую CSS Modules и всеми руками за простоту и меньший размер бандла, в сравнении с решениями CSS-in-JS, но возбранять этот подход не собираюсь.
То что вы забили, что у вас в props передается параметр для стилизации -- чисто ваша проблема, уж извините, но и в случае с CSS Modules будет тоже самое.
CSS-in-JS -- это просто другой подход, да и не одним styled-components едины, как и писать просто CSS стили, если лично вам не нравится -- не используйте, вас никто не заставляет.
Не согласен ни с статьей, ни с вашим комментарием, достаточно просто загуглить, вот, например, расширение для VS Code с подсветкой и, более того, с автодополнением. Инлайновые стили вообще рудимент, разве что для email верстки осталось. К тому же, есть отличные решения https://linaria.dev/ и https://vanilla-extract.style/, которые вообще извлекают ваши стили в обычные CSS чанки. В классическом styled-components, чтобы писать стили с переопределением для потомков, достаточно передавать компонент, что описано прямо в документации
Что касается статьи, "common issue example" якрий пример, что просто не разобрались как настроить бандлер и правильно подключить, хотя там тоже ничего сложно нет.
Шина событий в React -- это вообще что-то с чем-то, естественно если так делать ничего на npm и не найдете, просто говоря, PubSub можно организовать как тут в mitt, но все React компоненты объявляются в обычных модулях, и что мешает просто импортировать созданный bus? Зачем оборачивать в контекст? Одни вопросы...
У вас задача неправильно решена, нужно сначала смержить 2 списка, а только потом отсортировать, иначе условно для [1,2,3] и [1,2,3] у вас получится [1,2,3,1,2,3] вместо [1,1,2,2,3,3]
P.S. Не понял причину минусов, если в вашем понимании слияние не конкатенация, то почему тогда за один проход не решить ¯\_(ツ)_/¯
Атомарно можно обновить только, если хранить объект, и обновлять его полностью. Но в реальном приложении чаще это не нужно, потому что такие обновления батчатся, прежде чем обновить DOM
«Старое железо», «Гаджеты», «Планшеты», «Ноутбуки», «Игры и игровые консоли»
в теги «железо» и «игры и геймдев»? Кажется текущее деление слишком избыточно и неоднозначно.
P.S. Простому работяге хотелось бы читать про хард штуки отдельно от остальных трендов по типу «выгорание» и «собеседования», которые нагоняют лишь тоску
ИМХО это звучит как редакторы и тп не заменимы, но на самом деле это означает, что редакторы хороший материал для обучения GPT, чтобы повышать вариативность и корректность «сгенерированных» ответов
Существуют готовые решения, например:
https://github.com/expatfile/next-runtime-env
А что можно было ожидать от одного из членов Remix? Медиа борьба с конкурентами не более.
Сравните оригинал цитат с переводом, хотя бы по смыслу
Для webpack и vite достаточно использовать магические комментарии, чтобы запретить парсинг и разрешение зависимостей:
При этом мы не прибегаем к eval/new Function, не нарушаем CSP и тп.
Наверное, с вендор локом на технологиях MF, SSPA и тп можно согласиться, но аргументы против ИМХО несостоятельные, например, в официальной документации MF есть пример с указанием версий пакетов по semver, откуда появилась проблема в "новых версиях, в которых есть ломающие изменения" не понятно.
Когда мы говорим про микрофронты, без шаринга зависимостей и без коммуникации между микрофронтами, мы в сухом остатке получаем кучу независимых приложений на одной странице, со всеми вытекающими, ничем не отличающимися от того, как мы десяток лет назад встраивали разные виджеты, даже через те же iframe.
Статья, мягко говоря, с душком, уже давно Babel в проектах nextjs не используется, в том числе настройка для emotion идет из коробки
У меня нет цели кого-либо в чем-либо убеждать, достаточно зайти на главную страницу и посмотреть какие компании используют: spotify, airbnb, tinder, patreon и т.д.
Вы опять перекладываете ваши психологические травмы от неправильного использования технологии на саму технологию.
Кажется мы ходим по кругу, все что вы написали мы уже решили
/thread
Я имел ввиду в контексте CSS-in-JS решений, но не суть важно.
Пользовательский html, да и ещё с пользовательскими стилями штука достаточно, как минимум, странная, не говоря об XSS уязвимостях, легко привести пример когда без обработки этим можно выстрелить себе в ногу
Второй кейс имеет право на жизнь, но спокойно покрывается CSS custom variables, которые современные CSS-in-JS и используют
Для начала хорошо бы привести пример из "глубин", но почему-то вы приводите невладение технологией как контраргумент ее использования. Не поймите меня неправильно, я тоже использую CSS Modules и всеми руками за простоту и меньший размер бандла, в сравнении с решениями CSS-in-JS, но возбранять этот подход не собираюсь.
Для stylelint кстати есть официальный плагин, не понимаю в чем проблема
То что вы забили, что у вас в props передается параметр для стилизации -- чисто ваша проблема, уж извините, но и в случае с CSS Modules будет тоже самое.
CSS-in-JS -- это просто другой подход, да и не одним styled-components едины, как и писать просто CSS стили, если лично вам не нравится -- не используйте, вас никто не заставляет.
Не согласен ни с статьей, ни с вашим комментарием, достаточно просто загуглить, вот, например, расширение для VS Code с подсветкой и, более того, с автодополнением.
Инлайновые стили вообще рудимент, разве что для email верстки осталось.
К тому же, есть отличные решения https://linaria.dev/ и https://vanilla-extract.style/, которые вообще извлекают ваши стили в обычные CSS чанки.
В классическом styled-components, чтобы писать стили с переопределением для потомков, достаточно передавать компонент, что описано прямо в документации
Что касается статьи, "common issue example" якрий пример, что просто не разобрались как настроить бандлер и правильно подключить, хотя там тоже ничего сложно нет.
Шина событий в React -- это вообще что-то с чем-то, естественно если так делать ничего на npm и не найдете, просто говоря, PubSub можно организовать как тут в mitt, но все React компоненты объявляются в обычных модулях, и что мешает просто импортировать созданный bus? Зачем оборачивать в контекст? Одни вопросы...
https://realfavicongenerator.net/
У вас задача неправильно решена, нужно сначала смержить 2 списка, а только потом отсортировать, иначе условно для
[1,2,3]и[1,2,3]у вас получится[1,2,3,1,2,3]вместо[1,1,2,2,3,3]
P.S. Не понял причину минусов, если в вашем понимании слияние не конкатенация, то почему тогда за один проход не решить ¯\_(ツ)_/¯Атомарно можно обновить только, если хранить объект, и обновлять его полностью. Но в реальном приложении чаще это не нужно, потому что такие обновления батчатся, прежде чем обновить DOM
? blazing fast ? memory safe ?
Ничего так не дискредитирует rust, как люди, которые о нем пишут
Интересно больше то, что на сами Goophone тоже есть подделки, точнее копии ещё хуже качества, которые выдают себя за Goophone
Почему бы не перегруппировать
в теги «железо» и «игры и геймдев»? Кажется текущее деление слишком избыточно и неоднозначно.
P.S. Простому работяге хотелось бы читать про хард штуки отдельно от остальных трендов по типу «выгорание» и «собеседования», которые нагоняют лишь тоску