да как угодно, только то что указано в примере - явно указание на то, что ваш разработчик обладает крайне низкой компетенцией
надеются на помощь html-webpack-plugin и т.п.
потому что html-webpack-plugin имеет inject: 'body' опцию и сам вставит все скрипты в конец.
Если же так хочется контролировать инжекты, то вот, в порядке бреда:
<head>
<meta charset="UTF-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<title><%= htmlWebpackPlugin.options.title %></title>
<% for (var css in htmlWebpackPlugin.files.css) { %>
<link rel="preload" as="style" type="text/css" crossorigin="anonymous" href="<%= htmlWebpackPlugin.files.css[css] %>" onload="this.rel='stylesheet'"/>
<% } %>
</head>
<body>
<!-- какой-то код -->
<% for (var js in htmlWebpackPlugin.files.js) { %>
<script async src="<%= htmlWebpackPlugin.files.js[js] %>"></script>
<% } %>
</body>
надеяться не надо на инструменты, а читать нормально доку и пользоваться.
История #3: корень всех зол
ну... не знаю, муху можно и мухобойкой прибить, можно и из базуки выстрелить. Результат будет один и тот же, вопрос только в целесообразности использования средства умерщвления.
Вы берете оптимизацию в разрезе отдельно, а смотреть надо в целом. Если у вас рендер меньше 16 мсек на страницу, то и бог с ней с мемоизацией. А если у вас 100+ объектов (а вы мап в мапе делаете), да и рендер уже выходит, допустим в 75 мсек? Не надо отвечать, это очередной холиварный вопрос, тут вопрос целесообразности, как я и говорил чуть выше
я предпочитаю не тратить время на то, что не дает профита
Следуя ваше логике: - я могу пойти к питонщикам и сказать, что их_такой_синаксисис полное говно - могу пойти к сишникам/джавистам и сказать, что их синтаксис и типизация слишком сложна, а работу с памятью я не понимаю и нафига оно вообще надо, в JS есть свой сборщик мусора и работает все прекрасно без обращений к нему - пойти в любой ООП и сказать, что прототипное наследование - отстой, потому что схема не прозрачна, а композиция - лучше! Зачем классы, когда можно процедурно набахать функций, вон с jQuery так все делали! - пойти в любую команию и сказать, нафига вы делаете микросервисные архитектуры и т.д. и т.п., возьмите ВордПресс, у него пыха не беке и работа с бд уже есть! А еще поставьте плагинчик, он вам и сваггер сам нарисует! - зачем CI/CD если есть FTP - зачем GIT если есть архиваторы
и т.д. и т.п.
И когда я скажу, что "я пришел к вам из JS, там все иначе, но я хочу узнать что-то новое", но все мне не будет нравиться, просто потому, что я так не привык...
Наблюдая за вашими комментариями под статьями, складывается впечатление, что вы не понимаете, зачем вам TS
Вы жили в других парадигмах, пришли в JS со "своим уставом" и удивляетесь, почему это не работает. Вам говорят, как принято в комьюнити сейчас, но вы упорно отказываетесь. На любой аргумент в пользу TS у вас 10 против, это нормально. Не нормально то, что вас должны все убедить перейти на TS под соусом вашей, якобы, открытости к новому.
На все вопросы даже в этой статье есть ответ. Бандлеры (роллап, вебпак, даже тот же гальп как таскраннер), плагины к ним делают те вещи, которые вы хотите, но не так, как вы хотите.
Давайте не будем лукавить: вы не собираетесь переходить на TS, вас не нужно убеждать, потому что кроме вас никто этого сделать не может. Вы не хотите принимать правила игры, потому что они вам не по вкусу, вы заложник своих привычек. С вашей точки зрения импорты не те, то не то, это не так...
Но как пользователь i18n-react не увидел никаких преимуществ для локализации в разрезе именно текста. Все манипуляции с кешированием берет на себя библиотека, есть гибкий HMTLBackendAPI, а для остального я использовал встроенный Intl
Да такой сценарий понятен, но, почему-то знание фреймворка Х превращает разраба в диснеевсого героя, у которого доллары в глазах крутятся
И затем компании тратят время на выбивание дури и подтягивание основ, но большинство не выдерживают и уходят работать на галеру, куда их с руками и ногами отрывают, попутно демпингуя в 0.
Я сам прошел путь от такого же человека, но у меня просто не было денег на курсы и я просто потихоньку работал, а основы подтягивал позже, о чем сейчас нисколько не жалею, хоть и потратил достаточно много времени.
Достаточно холиварный вопрос, но на лицо:
1) типичная проблема образования — переполнение низкокачественными кадрами и шутка про «забудь, чему тебя учили» вообще не смешная становится, потому что это реальность.
2) чистый бизнес — получаем прибыль в моменте. Да, базу вроде бы дали, показали то и се, а как усвоили ученики уже не их проблема.
3) когда соискатель выходит на рынок, у него уже в теории ламборгини в гараже стоит через пару лет, а по факту у него глаза на лоб лезут, видя, что происходит за кулисами компаний. И Эльдорадо в виде программирования в целом оказывается даже не прикольно — оказывается, тут лутают бабки не за просто знание доки и что такое html и css, да и борода не признак хипстерства
Понять можно всех, но за одним вопросом стоит череда других и это явно не проблема библиотек. Скорее, их использования и то, спорно достаточно
Как писать код, который удобно анализировать
… не говоря, что ты «командный игрок», а рассказав мне, что анализ кода так же сложен для ревьюера, и что ты знаешь, как оптимизировать свои пул-реквесты, чтобы они были читаемыми и понятными.
Читая вот это какой-нибудь джун запомнит это и будут писать mySuperNewAwesomeFunctionThatMakesSomeCoolStuff и будет ставить читабельность кода превыше его эффективности. Тут вопрос о компромиссе чтения кода и его работы. И вопрос, можно ли написать такой код, который будет эффективен, при этом ревьювер потратит 3 минуты на чтение его и сразу поймет?
Как разобраться в любом JS-фреймворке
… потому что дело не в звёздах GitHub, а в общих принципах, разделяемых большинством современных JS-фреймворков. Определение сильных и слабых сторон других фреймворков позволяет лучше понимать выбранный тобой фреймворк.
Звёзды на гите лишь небольшое указание, что если комьюнити одобряет, то на это можно посмотреть и потрать время на ресёрч и только тогда можно будет сказать что-либо о фреймворке. И я говорю сейчас исключительно в разрере какой-либо существующей бизнес задачи.
почему «данные должны двигаться вниз, а действия — вверх». Или почему состояние должно изменяться там, где оно было создано, а не глубже в иерархии компонентов.
«почему?» не объясняет «как?». Вот та самая библиотека Х как правило на первой странице своей документации отвечает на некоторые «почему?» и «как?».
у каждого проекта есть технический долг, нужно перестать ныть об этом и приступать к рефакторингу. Каждой новой фиче должен предшествовать небольшой рефакторинг кода.
Рефактор ради рефактора — хождение по кругу. Это не дает, конечно, право писать плохой код и все выходящие, в т.ч. опыт написания кода, но как правило техдолг остается техдолгом навсегда, потому что бизнесу вообще плевать на эффективность твоих алгоритмов до тех пор, пока он из-за этого не теряет деньги. Конечно, можно программировать «для души», но лично такой подход в моей жизни еще не прокормил (это дабы пресечь сразу этот вариант), а задачам бизнеса, снова, плевать на твою душу.
Я к чему вообще веду. Может, не реакт испортил разработку, а сами разработчики? Гикбрейнсы, Хекслеты, Яндекс.Практикумы, выпускающие непонятного кого, которые, наслушавшись обещаний о классной работе и печеньках в офисах, на собесе требуют 100к+ зарплаты?
Сейчас есть проект на работе, где нужны реализовать микрофронты + хост. Есть CI/CD и все тому прочее, проект крупный. Но «женить» это все очень больно, особенно, когда оказалось, что нельзя бить на чанки js дочерние модули (это из особо критичный проблем).
Кое-как франкенштейн работает, но сердце щимит от того, что есть Module Federation, который по сути решает кучу проблем, но…
Пробовал по-разному, полный шаринг всех пакетов в хосте и микрофронтах по Advanced API из примеров в репозитории, но «не повезло, не фортануло» (с). Кое-как адаптировал текущие решения из Module Federation к своему проекту и работать даже начало стабильнее, монтирование/размонтирование, по крайней мере, работает как часы
Заинтересовал config в ваше примере, о нем нет никакой информации. Может именно там есть что-то, что поможет мне :) Да и было бы интересно посмотреть на вашу демку
За статью спасибо конечно, хотя у меня навернулись слезы, потому что я не смог в Module Federation :(
Пуск же можно растянуть за края где-то аж на три четверти экрана. Неужели так не все часто нужные иконки помещаются в видимой части? Также их можно ж сделать мельче, в четверть от обычного размера (правда, подписи тогда не будет).
мне просто это не нужно, вот и не пользуюсь. Все самое основное в панели быстрого доступа, остальное через поиск панели, если есть необходимость и пара папок в панели быстрого доступа в Проводнике.
В общем, я не понимаю людей, которые на рабочем столе ярлыки хранят. Это отголоски каких-то древних привычек
Если это адресовано лично мне, то я нигде и не говорил, что храню и тем более пользуюсь ярлыками с рабочего стола. Установилась софтина, создала ярлык — и фиг с ней. Свой юзкейс я описал выше
А так — так все мы и живем привычками. Чистить зубы тоже привычка, по сути. Ярлык потерять не страшно, а документ важный — да, и я не понимаю тех, кто конкретно документы рабочие и важные на РС хранят. Не понимаю, но и не осуждаю.
То же самое, только не храню ничего в облаках (семейные фото, аудиотека и т.д. на внешнем винте), остальное в репозиториях.
На рабочем компе только ярлыки Outlook, интранета, телеги, зума и рабочий софт (и то, рабочий софт закреплен в панели)
Только кейс описанный в статье касается рядового офисного сотрудника, который часто работает с документами и обычно хранит их на постоянной основе на рабочем столе.
Лично у меня всегда пригорало, когда я видел компьютер матери и у нее весь рабочий стол в таблицах экселя, хаотичен и при этом она разбирается во всем этом :D
Справедливо, но не всегда удобно прокручивать пуск, особенно если что-то в папках и т.д. В общем, новый пуск я не использую на полную катушку :)
Видимо и с виртуальными рабочими столами я дал промах, но все-равно выработалась привычка не хранить в принципе ничего важного на диске С. Даже папку документов я перенес на другой ssd.
Как временное хранилище — вполне себе и, видимо, так это и подразумевалось в принципе, однако, юзверь зверь непредсказуемый :D
никогда не храню важные файлы на рабочем столе, с учетом нескольких смертей hdd без возможности восстановления.
рабочий стол должен быть хранилищем ярлыков быстрого доступа или группированного контента в моем понимании.
А если РС является файлопомойкой, то боюсь представить, что будет, если в 10ке использовать виртуальные рабочие столы и захламлять каждый
Прочел статью и не понял. Точнее, понимание уже есть, но мне объяснение давали такое:
элемент — фактически присутствует, узел — в целом абстрактная единица, его можно создать js, но не вставить на страницу. И в зависимости от методов, мы создаем либо узлы, либо элементы (appendChild vs InsertAdjacentTML)
Смотрю, что у многих возникает вопрос уровня Android vs iOs, Windows vs Linux.
Скажу одно — пока вы не попробуете и то, и то на одной и той же задаче, то не поймете разницы. И задача должна быть не уровня «сверстать лендинг» или набросать страницы в паге и собрать воедино.
Вы попробуйте обвеситься линтингом или тестить код хотя бы на уровне установки переменных сред Node.js. И то, и то, можно делать в и там, и там, но в ходе практики окончательно слез с гальпа.
Пока вы смотрите и на гальп и на вебпак в разрезе конкатенации файлов и перекладывании файлов из src, в dist, то однозначно вам подойдет gulp и вебпак излишен:)
заканчивается на выводе футера. Из того, что представлено это явно не футер для контейнера, а отдельная сущность и за такое надо бить по рукам
а может этот код будет работать каждый кадр?
да как угодно, только то что указано в примере - явно указание на то, что ваш разработчик обладает крайне низкой компетенцией
потому что html-webpack-plugin имеет inject: 'body' опцию и сам вставит все скрипты в конец.
Если же так хочется контролировать инжекты, то вот, в порядке бреда:
надеяться не надо на инструменты, а читать нормально доку и пользоваться.
ну... не знаю, муху можно и мухобойкой прибить, можно и из базуки выстрелить. Результат будет один и тот же, вопрос только в целесообразности использования средства умерщвления.
Вы берете оптимизацию в разрезе отдельно, а смотреть надо в целом. Если у вас рендер меньше 16 мсек на страницу, то и бог с ней с мемоизацией. А если у вас 100+ объектов (а вы мап в мапе делаете), да и рендер уже выходит, допустим в 75 мсек? Не надо отвечать, это очередной холиварный вопрос, тут вопрос целесообразности, как я и говорил чуть выше
я предпочитаю не тратить время на то, что не дает профита
Следуя ваше логике:
- я могу пойти к питонщикам и сказать, что их_такой_синаксисис полное говно
- могу пойти к сишникам/джавистам и сказать, что их синтаксис и типизация слишком сложна, а работу с памятью я не понимаю и нафига оно вообще надо, в JS есть свой сборщик мусора и работает все прекрасно без обращений к нему
- пойти в любой ООП и сказать, что прототипное наследование - отстой, потому что схема не прозрачна, а композиция - лучше! Зачем классы, когда можно процедурно набахать функций, вон с jQuery так все делали!
- пойти в любую команию и сказать, нафига вы делаете микросервисные архитектуры и т.д. и т.п., возьмите ВордПресс, у него пыха не беке и работа с бд уже есть! А еще поставьте плагинчик, он вам и сваггер сам нарисует!
- зачем CI/CD если есть FTP
- зачем GIT если есть архиваторы
и т.д. и т.п.
И когда я скажу, что "я пришел к вам из JS, там все иначе, но я хочу узнать что-то новое", но все мне не будет нравиться, просто потому, что я так не привык...
Короче, глупо все это...
Наблюдая за вашими комментариями под статьями, складывается впечатление, что вы не понимаете, зачем вам TS
Вы жили в других парадигмах, пришли в JS со "своим уставом" и удивляетесь, почему это не работает. Вам говорят, как принято в комьюнити сейчас, но вы упорно отказываетесь. На любой аргумент в пользу TS у вас 10 против, это нормально. Не нормально то, что вас должны все убедить перейти на TS под соусом вашей, якобы, открытости к новому.
На все вопросы даже в этой статье есть ответ. Бандлеры (роллап, вебпак, даже тот же гальп как таскраннер), плагины к ним делают те вещи, которые вы хотите, но не так, как вы хотите.
Давайте не будем лукавить: вы не собираетесь переходить на TS, вас не нужно убеждать, потому что кроме вас никто этого сделать не может. Вы не хотите принимать правила игры, потому что они вам не по вкусу, вы заложник своих привычек. С вашей точки зрения импорты не те, то не то, это не так...
К чему эта демагогия?
Хотя я думал, что в смарт засунуть реакт достаточно больно
Но как пользователь i18n-react не увидел никаких преимуществ для локализации в разрезе именно текста. Все манипуляции с кешированием берет на себя библиотека, есть гибкий HMTLBackendAPI, а для остального я использовал встроенный Intl
И затем компании тратят время на выбивание дури и подтягивание основ, но большинство не выдерживают и уходят работать на галеру, куда их с руками и ногами отрывают, попутно демпингуя в 0.
Я сам прошел путь от такого же человека, но у меня просто не было денег на курсы и я просто потихоньку работал, а основы подтягивал позже, о чем сейчас нисколько не жалею, хоть и потратил достаточно много времени.
Достаточно холиварный вопрос, но на лицо:
1) типичная проблема образования — переполнение низкокачественными кадрами и шутка про «забудь, чему тебя учили» вообще не смешная становится, потому что это реальность.
2) чистый бизнес — получаем прибыль в моменте. Да, базу вроде бы дали, показали то и се, а как усвоили ученики уже не их проблема.
3) когда соискатель выходит на рынок, у него уже в теории ламборгини в гараже стоит через пару лет, а по факту у него глаза на лоб лезут, видя, что происходит за кулисами компаний. И Эльдорадо в виде программирования в целом оказывается даже не прикольно — оказывается, тут лутают бабки не за просто знание доки и что такое html и css, да и борода не признак хипстерства
Понять можно всех, но за одним вопросом стоит череда других и это явно не проблема библиотек. Скорее, их использования и то, спорно достаточно
Читая вот это какой-нибудь джун запомнит это и будут писать mySuperNewAwesomeFunctionThatMakesSomeCoolStuff и будет ставить читабельность кода превыше его эффективности. Тут вопрос о компромиссе чтения кода и его работы. И вопрос, можно ли написать такой код, который будет эффективен, при этом ревьювер потратит 3 минуты на чтение его и сразу поймет?
Звёзды на гите лишь небольшое указание, что если комьюнити одобряет, то на это можно посмотреть и потрать время на ресёрч и только тогда можно будет сказать что-либо о фреймворке. И я говорю сейчас исключительно в разрере какой-либо существующей бизнес задачи.
«почему?» не объясняет «как?». Вот та самая библиотека Х как правило на первой странице своей документации отвечает на некоторые «почему?» и «как?».
Рефактор ради рефактора — хождение по кругу. Это не дает, конечно, право писать плохой код и все выходящие, в т.ч. опыт написания кода, но как правило техдолг остается техдолгом навсегда, потому что бизнесу вообще плевать на эффективность твоих алгоритмов до тех пор, пока он из-за этого не теряет деньги. Конечно, можно программировать «для души», но лично такой подход в моей жизни еще не прокормил (это дабы пресечь сразу этот вариант), а задачам бизнеса, снова, плевать на твою душу.
Я к чему вообще веду. Может, не реакт испортил разработку, а сами разработчики? Гикбрейнсы, Хекслеты, Яндекс.Практикумы, выпускающие непонятного кого, которые, наслушавшись обещаний о классной работе и печеньках в офисах, на собесе требуют 100к+ зарплаты?
Кое-как франкенштейн работает, но сердце щимит от того, что есть Module Federation, который по сути решает кучу проблем, но…
Пробовал по-разному, полный шаринг всех пакетов в хосте и микрофронтах по Advanced API из примеров в репозитории, но «не повезло, не фортануло» (с). Кое-как адаптировал текущие решения из Module Federation к своему проекту и работать даже начало стабильнее, монтирование/размонтирование, по крайней мере, работает как часы
Заинтересовал config в ваше примере, о нем нет никакой информации. Может именно там есть что-то, что поможет мне :) Да и было бы интересно посмотреть на вашу демку
За статью спасибо конечно, хотя у меня навернулись слезы, потому что я не смог в Module Federation :(
Аккордеон генератор на радио инпутах…
Где-то плачет <details /> и адепты семнатики и доступности.
Да и в целом с новыми девтулзами в хроме и гриды можно набросать быстро
мне просто это не нужно, вот и не пользуюсь. Все самое основное в панели быстрого доступа, остальное через поиск панели, если есть необходимость и пара папок в панели быстрого доступа в Проводнике.
Если это адресовано лично мне, то я нигде и не говорил, что храню и тем более пользуюсь ярлыками с рабочего стола. Установилась софтина, создала ярлык — и фиг с ней. Свой юзкейс я описал выше
А так — так все мы и живем привычками. Чистить зубы тоже привычка, по сути. Ярлык потерять не страшно, а документ важный — да, и я не понимаю тех, кто конкретно документы рабочие и важные на РС хранят. Не понимаю, но и не осуждаю.
На рабочем компе только ярлыки Outlook, интранета, телеги, зума и рабочий софт (и то, рабочий софт закреплен в панели)
Только кейс описанный в статье касается рядового офисного сотрудника, который часто работает с документами и обычно хранит их на постоянной основе на рабочем столе.
Лично у меня всегда пригорало, когда я видел компьютер матери и у нее весь рабочий стол в таблицах экселя, хаотичен и при этом она разбирается во всем этом :D
Видимо и с виртуальными рабочими столами я дал промах, но все-равно выработалась привычка не хранить в принципе ничего важного на диске С. Даже папку документов я перенес на другой ssd.
Как временное хранилище — вполне себе и, видимо, так это и подразумевалось в принципе, однако, юзверь зверь непредсказуемый :D
рабочий стол должен быть хранилищем ярлыков быстрого доступа или группированного контента в моем понимании.
А если РС является файлопомойкой, то боюсь представить, что будет, если в 10ке использовать виртуальные рабочие столы и захламлять каждый
элемент — фактически присутствует, узел — в целом абстрактная единица, его можно создать js, но не вставить на страницу. И в зависимости от методов, мы создаем либо узлы, либо элементы (appendChild vs InsertAdjacentTML)
Скажу одно — пока вы не попробуете и то, и то на одной и той же задаче, то не поймете разницы. И задача должна быть не уровня «сверстать лендинг» или набросать страницы в паге и собрать воедино.
Вы попробуйте обвеситься линтингом или тестить код хотя бы на уровне установки переменных сред Node.js. И то, и то, можно делать в и там, и там, но в ходе практики окончательно слез с гальпа.
Пока вы смотрите и на гальп и на вебпак в разрезе конкатенации файлов и перекладывании файлов из src, в dist, то однозначно вам подойдет gulp и вебпак излишен:)