Какие актуальные на сегодня статьи или книги,можно прочитать,чтобы понять асинхронность в JavaScript?

Question

[Виталий]

Интересует как можно реализовать асинхронный код в javaScript в целом,так и конкретно в фреймворках, таких как jQuery и Angular.js

Answer 1

[Сергей Протько]

1) про асинхронность - https://developer.mozilla.org/en-US/docs/Web/JavaS... и дальше гуглить что не понятно

2) про реализацию в библиотеках фреймворках (в порядке простоты реализации и сложности в поддержке, не спроста есть такая штука как callback-hell):
- колбэки
- промисы (ангуляр использует их повсюду к примеру, они же есть в jquery)
- корутины (имеет смысл с трансляторами типа babel.js так как генераторы появились только в ES2015)

Answer 2

[Павел Кононенко]

Вряд ли ради такого будут писать книги или статьи

Comments

[Виталий]

Асинхронность в JavaScript никому не интересна,или это настолько просто,что даже не требует объяснения ?

[Павел Кононенко]

Виталий: второе. Но если вы напишете, что именно не понятно, то получите ответ в двух-трех предложениях. Организация кода в AngularJS-проекте такая:
- controllers
- directives
- services
- filters
application.js
routes.js
config.js

[Виталий]

Возможно Вы не совсем поняли вопрос,или я не совсем правило его сформулировал.
В интернете есть много про асинхронность,но хотелось бы как то отфильтровать лишние.... старое не актуальное.....

[Сергей Протько]

Виталий: все старое актуальное... в целом в контексте JS вам надо разобраться с такой штукой как event loop, не так страшен черт. А вот управление потом исполнения в контексте event loop это да, поинтереснее, собственно я в ответе все перечислил, вариантов не особо много.

Павел Кононенко: причем тут организация кода в проектах? И да, то что вы привели это тип плохая практика.

[Павел Кононенко]

Сергей Протько: это еще почему плохая?

[Сергей Протько]

Павел Кононенко: angular styleguide не рекомендует так делать.

Я стараюсь придерживаться этих рекомендаций, они реально помогают держать код под контролем. Еще я упарываюсь по изоляции изменений и т.д. Скажем у меня все что касается маршрутизации и т.д. заперто в модуле navigation, и там только темплейты к маршрутам цепляются. Контроллеры для стэйтов/раутов используются исключительно для того что бы передать параметры в нужном виде в атрибуты директив. Логика UI раздроблена на независимые директивы которые легко покрыть тестами.

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

[Павел Кононенко]

Сергей Протько: у меня рельсовые проекты. Мне эта структура не подходит. Может, когда выйдет Rails 5 и мы начнем писать чисто апи, а гульпом собирать фронт, то я буду так делать)

[Сергей Протько]

Павел Кононенко: что вам мешает прямо сейчас делать на рельсах чисто API?

[Павел Кононенко]

Сергей Протько: тогда зачем мне рельсы? В 5 версии можно избавиться от избыточности этого всего. Сейчас все итак неплохо смотрится в assets pipeline. Не было никогда проблем с моей структурой, обкатано в 20+ крупных коммерческих и гос.проектов. Может в глубокой теории что-то и является минусом, но на практике с этими минусами не сталкиваюсь.

[Сергей Протько]

Павел Кононенко: я не знаю зачем вам рельсы) если бы я решил уйти в руби я бы брал синатру, а рельсы я не переношу (надо будет глянуть что там в 5-ой версии планируют)

Что до структуры проекта - простой вопрос, вы пишите юнит тесты? Только e2e? Как у вас с поддержкой этих 20+ проектов? Я сам использовал такую структуру где-то полтора года, но все же такой подход позволяет сильно связать руки разработчику в плане того как он может косячить со структурой. Да и с код ревью проще, и тесты проще писать, а это как по мне самый главный аргумент.

[Павел Кононенко]

Сергей Протько: я не один, поэтому не могу решать за всех. Команда из рельсовиков. У нас юнит-тесты на модели и контроллеры. Для тестирования клиентской стороны используем Capybara + ChromeDriver. Поэтому покрывать JS-код нет необходимости. Ориентироваться по коду достаточно просто. Привинтить вашу структуру пока невозможно

[Сергей Протько]

Павел Кононенко: капибара + хром это и есть E2E тесты, и я как раз от этого этой структурой и хотел избавиться - нормальное покрытие тестами обойдется слишком дорого (для меня прогон тестов в минуту это уже дико долго). У меня так же команда, и я навязываю эту структуру как раз таки что бы люди перестали писать как придется... Но у меня нет проблем с фреймворками и прочим.