Как стать автором
Обновить
26
0

Пользователь

Отправить сообщение

А она уже есть?

А почему вы решили описывать настройки в .babelrc, а не в конфиге вебпака?

Правильно ли я понимаю, что babel-polyfill просто ищет упоминания всяких Promise в коде и добавляет полифилы в бандл? То есть даже если браузер современный ему всё равно всё это придётся скачать? Или возможно создавать разные бандлы под современные и старые браузеры?

Я бы добавил ещё поисковую оптимизацию в плюсы. Гугл индексирует js долго и не всегда правильно, яндекс — не индексирует совсем.

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

Это вы скорее описываете преимущества серверного рендеринга, а не изоморфного. Ведь во втором случае это будет происходить только при загрузке первой страницы. Если js успешно подгрузится, конечно. А дальше всё те же запросы к API.

Да, действительно. Поправил, спасибо :)

Смотря для кого. Если у вас база уже стоит и реакт знаете — то да. А если пытаться проходить туториал без предварительных знаний — несколько часов уйдёт.

IndexedDB точнее. А какие ещё варианты? Так же как у серверных бд под капотом файловая система :)


js фреймворки настолько умные, что до такой степени тупые? :)

Там другой подход, не предполагается полностью перезаписывать модель постоянно.

Да, наверное, даже третья :)
Вот о том и речь, что с двусторонним связыванием у вас нету возможности это решать. У вас есть только переменная во вью-модел, которая может спонтанно измениться из нескольких источников.
Вы не поняли о чём речь или находите слово недостаточно корректным?
Если в плане обучения — то лучше всего loopback, он вас хорошим паттернам научит. Там уже есть вся структура api, правильная иерархия url и т.п. Вам этого нехватает.
При чём тут холивар? Разве я отстиваю какой-то другой пример? Я же вам привожу конкретные аргументы того, что функционал вашего примера — это подмножество функционала todo-листа.

В todo есть: получение коллекции, создание элемента, изменение элемента, удаление элемента. У вас только первые два пункта.
helloWorld — это же не todo-list. А последний это как раз и есть то, что вы описываете в статье — простенькое взаимодействие с сервером. Совершенно на любом фреймворке это будет выглядеть просто. Случай очень простой. Разница между фреймворками проявится при усложнении системы.

Вот тут умный человек очень хорошо рассказал зачем все эти рекаты и вторые ангуляры нужны, очень рекомендую, тут именно суть, а не свистелки: https://www.youtube.com/watch?v=DCeNCr2tKOI
она решается достаточно просто

Речь не о том, как её решить, а о том, что эта проблема заложена в самой архитектуре two-way, а в one-way её нету.
Разница в том, что one-time binding не предполагает последующего изменения отрендеренного хтмл, а one-way предполагает.
Для бэкенда, если js смотреть хороши koa.js — там нормальная асинхронность через async / await. И loopback — там обычные rest api описывается просто декларативно. В плане фронтенда интересен react native, раз вы и так по краю ходите, легко будет портировать проект на мобильники.
Костыль для скорости — это one-time binding в первом ангуляре, который {{:: foo }}. А one-way data flow — это архитектурное решение.

Насколько я понимаю абстрактная проблема с двусторонним связыванием та же, что и с глобальными переменными. Есть у вас какая-то переменная в VM которая связана с несколькими элементами UI и может меняться с сервера, допустим. И вот эти элементы и сервер одновременно её меняют, как это разрулить? А никак, т.к. логика связывания неявно зашита где-то в глубинах фреймворка.

Меня лично это проблема не беспокоит, т.к. ничего такого сложно-связанного нету. Но если бы было, я бы задумался об one-way-flow.
А посмотрите просто историю как фейсбук придумали реакт. Насколько я помню, у них там какой-то рассинхрон в юай был. Одностороннее связывание решило эту проблему.

Информация

В рейтинге
Не участвует
Откуда
Таиланд
Зарегистрирован
Активность