Вместо последовательного перебора всех правил можно одновременно запустить проверку всех. Этот момент не остался без тестирования производительности и результаты не заставили себя ждать.
А вы как бы в курсе что оно будет все равно в одном потоке выполнятся и никакой параллельности не будет? Если вы конечно не рожаете пулл процессов для проверки роутов.
Фишку с непоследовательным выполнением миддлеваре вообще не понял, в этом как раз и профит что запрос обрабатывается последовательно всеми миддлварями и это последовательность никак не мешает асинхронности.
Это дает отличную возможность избавиться от callback hell и постоянной обработки ошибок на всех уровнях, как, например, реализовано в express.
Это не избавляет вас от необходимости обрабатывать ошибки асинхронных функций. Напишите trow Error в таймауте и Promise.all его не в поймает.
Почему то все забыли про Elite Dangerous, а ведь там вам и прокачка, и торговля, и пвп, и пве, и квесты и непостижимое за человеческую жизнь поле для исследования. Диалоги правда подкачали.
добавление к предыдущему моему комментарию:
Так же можно ввести договоренность в именовании методов, например:
Методы которые начинаются на "$" это приватные, а "$$" это защищенные.
И это во много раз проще в поддержке и отладке, чем копаться потом в стектрейсе который будет захламлен библиотечными функциями.
Так же это проще для стороннего человека, ему не нужно въезжать в детали реализации библиотеки, достаточно только узнать о принятой методологии именовании методов.
Я все же с Вами не соглашусь.
Мое мнение все же останется прежним, что правильней это помечать jsdoc`ом приватные/защищенные методы, чем реализовывать это через библиотеки.
Что касается сторонних библиотек, то это проблема библиотек что там комментариев к коду нет, значит библиотека «не очень» и лучше воздержаться от ее использования.
Что касается IDE то не надо думать о всех, нужно думать о себе. Настройте IDE что бы оно понимало jdoc, помечайте методы jsdoc'ом, а те кто пишут в блокноте должны либо читать ваш код и помнить головой где какой метод или использовать IDE.
я не стал бы говорить что Dart мертв, насколько мне видно, он все так же развивается и поддерживает. Другой вопрос что он не получил популярности и у него не очень понятное будущее. Но это куда лучше чем вот такая библиотека, потому что будущее этой библиотеки еще туманней чем у Darta.
Я так и не понял зачем вам настоящие приватные и защищенные методы в js? Для контроля кода в момент разработки достаточно писать jsdoc и тогда нормальная IDE сама сообщит что это за метод и как его следует использовать. Для иллюзии защищенности кода в момент выполнения, так это только иллюзия и лишнее переосложнение системы, еще не раз будет напоминать себе при отладке.
Может все потому что в огромном кол-ве мест требуется «скачать и подключить jq плагин» и на этом все? Много ли где в вебе требуется больших знаний, кроме самой платформы?
У нас в компании отлично работал PHP разработчик по специальности Юрист, который передумал быть юристом и самостоятельно изучил программирование. В результате доработался до релокации в Лондон. Поэтому Ваш категоричный нет, весь странен. Нужно как минимум поговорить с человеком.
Один раз пришел с офером на руках, типа так и так. Сделали контрпредложение, принял его, через пол года ушел как раз по тем причинам что в контрпредложении говорят одно, а выходит по другому.
Поэтому в какой то степени с изложенным в статье согласен, если причина ухода является проблема А которая не решалась длительное время но решилась когда приперло, то очень вероятно появление проблемы Б, которая так же не будет решаться.
У меня под последним хромом с тачпада не заработало.
И еще из замечаний, почему в конструктор передается id а не сразу нода? Я вот идишниками уже пару лет не пользуюсь
Вся статья сводится к тому как идет борьба с загрузкой ресурсов и как потом все то упаковать в .exe, нет ни слова о создании игры. Картинку с совой прилагать не будут.
1) гугулим «webpack 2 tree shaking», или подключаем только то что нужно например для lodash:
import array from 'lodash/array';
2) Читаем документацию: https://webpack.github.io/docs/usage-with-bower.html
Для дев конфига можно прописать алиас на не минифицированный файл.
3) Если библиотека правильная то все что для продакшина не нужно, срезается установкой переменой окружения `NODE_ENV=production`, собственно строка запуска будет такой: `NODE_ENV=production webpack ...`
4) В вебпак кофиге это ни как реализовывать не нужно, просто нужно подключить только ту локализацию которая нужна прямо в коде приложения
а если убрать бессмысленные придирки и посмотреть вот сюда: http://kangax.github.io/compat-table/es6/
то можно заметить что edge имеет поддержку es6 даже больше чем babel, а отсутствующие фичи не так уж и критичны.
Рискну предположить, что дело не в том что кто-то знает английский, а кто то не знает. Автор комментария сделал замечание о том что качество статьи никакое, по сути вы просто кинули ссылку на видео.
От себя добавлю, что прикрываться фразой: «Стыдно, считать, что имеешь отношение ИТ и не знать английский хотя бы на базовом уровне.», совсем некрасиво, потому что это шаблонный ответ на все вида: «Стыдно, считать, что имеешь отношение к <% чему-либо %> и не <% (знать/уметь) %> <% (что-либо)%> хотя бы на базовом уровне.». Это как последний аргумент: «Сначала добейся».
А вы как бы в курсе что оно будет все равно в одном потоке выполнятся и никакой параллельности не будет? Если вы конечно не рожаете пулл процессов для проверки роутов.
Фишку с непоследовательным выполнением миддлеваре вообще не понял, в этом как раз и профит что запрос обрабатывается последовательно всеми миддлварями и это последовательность никак не мешает асинхронности.
Это не избавляет вас от необходимости обрабатывать ошибки асинхронных функций. Напишите trow Error в таймауте и Promise.all его не в поймает.
Так же можно ввести договоренность в именовании методов, например:
Методы которые начинаются на "$" это приватные, а "$$" это защищенные.
И это во много раз проще в поддержке и отладке, чем копаться потом в стектрейсе который будет захламлен библиотечными функциями.
Так же это проще для стороннего человека, ему не нужно въезжать в детали реализации библиотеки, достаточно только узнать о принятой методологии именовании методов.
Мое мнение все же останется прежним, что правильней это помечать jsdoc`ом приватные/защищенные методы, чем реализовывать это через библиотеки.
Что касается сторонних библиотек, то это проблема библиотек что там комментариев к коду нет, значит библиотека «не очень» и лучше воздержаться от ее использования.
Что касается IDE то не надо думать о всех, нужно думать о себе. Настройте IDE что бы оно понимало jdoc, помечайте методы jsdoc'ом, а те кто пишут в блокноте должны либо читать ваш код и помнить головой где какой метод или использовать IDE.
Я так и не понял зачем вам настоящие приватные и защищенные методы в js? Для контроля кода в момент разработки достаточно писать jsdoc и тогда нормальная IDE сама сообщит что это за метод и как его следует использовать. Для иллюзии защищенности кода в момент выполнения, так это только иллюзия и лишнее переосложнение системы, еще не раз будет напоминать себе при отладке.
Мало вам классов в JS берите Dart там есть все и даже больше, без вот этих ваших костылей и прочего.
Поэтому в какой то степени с изложенным в статье согласен, если причина ухода является проблема А которая не решалась длительное время но решилась когда приперло, то очень вероятно появление проблемы Б, которая так же не будет решаться.
И еще из замечаний, почему в конструктор передается id а не сразу нода? Я вот идишниками уже пару лет не пользуюсь
2) Читаем документацию: https://webpack.github.io/docs/usage-with-bower.html
Для дев конфига можно прописать алиас на не минифицированный файл.
3) Если библиотека правильная то все что для продакшина не нужно, срезается установкой переменой окружения `NODE_ENV=production`, собственно строка запуска будет такой: `NODE_ENV=production webpack ...`
4) В вебпак кофиге это ни как реализовывать не нужно, просто нужно подключить только ту локализацию которая нужна прямо в коде приложения
то можно заметить что edge имеет поддержку es6 даже больше чем babel, а отсутствующие фичи не так уж и критичны.
От себя добавлю, что прикрываться фразой: «Стыдно, считать, что имеешь отношение ИТ и не знать английский хотя бы на базовом уровне.», совсем некрасиво, потому что это шаблонный ответ на все вида: «Стыдно, считать, что имеешь отношение к <% чему-либо %> и не <% (знать/уметь) %> <% (что-либо)%> хотя бы на базовом уровне.». Это как последний аргумент: «Сначала добейся».