С одной стороны то, что сейчас идёт в стандартной поставке windows и близко не лежало рядом с полноценной и даже онлайн версией, с другой — они, похоже, просто outlook.com завернут в электрон, как обычно, максимум — добавят пару интеграций. Правда не до конца понятно чем это лучше PWA версии, которая уже есть и отлично работает
Это пока, они очень активно обсуждают включение шведского (или, в противовес, делание английского вторым гос. языком. Это было бы безумно круто, но вряд ли пройдет). Не знаю, правда, сколько они собираются обсуждать еще.
Швеция находится в суперпозиции: с одной стороны, английского хватает с головой и большая редкость когда кто-то не говорит на английском (и ещё большая, если они его вообще не понимают), с другой — шаг влево/вправо от ритма жизни квартира-работа и оказывается что все на шведском. Постоянный Гугл транслейт и чувство отдалённости и чужести в стране давит и не даёт жить на полную. Тут и так хватает разницы в культуре и неожиданных открытий, язык все же нужен. Но можно смело ехать в страну без знаний шведского (но тогда со знанием английского, безусловно).
Вообще, если говорить про текущее состояние (мы от него немного постепенно отходим, но пока оно работало неплохо), мы балансируем с useReducer и контекстами для локальных стейтов компонента, для глобального стейта используем редакс (преимущественно для того, что взаимодействует с сервером), для форм — формик. Для редакса написали свой хук — useSaga. Как результат — useCallback большая редкость, в основном, в составе переиспользуемых хуков. useMemo я тоже стараюсь избегать в пользу реселекта из редакса. Практика показывает, что один большой, специфичный под компонент, реселект и один useSelector не только в разы проще тестировать, но и лучше для производительности.
P.S. useSaga принимает в качестве аргумента сагу, возвращает Result (который может быть init, loading and done) и функцию для запуска саги. Внутри он диспатчит экшен и ждет ответный экшен об выполнении саги делает магию с каналами и форками внутри саги. Я знаю что это злой хук, который противоречит идеям и концепциям и редакса, и реакта. Но работает и просто умопомрачительно сокращает код.
Тут стоит уточнить, что компонент, который задействует хотя бы 1 хук — по определению impure. Ибо все хуки — side effects. А значит и component — с side-effects. В лучшем случае вам удастся сохранить некоторые кусочки вашего компонента чистыми (например callback в useMemo). Это в принципе неплохо.
Это как посмотреть. Если копать в теорию — функции остаются чистыми, а хуки — эдакий способ передачи аргументов внутрь функции. Т.е. в отличие от класса, который хранит значения внутри себя, хуки (эффекты в окамл) все таки запрашиют значения у того, кто их запускает. Т.е. вы можете перевызвать функцию сколько угодно раз, передав значения эффектов как вам нужно, разве что синтаксис отличается от передачи аргументов. Что-то вроде
Так что в теории, функция полностью зависит от переданных аргументов и все еще чистая.
На практике вы, безусовно, правы, и никто так компоненты тестировать не будет, так что функции нечистые. Но это вопрос к организации стейта: вообще можно добиться хороших результатов по чистоте функции с применением useReduce и контекстов, ну или вообще того же редакса.
На самом деле это каждый раз спорный пример. Да заодно мы, например, не используем нативные кнопки, а используем обертки. И никто не может сказать что оптимальнее — пересоздать функцию и перерисовать обертку или useCallback.
Покуда каждый раз думать и выбирать что лучше — лишняя когнитивная нагрузка, зачастую рекомендация оборачивать все, если вы не делаете непосредственно конечный элемент (атом или саму обертку над кнопкой).
Про конкретный пример я согласен, тут он не нужен, но такое проклятие примитивных примеров — они слабо отражают реальный код и нужно натягивать сову на глобус.
Хуки — это новая функция, добавленная в React v16.8. Хуки позволяют использовать все возможности React без написания классовых компонентов.
Хоть технически хуки и являются функциями (классы в жс тоже технически являются функциями), хуки это скорее целая парадигма обработки сайд эффектов, основанная на эффектах в ОКамл, позволяющая сохранять значения при многократном вызове функции, оставляя функцию при этом чистой.
И нет, не все можно сделать на хуках, на хуках пока что нельзя ловить ошибки, например (componentDidCatch).
Другая причина в том, что не существует конкретного способа повторно использовать логику компонента, наделенного состоянием. Несмотря на то, что HOC (Higher-Order Component) и шаблоны Render Props (метод передачи props от родителя ребенку, используя функцию или замыкание) решают эту проблему, здесь требуется изменить код классового компонента. Хуки позволяют совместно использовать логику с отслеживанием состояния без изменения иерархии компонентов.
Ничего они не требуют изменять и рендер пропсы никуда не пропали. Основная проблема с HOC в том, что обычно навешивается по три-четыре, а то и больше HOC и, мало того, что они могут передавать конфликтующие значения, порой становится сложно понять кто и по какой причине передал значение, особенно если оно неправильное. Ну и их сложнее тестировать, чем хуки.
Ну и контекст до хуков был труден в использовании, мягко говоря.
Классовые компоненты не очень хорошо минимизируются, а также делают горячую перезагрузку ненадежной. Это еще одна причина для создания хуков.
У нас один из самописных хуков (точнее целое семейство) вообще отломали горячую перезагрузку, пункт не засчитан. И не то чтобы они были какими-то особо хитрыми, так, обертка вокруг редуксовского диспатча.
Ну и вообще, если разглагольствовать, то основная причина, конечно же, стремление построения реактивной библиотеки с чистыми функциями. Мало того, что функциональные компоненты обычно меньше и проще чем классовые, так они еще и не содержат обычно стейтов и сайд эффектов, так что их было просто тестировать и вообще они полюбились людям. Но команда реакта достаточно долго думала как же все таки дать возможность делать lifecycle хуки в функциональных компонентах, вот и придумала. Правда это принесло в них состояние, и хотя функции сами по себе по-прежнему чистые, компоненты опять могут хранить внутренний стейт, что опять повышает требования к тестированию.
Будут ли хуки React работать внутри классовых компонентов — Нет.
Ну если очень хочется, то да, да и никто не мешает миксовать компоненты или использовать хуки в HOC.
Можно обновить значение переменной состояния, просто передав новое значение в функцию обновления или передав callback. Второй способ с передачей callback-функции безопасен в использовании.
Без контекста не совсем понятно что имеется ввиду под "безопасен". Я бы обязательно спросил что это значит и ожидал услышать про захват замыканий и использование устаревшего значения при, например, асинхронной логике в обработчике (заодно, как показывает практика, это не самый тривиальный случай, который многие не понимают), или нежелание тянуть доп. параметр и пересоздавать каждый раз кэлбэк когда поменялось значение в сторе.
Теперь к вопросам. Большинство из них — перепечатка из документации. Но довольно важные моменты остались за кулисами. Например, нет ни одного вопроса про useCallback. А именно useCallback — та невеселая штука, которая превращает красивые примеры в не очень то красивый реальный код. Ну т.е. useState2 вообще должен выглядеть примерно так:
Еще не вижу правил использования хуков (никаких хуков внутри условных выражений, нельзя делать массивы хуков и тому подобное), заодно мне лично всегда интересно спрашивать "почему такие правила вообще существуют", но это уровень чуть выше.
Я вижу что вам нужен, как минимум, паспорт. СНИЛС тоже не помешает. Не знаю, может и можно через письмо, которое получить по свидетельству о рождении, но я бы не был в этом уверен.
Не хочу влазить, но все же замечу что Европа активно строит новую кросс-континентальную сеть, которая будет балансировать электричество между множеством стран, вырабатывая электричество там, где сейчас есть ветер/солнце/река и доставляя туда, где это нужно. Это огромные инвестиции и огромный проект, который, в будущем, принесет огромную пользу Европе. Так что развивают инфраструктуру везде.
Да и те же скандинавы — электрифицируют все что можно, у Норвежцев супер оптимистичный план, но у них есть довольно халявный источник большого количества электричесва (ГЭСы)
Паровозы остались в строю, часть ЖД сможет функционировать обратно. И паровые двигатели, в целом, не то чтобы что-то космическое, должно хватить на часть задач.
Вопросы по топику: что со школами и образованием в целом? Медициной? Разнообразие еды?
Насколько люди общительны и как просто заводить друзей (если возможно) и проявляется ли ксенофобия? (Например, в Швеции сложно найти работу не в IT, если в твоей фамилии нет букв типа ä).
Я угадал верный результат только потому что раз есть вопрос (и целая статья на эту тему), значит не очень очевидное поведение. Логическо только 2 подошла. Но, стоит признаться, я думал что приоритет у вычислительного рака NaN выше и все функции, которые на него натыкаются, так же должны возвращать NaN без исключений.
Более того, в некоторых языках (не будем тыкать в js пальцем) за NaN может скрываться не какое-то число, которое не влезло в дабл или что-то в этом духе, а строка или вообще объект. В нем выражение Math.pow(1, "give me a power!") или даже с смайликом в качестве степени — возможно. Единица в степени эмоджи, равная единице, выглядит странно.
Справедливости ради, в JS все наоборот, как обычно:
1 ** NaN // NaN
"Give me a power" ** 0 // 1
new Object() ** 0 // 1
Похоже на проблему на заправках (только в обратную сторону) — кто-то может приложить NFC карту, но потом просто уехать, следующий тогда на этой помпе может заправиться "бесплатно". (Circle K пишет что у них там камеры установлены, они считывают номер и могут определять такие ситуации. А еще могут отказывать в заправке, если у вашего номера есть недобросовестная история. Но я склонен не доверять этому)
Я нашел множество разных вариантов, в том числе — специальный конденсатор в схеме питания RFID метки, который выводится из строя полем определенной частоты и продолжительности. Такое ощущение, что есть тысячи разных способов. Пробемы с электромагнитным прожиганием заключаются в том, что либо нужен достаточно сильное поле, либо специальная конструкция.
Хорошая статья на вики, где сказано про специальные конденсаторы. Насколько я понял, это все же не относится к RFID, который реально просто деактивируется командой килл (которая, внутри, прожигает EEPROM или что она там делает).
Ответил ниже. Тоже сперва так подумал, но в других магазинах то не пищит, если просканировать, но пищит, если не сканировать. Там есть комманда kill, которая что-то делает аппаратно.
Обратно к оригинальному вопросу — больше похоже на механическое повреждение, брак или что-то в этом духе, чем что его выжгли этой машиной или, тем более, размагнитили.
ПС, хотя да, бывает что просто сканируют одежду над специальным устройством и деактивируют датчики. Вообще не знаю как оно работает, может и правда выжигают, интересно будет почитать.
С одной стороны то, что сейчас идёт в стандартной поставке windows и близко не лежало рядом с полноценной и даже онлайн версией, с другой — они, похоже, просто outlook.com завернут в электрон, как обычно, максимум — добавят пару интеграций. Правда не до конца понятно чем это лучше PWA версии, которая уже есть и отлично работает
Это пока, они очень активно обсуждают включение шведского (или, в противовес, делание английского вторым гос. языком. Это было бы безумно круто, но вряд ли пройдет). Не знаю, правда, сколько они собираются обсуждать еще.
Есть, и я очень надеюсь что это приложение — завёрнутый в вебвью мануал как это сделать. Странно ставить для этого отдельное приложение
Швеция находится в суперпозиции: с одной стороны, английского хватает с головой и большая редкость когда кто-то не говорит на английском (и ещё большая, если они его вообще не понимают), с другой — шаг влево/вправо от ритма жизни квартира-работа и оказывается что все на шведском. Постоянный Гугл транслейт и чувство отдалённости и чужести в стране давит и не даёт жить на полную. Тут и так хватает разницы в культуре и неожиданных открытий, язык все же нужен. Но можно смело ехать в страну без знаний шведского (но тогда со знанием английского, безусловно).
Вообще, если говорить про текущее состояние (мы от него немного постепенно отходим, но пока оно работало неплохо), мы балансируем с useReducer и контекстами для локальных стейтов компонента, для глобального стейта используем редакс (преимущественно для того, что взаимодействует с сервером), для форм — формик. Для редакса написали свой хук — useSaga. Как результат — useCallback большая редкость, в основном, в составе переиспользуемых хуков. useMemo я тоже стараюсь избегать в пользу реселекта из редакса. Практика показывает, что один большой, специфичный под компонент, реселект и один useSelector не только в разы проще тестировать, но и лучше для производительности.
P.S. useSaga принимает в качестве аргумента сагу, возвращает Result (который может быть init, loading and done) и функцию для запуска саги. Внутри
он диспатчит экшен и ждет ответный экшен об выполнении сагиделает магию с каналами и форками внутри саги. Я знаю что это злой хук, который противоречит идеям и концепциям и редакса, и реакта. Но работает и просто умопомрачительно сокращает код.Это как посмотреть. Если копать в теорию — функции остаются чистыми, а хуки — эдакий способ передачи аргументов внутрь функции. Т.е. в отличие от класса, который хранит значения внутри себя, хуки (эффекты в окамл) все таки запрашиют значения у того, кто их запускает. Т.е. вы можете перевызвать функцию сколько угодно раз, передав значения эффектов как вам нужно, разве что синтаксис отличается от передачи аргументов. Что-то вроде
Так что в теории, функция полностью зависит от переданных аргументов и все еще чистая.
На практике вы, безусовно, правы, и никто так компоненты тестировать не будет, так что функции нечистые. Но это вопрос к организации стейта: вообще можно добиться хороших результатов по чистоте функции с применением useReduce и контекстов, ну или вообще того же редакса.
На самом деле это каждый раз спорный пример. Да заодно мы, например, не используем нативные кнопки, а используем обертки. И никто не может сказать что оптимальнее — пересоздать функцию и перерисовать обертку или useCallback.
Покуда каждый раз думать и выбирать что лучше — лишняя когнитивная нагрузка, зачастую рекомендация оборачивать все, если вы не делаете непосредственно конечный элемент (атом или саму обертку над кнопкой).
Про конкретный пример я согласен, тут он не нужен, но такое проклятие примитивных примеров — они слабо отражают реальный код и нужно натягивать сову на глобус.
Это косвенно следует из «нельзя использовать хуки в циклах» https://reactjs.org/docs/hooks-rules.html
Конечно, теоретически ничего не взорвется, но нужно быть супер уверенным в том что массив не может измениться никогда.
Хоть технически хуки и являются функциями (классы в жс тоже технически являются функциями), хуки это скорее целая парадигма обработки сайд эффектов, основанная на эффектах в ОКамл, позволяющая сохранять значения при многократном вызове функции, оставляя функцию при этом чистой.
И нет, не все можно сделать на хуках, на хуках пока что нельзя ловить ошибки, например (componentDidCatch).
Ничего они не требуют изменять и рендер пропсы никуда не пропали. Основная проблема с HOC в том, что обычно навешивается по три-четыре, а то и больше HOC и, мало того, что они могут передавать конфликтующие значения, порой становится сложно понять кто и по какой причине передал значение, особенно если оно неправильное. Ну и их сложнее тестировать, чем хуки.
Ну и контекст до хуков был труден в использовании, мягко говоря.
У нас один из самописных хуков (точнее целое семейство) вообще отломали горячую перезагрузку, пункт не засчитан. И не то чтобы они были какими-то особо хитрыми, так, обертка вокруг редуксовского диспатча.
Ну и вообще, если разглагольствовать, то основная причина, конечно же, стремление построения реактивной библиотеки с чистыми функциями. Мало того, что функциональные компоненты обычно меньше и проще чем классовые, так они еще и не содержат обычно стейтов и сайд эффектов, так что их было просто тестировать и вообще они полюбились людям. Но команда реакта достаточно долго думала как же все таки дать возможность делать lifecycle хуки в функциональных компонентах, вот и придумала. Правда это принесло в них состояние, и хотя функции сами по себе по-прежнему чистые, компоненты опять могут хранить внутренний стейт, что опять повышает требования к тестированию.
Ну если очень хочется, то да, да и никто не мешает миксовать компоненты или использовать хуки в HOC.
Без контекста не совсем понятно что имеется ввиду под "безопасен". Я бы обязательно спросил что это значит и ожидал услышать про захват замыканий и использование устаревшего значения при, например, асинхронной логике в обработчике (заодно, как показывает практика, это не самый тривиальный случай, который многие не понимают), или нежелание тянуть доп. параметр и пересоздавать каждый раз кэлбэк когда поменялось значение в сторе.
Теперь к вопросам. Большинство из них — перепечатка из документации. Но довольно важные моменты остались за кулисами. Например, нет ни одного вопроса про useCallback. А именно useCallback — та невеселая штука, которая превращает красивые примеры в не очень то красивый реальный код. Ну т.е. useState2 вообще должен выглядеть примерно так:
Еще не вижу правил использования хуков (никаких хуков внутри условных выражений, нельзя делать массивы хуков и тому подобное), заодно мне лично всегда интересно спрашивать "почему такие правила вообще существуют", но это уровень чуть выше.
Спасибо, мы вам перезвоним.
Открыв страницу https://www.gosuslugi.ru/help/faq/c-1/2752
Я вижу что вам нужен, как минимум, паспорт. СНИЛС тоже не помешает. Не знаю, может и можно через письмо, которое получить по свидетельству о рождении, но я бы не был в этом уверен.
Оба портала требуют чтобы пользователю было хотя бы 14 лет. Решение для школьников, естественно.
Не хочу влазить, но все же замечу что Европа активно строит новую кросс-континентальную сеть, которая будет балансировать электричество между множеством стран, вырабатывая электричество там, где сейчас есть ветер/солнце/река и доставляя туда, где это нужно. Это огромные инвестиции и огромный проект, который, в будущем, принесет огромную пользу Европе. Так что развивают инфраструктуру везде.
Да и те же скандинавы — электрифицируют все что можно, у Норвежцев супер оптимистичный план, но у них есть довольно халявный источник большого количества электричесва (ГЭСы)
Паровозы остались в строю, часть ЖД сможет функционировать обратно. И паровые двигатели, в целом, не то чтобы что-то космическое, должно хватить на часть задач.
Вопросы по топику: что со школами и образованием в целом? Медициной? Разнообразие еды?
Насколько люди общительны и как просто заводить друзей (если возможно) и проявляется ли ксенофобия? (Например, в Швеции сложно найти работу не в IT, если в твоей фамилии нет букв типа ä).
Я угадал верный результат только потому что раз есть вопрос (и целая статья на эту тему), значит не очень очевидное поведение. Логическо только 2 подошла. Но, стоит признаться, я думал что приоритет у вычислительного рака NaN выше и все функции, которые на него натыкаются, так же должны возвращать NaN без исключений.
Более того, в некоторых языках (не будем тыкать в js пальцем) за NaN может скрываться не какое-то число, которое не влезло в дабл или что-то в этом духе, а строка или вообще объект. В нем выражение
Math.pow(1, "give me a power!")или даже с смайликом в качестве степени — возможно. Единица в степени эмоджи, равная единице, выглядит странно.Справедливости ради, в JS все наоборот, как обычно:
Похоже на проблему на заправках (только в обратную сторону) — кто-то может приложить NFC карту, но потом просто уехать, следующий тогда на этой помпе может заправиться "бесплатно". (Circle K пишет что у них там камеры установлены, они считывают номер и могут определять такие ситуации. А еще могут отказывать в заправке, если у вашего номера есть недобросовестная история. Но я склонен не доверять этому)
Я нашел множество разных вариантов, в том числе — специальный конденсатор в схеме питания RFID метки, который выводится из строя полем определенной частоты и продолжительности. Такое ощущение, что есть тысячи разных способов. Пробемы с электромагнитным прожиганием заключаются в том, что либо нужен достаточно сильное поле, либо специальная конструкция.
Хорошая статья на вики, где сказано про специальные конденсаторы. Насколько я понял, это все же не относится к RFID, который реально просто деактивируется командой килл (которая, внутри, прожигает EEPROM или что она там делает).
Ответил ниже. Тоже сперва так подумал, но в других магазинах то не пищит, если просканировать, но пищит, если не сканировать. Там есть комманда kill, которая что-то делает аппаратно.
Да, я уже понял. Полез гуглить — у них есть kill command (https://itlaw.wikia.org/wiki/Kill_command#:~:text=Definition,responding%20to%20any%20additional%20commands.) (для выжигания электромагнитным импульсом нужно использовать магнитрон из микроволновки, что не есть хорошо в магазине, покуда он выжгет все, на что попадет). Вряд ли NFC поддерживает эту команду.
Обратно к оригинальному вопросу — больше похоже на механическое повреждение, брак или что-то в этом духе, чем что его выжгли этой машиной или, тем более, размагнитили.
ПС, хотя да, бывает что просто сканируют одежду над специальным устройством и деактивируют датчики. Вообще не знаю как оно работает, может и правда выжигают, интересно будет почитать.