Задачи на собеседованиях. Event loop. JS

Привет! На одном из собеседований была вот такая задача:

function log(x) {
return () => console.log(x);
}

document.addEventListener('myevent', log('A'));
document.dispatchEvent(new CustomEvent('myevent'));
setTimeout(log('B'), 0);
setTimeout(log('C'), 16);
requestAnimationFrame(log('D'));
Promise.resolve().then(log('E'));
window.addEventListener('message', log('F'));
window.postMessage({}, location.origin);

Тот случай, когда сложнее вспомнить, что является макро-задачей, что микро, а что ни тем ни другим

Rematch — Redux без шаблонного кода

Не знал о таком конфиге, спасибо

Rematch — Redux без шаблонного кода

Отмечу, что Rematch постоянно развивается и улучшается

Судя по их гитхабу, последний коммит был почти год назад

Rematch — Redux без шаблонного кода

Статья ведь не об этом, а о преимуществах перед нативным Redux

Rematch — Redux без шаблонного кода

У MobX, как минимум, огромный вес пакета.

Feature-Sliced Design – альтернативный подход к организации кода приложений

Да, к сожалению, это один из кейсов, которые не до конца учтены в методологии. Это можно считать одним из исключений, поскольку, если бы мы задавали useAppDispatch и useAppSelector в слое app, нарушение принципов было бы куда серьезней.

По поводу таких кейсов советую обращаться к ребятам в телеграмм канал, там подскажут компромисное решение. https://t.me/feature_sliced

FSD - рекомендации по написанию кода, так что от них иногда можно отступать. Но не сильно и не часто) Спасибо за замечание!

Feature-Sliced Design – альтернативный подход к организации кода приложений

Вот в этом комментарии отвечал на схожий вопрос (https://habr.com/ru/companies/avito/articles/752536/comments/#comment_25853686), если из этого ответа будет не до конца понятно, предлагаю ознакомиться с этим проектом (https://github.com/egorchh/production-project). Если ясней не станет, то отпишитесь, пожалуйста, я попробую расписать максимально подробный ответ.

Feature-Sliced Design – альтернативный подход к организации кода приложений

Прошу прощения за долгий ответ, был в отпуске.

Насколько я понял примеры:

1) Пусть в глобальном сторе у нас будут счетчики. Под каждый счетчик мы можем создать свою сущность или сделать единую изменяемую сущность счетчика (в зависимости от того, насколько они отличаются друг от друга). В этой сущности (слой entity) мы как раз будем обрабатывать запрос приходящий с сервера или работать с счетчиками через клиент и посылать данные об их изменении в глобальный стор. А в нужных нам местах брать информацию о счетчиках из глобального стора.

Таким образом мы можем посылать данные в стор и забирать их оттуда без нарушения потока данных. Поскольку, хоть инициализация стора и хранится в слое app, сам по себе стор распростаняется на все приложение.

2) К сожалению, не совсем понял пример. Роут-конфиг (скрин ниже) также хранится в слое app. В нашем выпадающем меню, которое, |скорее всего является виджетом, каждый элемент - ссылка <Link/>

Кликаем по ссылке, перемещается по нужному роуту.

Надеюсь, что хотя бы приблизительно правильно понял о чем идет речь в примерах. Если нет, то буду рад более точным примерам, желательно с кодом и схемой структуры.

Feature-Sliced Design – альтернативный подход к организации кода приложений

Прошу прощения за долгий ответ, был в отпуске.

Да, конечно. Так как api и ui - сегменты и находятся в одном слайсе, они могут использовать друг друга. А вот уже из слайса мы импортируем только то, что нам понадобится на слое выше.

5 новинок CSS в адаптивной верстке, которые можно использовать уже сейчас

Эта статья - луч света. Я уже решил костылять в рабочей задаче, но тут увидел новые единицы измерения, применил и ,о чудо, заработало. Спасибо за качественный контент и сэкономленные нервы!

Feature-Sliced Design – альтернативный подход к организации кода приложений

Здравствуйте, поскольку не работал с Zustand, приведу пример на Redux Toolkit. Думаю, логика будет идентична.

1 шаг:

Поскольку на все приложение один глобальный стор, его стоит объявить и конфигурировать в app. На скрине ниже: конфигурируем store в одноименном файле, также к конфигурации относится не только объявление стора, но и глобальные типы, дополнительные инструменты. В сегменте ui создаем hoc с оберткой (hoc тут необязательный, можем просто обернуть компонент в провайдер). StoreProvider импортируем из app, оборачиваем в него корневой компонент. Корневой компонент находится все слоев, можно представить его выше слоя app по иерархии (такое исключение из правил).

Структура слоя app

StoreProvider.tsx

Корневой файл приложения, обернутый в StoreProvider

2 шаг:

Нам нужно работать с глобальным стейтом в компонентах, которые находятся ниже по иерархии слоев:

Посмотрим на примере фичи:

В рамках приведенной ниже фичи, мы создаем слайс loginSlice, селекторы, если необходимо, asynThunk'и, типы. Все эти сущности относятся только к работе с той частью стора, которая напрямую связана с фичей

То есть работа со с глобальным стейтом инкапсулирована на уровне каждого слайса. Такой подход, не позволяет нам заэффектить ту часть стора, которая не относится к данной фиче.

features/AuthByUsername

Схема работы с глобальным стейтом

Надеюсь, что сумел раскрыть суть подхода, если будут вопросы, с радостью расскажу более подробно.

Feature-Sliced Design – альтернативный подход к организации кода приложений

Цель статьи не прорекламировать FSD, а рассказать о ней, описать минусы и плюсы. Использовать ее или нет - решение каждого разработчика.

Сожалею, если мне не удалось донести всех аспектов и раскрыть тему до конца. Буду учиться писать статьи более развернуто и аргументированно. Спасибо за мнение!

Feature-Sliced Design – альтернативный подход к организации кода приложений

FSD предлагает более удобную для разработки структуру приложения. Когда все разложено по полочкам, легче найти место для новой фичи или экрана. Сложно спорить с тем, что порядок в структуре проекта более выгоден для разработки.

Даже если мы разобьем весь проект на компоненты по одной строчке, как в вашем примере выше, это не значит что структура будет расширяемой и гибкой. Мы все еще можем столкнуться с высокой связностью модулей проекта между собой, что чревато сайд эффектами при внедрении нового функционала и тд.

Если заинтересованы методологией, советую попробовать внедрить ее в свой проект или написать его с нуля, тогда, уверен, что вы почувствуете преимущества.

Feature-Sliced Design – альтернативный подход к организации кода приложений

Согласен, на сайте FSD достаточно простые примеры, которые нужны там скорее для ознакомления с базовыми концепциями методологии. Однако методология хорошо себя показывает в рамках моей компании, несколько проектов переведены на FSD.

К сожалению, не могу привести пример проектов по соображениям NDA, однако предлагаю вам ознакомиться с примерами реальных проектов, которые предоставлены на официальной странице гитхаба Feature Sliced Design: https://github.com/feature-sliced/examples (эти примеры и много другое также можно найти по ссылке с доп. информацией в конце статьи https://github.com/egorchh/Feature-Sliced-Design-information#примеры)

Также вы можете ознакомиться с моим пет-проектом. Крупное приложение построенное на FSD - https://github.com/egorchh/production-project. (можно удобно запустить на своем пк)

Feature-Sliced Design – альтернативный подход к организации кода приложений

Здравствуйте, не совсем понял суть комментария, не могли бы вы более подробно описать?

Feature-Sliced Design – альтернативный подход к организации кода приложений

Спасибо!