tldr: к js функции можно допихть произвольных свойств. Но идея в контексте компонентов мне понравилась, попробуем.
/** Обратите внимание на импорт, мы залезли во внутренности EventCard и выдернули необходимое. Выглядит это посредственно */ import { ActionBar } from "./shared/components/EventCard/ActionBar"; import { StatusBar } from "./shared/components/EventCard/StatusBar";
В EventCard/index.tsx можно сделать
export { ActionBar } from "./ActionBar";
export { StatusBar } from "./StatusBar";
И в файле использования уже не так все плохо будет
import { EventCard, ActionBar, StatusBar } from "./shared/components/EventCard";
Copilot мне показался классным. Не подсчитывал, улучшает ли он реально продуктивность, но каждый день удивляет (в хорошем смысле) своими догадками!
10 USD/mo так себе ценник. Пока он тянет примерно на 3 USD/mo. Особенно учитывая, что при использовании нужно принять просто безумное соглашение по сбору и хранению личных данных. Он может собирать абсолютно все для своего обучения, будто троян специально себе поставил. Раз уж польза идет в обе стороны (Copilot помогает вам писать, а вы - его обучать), то ценник должен это отражать.
Такая глупенькая кликбэйтовость заголовка "помогут Вам стать Senior". Будто у людей "стать Senior" - это самоцель и они читают статьи только явно направленные на это =) Можно же было сказать "упростят процесс отладки", например.
Смотрю, и никак не могу поверить, что сделано "вечерами и на выходных". Просто потрясающе. Да даже на фулл-тайме осилить такое силами одного человека - это фантастика, какое же должно быть сочетание технических и творческих способностей. У меня к вам только лучи уважения. Дальнейших успехов вам в ваших проектах!
Тут стоит добавить важное замечание: не допускается сговор участников и способ разбиения исходного числа на сумму должен быть непредсказуем для других.
С редьюсерами такая ситуация, что относительно простые состояния (например, представляемые одним фундаментальным объектом JS без вложенностей) на них реализовать проще/понятнее и субъективно красивее. Именно на такие случаи в первую очередь и рассчитана эта библиотека: когда приложению требуется простое состояние с глобальной видимостью.
Сложная же логика с кучей акшенов и состоянием представляемым множеством связанных объектов удобнее реализовывается через класс / объект с методами.
Как и везде, нет универсального решения лучшего во всех случаях.
Редьюсер по определению своему - это чистая функция.
toLocalStorage ведетсебя как чистая функция. Он только записывает текущее значение состояния в localStorage не читая ничего обратно (это делает инициализатор) и не модифицируя состояние. Да, формально, это не чистая функция и, например, мемоизация невозможна (но и бессмысленна).
Своим именованием вы ломаете их eslint плагин, devtools
Упустил из виду, что средства разработки опираются на конвенции именования. Протестирую с eslint и devtools.
А зачем вы фризите входной объект? С одной стороны понятно, чтобы его никто не вздумал мутировать, но с другой стороны, это должно решаться иными средствами, например, типами.
Вы все правильно написали, это позволяет не просто не допустить незаконных мутаций, но и грубо сообщить об этом пользователю ошибкой. Предполагается, что после передачи входного объекта он становится частью внутреннего состояния библиотеки и больше не принадлежит пользователю.
К сожалению, типами это не решить. Да и plain JS пользователи, на сколько мне известно, существуют.
Асинхронный scheduling внушает опасение. Можно попать в infinite loop, который очень сложно сдетектить
Асинхронный вызов подписчиков был введен в основном как debouncing. В dev режиме планируется добавить детекцию бесконечного цикла обновлений с выводом предупреждения. (Эвристикой: считать количество вызовов подписчиков в единицу времени. Должно поймать основной процент проблем.)
По-хорошему, лучше делегировать обновление стейта самому фреймворку. Сделать один Provider c useState, use-хук будет писать и читать из этого провайдера, а react сам разберется с порядком обновлений
Пользователю тогда придется явно оборачивать корневой компонент в этот провайдер... Но может это действительно разумный трейд-офф.
Просто сначала подумал, что store.text явно указывается в списке зависимостей до его использования (и пока не указан, не доступен пользователю). Интересная фитча. Попробую поиграть с оборачиванием store в `Proxy` для автоматического детектирования чтения свойств. Еще раз благодарю за пример.
Кейсы с возможными устаревшими пропсами и зомби-чилдами не проверяли?
На сколько смог разобраться, данные "баги" больше на плечах пользователя, чем на библиотеке. Ну я повторюсь, что в частности с МобХ не достаточно знаком. В первом случаи пропсы должны быть указаны в списке зависимостей (и, соответственно, акшен зависящий от пропов должен запускаться синхронно через эффект). Во втором случаи, при использовании не-локального состояния лучше не делать никаких предположений о текущем состоянии, оно может быть любым (в рамках объявленного типа).
подписка на стейт по факту использования в отличии от безусловной подписки в хуке
Тут соглашусь, такая функция должна присутствовать даже в минимальном наборе. Будем добавлять возможность указания используемых полей объекта в хуке, по типу списка зависимостей.
Из статьи не понятно, как это может быть лучше с точки зрения безопасности: данные между чипом и МК передаются в открытом виде. Можно какой-то пример? Пока вижу выигрыш только в оффлоаде функций шифрования.
Проверки, что расшифровывался не мусор (или какая-то левая прошивка, но для этого же нужно знать ключ) - нет. Если юзер захочет убить устройство, то у него это получится.
Для слабых микроконтроллеров посмотрите еще в сторону TEA / XTEA
Очень компактный код, работает на месте, никаких таблиц. Использую его в бутлоадерах на AVR, функция расшифровки компилируется в ~400 байт (память программ).
tldr: к js функции можно допихть произвольных свойств. Но идея в контексте компонентов мне понравилась, попробуем.
В
EventCard/index.tsxможно сделатьИ в файле использования уже не так все плохо будет
Copilot мне показался классным. Не подсчитывал, улучшает ли он реально продуктивность, но каждый день удивляет (в хорошем смысле) своими догадками!
10 USD/mo так себе ценник. Пока он тянет примерно на 3 USD/mo. Особенно учитывая, что при использовании нужно принять просто безумное соглашение по сбору и хранению личных данных. Он может собирать абсолютно все для своего обучения, будто троян специально себе поставил. Раз уж польза идет в обе стороны (Copilot помогает вам писать, а вы - его обучать), то ценник должен это отражать.
Еще один из самых известных случаев - Spyro на PS1
https://www.youtube.com/watch?v=4GYSeXLr5sY
Супер круто!
В следующем году ждем SSD с УФ стиранием.
Такая глупенькая кликбэйтовость заголовка "помогут Вам стать Senior". Будто у людей "стать Senior" - это самоцель и они читают статьи только явно направленные на это =) Можно же было сказать "упростят процесс отладки", например.
Смотрю, и никак не могу поверить, что сделано "вечерами и на выходных". Просто потрясающе. Да даже на фулл-тайме осилить такое силами одного человека - это фантастика, какое же должно быть сочетание технических и творческих способностей. У меня к вам только лучи уважения. Дальнейших успехов вам в ваших проектах!
Тут стоит добавить важное замечание: не допускается сговор участников и способ разбиения исходного числа на сумму должен быть непредсказуем для других.
Чисто как мысленный эксперимент: импульс сброса через конденсатор подаем на триггер, а выход триггера отвечает за активацию кэша.
Это нераспаянный ethernet контроллер + трансформатор
картинка
С редьюсерами такая ситуация, что относительно простые состояния (например, представляемые одним фундаментальным объектом JS без вложенностей) на них реализовать проще/понятнее и субъективно красивее. Именно на такие случаи в первую очередь и рассчитана эта библиотека: когда приложению требуется простое состояние с глобальной видимостью.
Сложная же логика с кучей акшенов и состоянием представляемым множеством связанных объектов удобнее реализовывается через класс / объект с методами.
Как и везде, нет универсального решения лучшего во всех случаях.
Добавил в документацию соответстующее предупреждение.
И не спорю, не чистая. Я о том, что в конкретном use-case это несущественно, т.к. не вызовет каких-либо неприятностей.
Благодарен, что вы решили это сделать.
toLocalStorage ведет себя как чистая функция. Он только записывает текущее значение состояния в
localStorageне читая ничего обратно (это делает инициализатор) и не модифицируя состояние. Да, формально, это не чистая функция и, например, мемоизация невозможна (но и бессмысленна).Упустил из виду, что средства разработки опираются на конвенции именования. Протестирую с eslint и devtools.
Вы все правильно написали, это позволяет не просто не допустить незаконных мутаций, но и грубо сообщить об этом пользователю ошибкой. Предполагается, что после передачи входного объекта он становится частью внутреннего состояния библиотеки и больше не принадлежит пользователю.
К сожалению, типами это не решить. Да и plain JS пользователи, на сколько мне известно, существуют.
Асинхронный вызов подписчиков был введен в основном как debouncing. В dev режиме планируется добавить детекцию бесконечного цикла обновлений с выводом предупреждения. (Эвристикой: считать количество вызовов подписчиков в единицу времени. Должно поймать основной процент проблем.)
Пользователю тогда придется явно оборачивать корневой компонент в этот провайдер... Но может это действительно разумный трейд-офф.
Просто сначала подумал, что
store.textявно указывается в списке зависимостей до его использования (и пока не указан, не доступен пользователю). Интересная фитча. Попробую поиграть с оборачиваниемstoreв `Proxy` для автоматического детектирования чтения свойств. Еще раз благодарю за пример.Спасибо за комментарий.
На сколько смог разобраться, данные "баги" больше на плечах пользователя, чем на библиотеке. Ну я повторюсь, что в частности с МобХ не достаточно знаком.
В первом случаи пропсы должны быть указаны в списке зависимостей (и, соответственно, акшен зависящий от пропов должен запускаться синхронно через эффект).
Во втором случаи, при использовании не-локального состояния лучше не делать никаких предположений о текущем состоянии, оно может быть любым (в рамках объявленного типа).
Тут соглашусь, такая функция должна присутствовать даже в минимальном наборе. Будем добавлять возможность указания используемых полей объекта в хуке, по типу списка зависимостей.
Из статьи не понятно, как это может быть лучше с точки зрения безопасности: данные между чипом и МК передаются в открытом виде. Можно какой-то пример? Пока вижу выигрыш только в оффлоаде функций шифрования.
Проверки, что расшифровывался не мусор (или какая-то левая прошивка, но для этого же нужно знать ключ) - нет. Если юзер захочет убить устройство, то у него это получится.
Для чего, не понял? "MAC"?
Для слабых микроконтроллеров посмотрите еще в сторону TEA / XTEA
Очень компактный код, работает на месте, никаких таблиц. Использую его в бутлоадерах на AVR, функция расшифровки компилируется в ~400 байт (память программ).