А к чему jQuery тогда? Есть нативный DOM, так же еще быстрее, а код организовать вы уже умеете. Наверно у вас уже есть самописные хранилища state приложения, самописные роутеры, обертки над сокетами, обертку над ajax тоже можно самому написать. Выносить обновление dom под капот тоже не стоит (как в реакт, например), можно же просто подписаться на что-нибудь и в ручную апдейтить dom (не забыть отписаться потом, и не забыть проверить вообще в dom ли у нас нужные элементы).
Это была ирония, если что.
Фронт-энд быстро эволюционирует, новые фреймворки это не новые технологии, это новые виды (возможно только в мире фронта) абстракций, лучшие выживают (react, angular), остальные умирают (где там backbone и knockout сейчас).
Ну я не знаю как у вас устроено, у меня в терминале (Открытие) нельзя выставить само «плечо», можно купить инструмент на определенную сумму, даже которая превышает депозит. Как же у вас выглядит выставление заявки? Например у вас 500к рублей депо, вы выставляете заявку на покупку одного лота USD с плечом 100, в итоге у вас получается депо ~435к и заемные средства ~585к?
У нас большой проект на реакте и мы юзаем DI (очень похожую на DI angular2), это дает возможность удобно использовать модульность. Например можно объявить интерфейс модуля и уже в рантайме биндить к интерфейсу модуля конкретную реализацию. при этом сами модули ничего не знают друг о друге, только об интерфейсах.
Конечно можно это все реализовать и через сервис-локатор например или просто на коленке, но поддерживать и расширять код с DI имхо намного проще.
С сервис-локатором например 2 варианта использования, либо делать его глобальным, либо прокидывать его через все сущности. При DI инжектор управляет тем, что будет использовать клиентский код, а не клиентский код следит за местоположением сервис-локатора и своими зависимостями (IoC принцип, странно что про него упоминания я не заметил в статье).
А какая в реакте может быть работа с зависимостями? из коробки никакой.
И вообще, ангулар это фреймворк, а реакт ui-библиотека. Они выполняют разные функции и сравнимы только частично, в области отрисовки ui.
Интересует каким образом будет строиться доказательная база при, например, покупке услуги/товара за биткоины. Формально все что может связывать транзакцию и конкретного человека это приватный ключ, который никто не может знать и он может быть нигде не записан.
А к чему jQuery тогда? Есть нативный DOM, так же еще быстрее, а код организовать вы уже умеете. Наверно у вас уже есть самописные хранилища state приложения, самописные роутеры, обертки над сокетами, обертку над ajax тоже можно самому написать. Выносить обновление dom под капот тоже не стоит (как в реакт, например), можно же просто подписаться на что-нибудь и в ручную апдейтить dom (не забыть отписаться потом, и не забыть проверить вообще в dom ли у нас нужные элементы).
Это была ирония, если что.
Фронт-энд быстро эволюционирует, новые фреймворки это не новые технологии, это новые виды (возможно только в мире фронта) абстракций, лучшие выживают (react, angular), остальные умирают (где там backbone и knockout сейчас).
await и генерит промисы, как видно из названия он их ждет
Ну так вроде ничто не мешает каждый await обернуть в try-catch, за одно удобнее различные исключения бросать
Очевидно, что то что и написал, код выше эквивалентен этому
как вариант без Promise.all
Конечно можно это все реализовать и через сервис-локатор например или просто на коленке, но поддерживать и расширять код с DI имхо намного проще.
С сервис-локатором например 2 варианта использования, либо делать его глобальным, либо прокидывать его через все сущности. При DI инжектор управляет тем, что будет использовать клиентский код, а не клиентский код следит за местоположением сервис-локатора и своими зависимостями (IoC принцип, странно что про него упоминания я не заметил в статье).
И вообще, ангулар это фреймворк, а реакт ui-библиотека. Они выполняют разные функции и сравнимы только частично, в области отрисовки ui.
внутри использовать span