В целом, фишка актуальна для большинства фронтенд фреймворков, потому что большая часть из них перерисовывает только то, что изменилось, однако иногда меняется не только то, что задумывалось)
Согласен, что многие из этих вопрос борщ и вероятность того, что вы когда-то реально с ними столкнетесь в бою мала, но их спрашивают и нужно быть готовым, что и этот борщ вас могут спросить. А так да, отвечать на вопросы и решать алгосы, которые никогда в жизни не пригодятся - отстой.
Если создать строку через конструктор, new String(''), то она явно будет обьектом, кринжовый вопрос. А вообще в JS есть такая история как boxing/unboxing и все примитивы оборачиваются в объекты, для того чтобы мы могли использовать у них методы, например такие как toLowerCase() и тд. Так что вопрос может быть в каком-то смысле был на знание этого, просто странно сформулирован. Вот тут можно почитать - тык.
Насколько я знаю, JS хранит массив в памяти как объект с числовыми ключами, ну и тогда ответ на второй вопрос следует из первого - нет, зависимости нет, так как это объект, а в объекте можно хранить все.
Да, тут немного сложно, я применял ее для кэширования картинок, которые появляются во viewport, чтобы пользователь при повторном заходе сразу видела красивую картинку и для кастомной fallback страницы при отсутствии сети. Еще насколько я знаю, можно делать некое проксирование запросов, что тоже бывает полезно.
Big O — нотация, которая позволяет определить верхнюю границу скорости работы алгоритма. Она описывает отношение входных данных ко времени, за которое алгоритм сможет их обработать.
Это тоже не совсем верно, Big O - асимптотическая сложность, которая описывает верхнюю границу сложности алгоритма при увеличении размера входных данных, или как рост размера входных данных влияет на количество шагов. Но никак не отношение данных ко времени.
Раз уж вы приводите пример и устойчивых и неустойчивых сортировок, то было бы здорово привести пример устойчивой сортировки за O(n * log(n)), потому что про них тоже довольно часто спрашивают, например Merge Sort хорошо бы подошел - https://ru.wikipedia.org/wiki/Сортировка_слиянием.
Еще думаю у Quick Sort было бы полезно показать худший случай, где сортировка за O(n ** 2), раз вы его упоминаете.
Оно срабатывает не только для запросов из JavaScript, оно срабатывает для всех запросов страниц/статических файлов/скриптов и тд.
Да, можно повесить обработчик и добавить что-то в headers каждого запроса, но есть ограничения. Если интересно, можно почитать тут подробнее, грамотный ответ на ваш вопрос - https://qna.habr.com/q/553673
Согласен, что Service Workers стоят внимания, но мне показалось запихать в одну статью Shared/Dedicated/Service Workers будет слишком, в плане, материала по Service Workers точно наберется на еще одну статью, со всей его специфичностью.
Да и про Service Worker почти все знают, так как он на слуху, а вот с Shared/Dedicated Workers как по мне люди не очень знакомы.
Dedicated Workers - 97%, все поддерживает, кроме Opera Mini(Даже IE в последних версиях карл) Shared Workers - 53%, тут хуже, с десктопными браузерами все нормально, до мобильных еще не добралась технология https://caniuse.com/?search=web workers
Dedicated можно спокойно юзать, Shared в целом тоже можно использовать только на Desktop, особенно если основной пользователь это пользователь именно с Desktop'a
Думаю, что вложенность все-таки не настолько большая, чтобы она могла разрушать инкапсуляцию, если так, то скорее всего у вас уже какой-то overengineering и компоненты в 3 строки) ИМХО
Drilling CSS переменных вниз звучит очень страшно и уж точно ломает масштабируемость)) ИМХО
А по-поводу, @ container, очевидно, что они скоро будут активно использоваться, но думаю, что tailwind их внедрит как только у них появится обширная поддержка(сейчас это 86%, что не так много), а если уж прямо сейчас хочется, то по первой ссылке в гугле с 600 звездами на github есть либа - https://github.com/tailwindlabs/tailwindcss-container-queries
А в чем тогда преимущество tailwind если вы все равно длинные стили выносите в отдельный от вашего компонента объект с @apply?
Преимущество проявляется когда вы пишете максимально атомарные компоненты, с небольшим количеством стилей, а также когда вы пишете адаптив для 4 устройств например(вы вместо того, чтобы писать огромную вложенность из @ media, просто пишете sm: xl: lg:, etc...), также темизация элементарна. Если все ваши компоненты огромные и у каждого элемента по 20-30 стилей, пожалуй, tailwind не очень.
И забыли еще один большой минус tailwind - у него свое понятие размеров и цветов, надо запоминать что означают все эти bg-red-400 и mr-10. Если бы 10 означало 10px, это бы еще понятно, но 10 - это что-то относительно rem. Очень странная логика у tailwind.
Мало кто пользуется именно этими значениями, обычно они переопределяются кастомным конфигом и делаются понятными в вашей команде, вместо bg-red-400 -> bg-red-base например, mr-10 -> mr-40 можно превратить, если вам так будет удобнее, да и к тому что одна единица 4px довольно быстро привыкаешь
Думаю, вы немного не поняли, в каком контексте я показал этот пример, тут суть была не в том, что написано в этих стилях, в этом примере это играет второстепенную роль, первостепенно я хотел показать, что можно избежать спагетти кода в HTML(огромной награмажденности классов), на который многие ошибочно указывают при споре насчет того, насколько Tailwind захламляет разметку. Если уж говорить про сам код, то это просто какое-то мессиво из непонятных переменных, приправленное не всегда логичной организацией и уместными свойствами и в целом какой-то правильно организацией кода в примере не пахнет.
Думаю это не проблема конкретно Tailwind, я бы больше сказал, что это проблема всего IT, курсы аля "Как стать middle разработчиком за 3 месяца", гораздо больше влияют на то, что люди меньше изучают базу и сразу лезут во фреймворки(потому что на курсе сказали, что знание всего остального не обязательно и можно загуглить)/другие инструменты, которые являются надстройкой над чем-то базовым + изобилие готовых решений, которыми все пользуются тоже этому способствует. Однако я не считаю, что Tailwind таковым является, мне кажется, что Tailwind больше про альтернативный подход, а не про готовые решения, он явно никак не влияет на понимание общего flow разработки/работы с дизайнером и тд
Да, в devtools, есть кнопочка rotate.
Звучит интересно, попробую, спасибо!
В целом, фишка актуальна для большинства фронтенд фреймворков, потому что большая часть из них перерисовывает только то, что изменилось, однако иногда меняется не только то, что задумывалось)
Я же фронтендер Никита, а не типограф Никита)
Там ссылка на refactoring.guru, он почему-то не работает без впнки, попробуй с впн зайти
Согласен, что многие из этих вопрос борщ и вероятность того, что вы когда-то реально с ними столкнетесь в бою мала, но их спрашивают и нужно быть готовым, что и этот борщ вас могут спросить. А так да, отвечать на вопросы и решать алгосы, которые никогда в жизни не пригодятся - отстой.
Да, вы правы, за это отвечает движок
Так никто не делает, потому что это не рекомендуется делать стандартами, эти конструкторы, вроде как, для внутреннего использования.
Если создать строку через конструктор, new String(''), то она явно будет обьектом, кринжовый вопрос.
А вообще в JS есть такая история как boxing/unboxing и все примитивы оборачиваются в объекты, для того чтобы мы могли использовать у них методы, например такие как toLowerCase() и тд. Так что вопрос может быть в каком-то смысле был на знание этого, просто странно сформулирован. Вот тут можно почитать - тык.
Насколько я знаю, JS хранит массив в памяти как объект с числовыми ключами, ну и тогда ответ на второй вопрос следует из первого - нет, зависимости нет, так как это объект, а в объекте можно хранить все.
Да, тут немного сложно, я применял ее для кэширования картинок, которые появляются во viewport, чтобы пользователь при повторном заходе сразу видела красивую картинку и для кастомной fallback страницы при отсутствии сети. Еще насколько я знаю, можно делать некое проксирование запросов, что тоже бывает полезно.
Это тоже не совсем верно, Big O - асимптотическая сложность, которая описывает верхнюю границу сложности алгоритма при увеличении размера входных данных, или как рост размера входных данных влияет на количество шагов. Но никак не отношение данных ко времени.
Раз уж вы приводите пример и устойчивых и неустойчивых сортировок, то было бы здорово привести пример устойчивой сортировки за O(n * log(n)), потому что про них тоже довольно часто спрашивают, например Merge Sort хорошо бы подошел - https://ru.wikipedia.org/wiki/Сортировка_слиянием.
Еще думаю у Quick Sort было бы полезно показать худший случай, где сортировка за O(n ** 2), раз вы его упоминаете.
Оно срабатывает не только для запросов из JavaScript, оно срабатывает для всех запросов страниц/статических файлов/скриптов и тд.
Да, можно повесить обработчик и добавить что-то в headers каждого запроса, но есть ограничения. Если интересно, можно почитать тут подробнее, грамотный ответ на ваш вопрос - https://qna.habr.com/q/553673
Согласен, что Service Workers стоят внимания, но мне показалось запихать в одну статью Shared/Dedicated/Service Workers будет слишком, в плане, материала по Service Workers точно наберется на еще одну статью, со всей его специфичностью.
Да и про Service Worker почти все знают, так как он на слуху, а вот с Shared/Dedicated Workers как по мне люди не очень знакомы.
Dedicated Workers - 97%, все поддерживает, кроме Opera Mini(Даже IE в последних версиях карл)
Shared Workers - 53%, тут хуже, с десктопными браузерами все нормально, до мобильных еще не добралась технология
https://caniuse.com/?search=web workers
Dedicated можно спокойно юзать, Shared в целом тоже можно использовать только на Desktop, особенно если основной пользователь это пользователь именно с Desktop'a
Идеальный ответ!
Думаю, что вложенность все-таки не настолько большая, чтобы она могла разрушать инкапсуляцию, если так, то скорее всего у вас уже какой-то overengineering и компоненты в 3 строки) ИМХО
Drilling CSS переменных вниз звучит очень страшно и уж точно ломает масштабируемость)) ИМХО
А по-поводу, @ container, очевидно, что они скоро будут активно использоваться, но думаю, что tailwind их внедрит как только у них появится обширная поддержка(сейчас это 86%, что не так много), а если уж прямо сейчас хочется, то по первой ссылке в гугле с 600 звездами на github есть либа - https://github.com/tailwindlabs/tailwindcss-container-queries
Преимущество проявляется когда вы пишете максимально атомарные компоненты, с небольшим количеством стилей, а также когда вы пишете адаптив для 4 устройств например(вы вместо того, чтобы писать огромную вложенность из @ media, просто пишете sm: xl: lg:, etc...), также темизация элементарна. Если все ваши компоненты огромные и у каждого элемента по 20-30 стилей, пожалуй, tailwind не очень.
Мало кто пользуется именно этими значениями, обычно они переопределяются кастомным конфигом и делаются понятными в вашей команде, вместо bg-red-400 -> bg-red-base например, mr-10 -> mr-40 можно превратить, если вам так будет удобнее, да и к тому что одна единица 4px довольно быстро привыкаешь
Думаю, вы немного не поняли, в каком контексте я показал этот пример, тут суть была не в том, что написано в этих стилях, в этом примере это играет второстепенную роль, первостепенно я хотел показать, что можно избежать спагетти кода в HTML(огромной награмажденности классов), на который многие ошибочно указывают при споре насчет того, насколько Tailwind захламляет разметку.
Если уж говорить про сам код, то это просто какое-то мессиво из непонятных переменных, приправленное не всегда логичной организацией и уместными свойствами и в целом какой-то правильно организацией кода в примере не пахнет.
Думаю это не проблема конкретно Tailwind, я бы больше сказал, что это проблема всего IT, курсы аля "Как стать middle разработчиком за 3 месяца", гораздо больше влияют на то, что люди меньше изучают базу и сразу лезут во фреймворки(потому что на курсе сказали, что знание всего остального не обязательно и можно загуглить)/другие инструменты, которые являются надстройкой над чем-то базовым + изобилие готовых решений, которыми все пользуются тоже этому способствует.
Однако я не считаю, что Tailwind таковым является, мне кажется, что Tailwind больше про альтернативный подход, а не про готовые решения, он явно никак не влияет на понимание общего flow разработки/работы с дизайнером и тд