Правильно ли я понимаю, что babel-polyfill просто ищет упоминания всяких Promise в коде и добавляет полифилы в бандл? То есть даже если браузер современный ему всё равно всё это придётся скачать? Или возможно создавать разные бандлы под современные и старые браузеры?
Если сюда добавить необходимость делать клиентские API запросы после инициализации и вспомнить, что на мобильном интернете часто можно столкнуться с весьма ощутимыми задержками
Это вы скорее описываете преимущества серверного рендеринга, а не изоморфного. Ведь во втором случае это будет происходить только при загрузке первой страницы. Если js успешно подгрузится, конечно. А дальше всё те же запросы к API.
Смотря для кого. Если у вас база уже стоит и реакт знаете — то да. А если пытаться проходить туториал без предварительных знаний — несколько часов уйдёт.
Вот о том и речь, что с двусторонним связыванием у вас нету возможности это решать. У вас есть только переменная во вью-модел, которая может спонтанно измениться из нескольких источников.
Если в плане обучения — то лучше всего loopback, он вас хорошим паттернам научит. Там уже есть вся структура api, правильная иерархия url и т.п. Вам этого нехватает.
При чём тут холивар? Разве я отстиваю какой-то другой пример? Я же вам привожу конкретные аргументы того, что функционал вашего примера — это подмножество функционала todo-листа.
В todo есть: получение коллекции, создание элемента, изменение элемента, удаление элемента. У вас только первые два пункта.
helloWorld — это же не todo-list. А последний это как раз и есть то, что вы описываете в статье — простенькое взаимодействие с сервером. Совершенно на любом фреймворке это будет выглядеть просто. Случай очень простой. Разница между фреймворками проявится при усложнении системы.
Вот тут умный человек очень хорошо рассказал зачем все эти рекаты и вторые ангуляры нужны, очень рекомендую, тут именно суть, а не свистелки: https://www.youtube.com/watch?v=DCeNCr2tKOI
Для бэкенда, если js смотреть хороши koa.js — там нормальная асинхронность через async / await. И loopback — там обычные rest api описывается просто декларативно. В плане фронтенда интересен react native, раз вы и так по краю ходите, легко будет портировать проект на мобильники.
Костыль для скорости — это one-time binding в первом ангуляре, который {{:: foo }}. А one-way data flow — это архитектурное решение.
Насколько я понимаю абстрактная проблема с двусторонним связыванием та же, что и с глобальными переменными. Есть у вас какая-то переменная в VM которая связана с несколькими элементами UI и может меняться с сервера, допустим. И вот эти элементы и сервер одновременно её меняют, как это разрулить? А никак, т.к. логика связывания неявно зашита где-то в глубинах фреймворка.
Меня лично это проблема не беспокоит, т.к. ничего такого сложно-связанного нету. Но если бы было, я бы задумался об one-way-flow.
А посмотрите просто историю как фейсбук придумали реакт. Насколько я помню, у них там какой-то рассинхрон в юай был. Одностороннее связывание решило эту проблему.
А она уже есть?
А почему вы решили описывать настройки в
.babelrc, а не в конфиге вебпака?Правильно ли я понимаю, что
babel-polyfillпросто ищет упоминания всякихPromiseв коде и добавляет полифилы в бандл? То есть даже если браузер современный ему всё равно всё это придётся скачать? Или возможно создавать разные бандлы под современные и старые браузеры?Я бы добавил ещё поисковую оптимизацию в плюсы. Гугл индексирует js долго и не всегда правильно, яндекс — не индексирует совсем.
Это вы скорее описываете преимущества серверного рендеринга, а не изоморфного. Ведь во втором случае это будет происходить только при загрузке первой страницы. Если js успешно подгрузится, конечно. А дальше всё те же запросы к API.
Точно :)
Да, действительно. Поправил, спасибо :)
Смотря для кого. Если у вас база уже стоит и реакт знаете — то да. А если пытаться проходить туториал без предварительных знаний — несколько часов уйдёт.
IndexedDB точнее. А какие ещё варианты? Так же как у серверных бд под капотом файловая система :)
Там другой подход, не предполагается полностью перезаписывать модель постоянно.
В todo есть: получение коллекции, создание элемента, изменение элемента, удаление элемента. У вас только первые два пункта.
Вот тут умный человек очень хорошо рассказал зачем все эти рекаты и вторые ангуляры нужны, очень рекомендую, тут именно суть, а не свистелки: https://www.youtube.com/watch?v=DCeNCr2tKOI
Речь не о том, как её решить, а о том, что эта проблема заложена в самой архитектуре two-way, а в one-way её нету.
{{:: foo }}. А one-way data flow — это архитектурное решение.Насколько я понимаю абстрактная проблема с двусторонним связыванием та же, что и с глобальными переменными. Есть у вас какая-то переменная в VM которая связана с несколькими элементами UI и может меняться с сервера, допустим. И вот эти элементы и сервер одновременно её меняют, как это разрулить? А никак, т.к. логика связывания неявно зашита где-то в глубинах фреймворка.
Меня лично это проблема не беспокоит, т.к. ничего такого сложно-связанного нету. Но если бы было, я бы задумался об one-way-flow.