Спасибо за статью, отличное сравнение. Недавно сам перешел с Rails на Phoenix. Из классного, что вы не упомянули это Context. По дефолту в рельсе бизнес логика размазана по контроллерам и моделям(даже в скаффолде). Потом люди начинают думать головой и выносить все это в сервисы. В эликсире же с версии 1.3 ввели Context которые по факту просто модули с функциями внутри. Это позволяет сразу всю бизнес логику заворачивать в Context и в контроллере просто его вызывать. И самое приятно, что при генерации скаффолдов сразу генерируется правильная структура, а не бизнес логика в контроллере.
Вы бы не могли подробнее описать плюсы подхода со стримами. Я вижу его в ng6 а теперь в Реакте но не понимаю его бенефитов. Задачу с поиском обычно решаю так.
1. Описываем state const state = {availableOptions: []}
2. тупой компонент который внутри имеет debounce и отдает term наружу в onChange event.
3. fetchData просто async экшен который заполняет стейт
Это дает разделение логики фетча от компоненты и состояния. По факту у нас тупая компонента, фетч можно делать при помощи чего угодно (thunk, saga).
Насколько я увидел по исходникам проекта, то вы делаете все в rails way — все рендерится на бекенде внутри феникса, а потом данные пробрасываются на клиент и работает реакт.
Насколько я вижу, на сегодняшний день люди предпочитают строить реакт с SSR который рендерится нодой, а данные выгребать с API из rails/phoenix/etc. (имхо так проще разбить API и клиент в 2 отдельных проекта)
Почему вы делаете именно так? Проще в поддержке?
Последние 5 лет использую вместе с женой сервис «Дребеденьги». Не знаю, как зарабатывает на нем автор, но его цена 500 рублей в год.
Обычно оба заносим все траты с телефонов, оно синхронизирует все. Раз в неделю заношу траты из банка, который делались онлайн и жена перепроверяет сходится ли остаток наличных. Если заносить реже, то обычно есть недостачи и непонятно куда делись.
Из того, что мне нравится в этом сервисе:
1. Цена))
2. Удобное планирование бюджета на каждый месяц. Там можно добавлять категории, чтобы видеть когда превысил расходы по категории
3. Графики доходов, расходов за год.
4. Каждую неделю на почту высылают бекап с всеми данными. Я один раз накосячил, удалив категорию и помогло все восстановить.
Исходя из моего опыта правил JSONAPI недостаточно обычно и постоянно возникают вопросы «А как реализовать то или то»и никакая библиотека не покрывает нужны целиком. Например, фильтрация и сортировка в JSONAPI не описана. Пишите как хотите. И все библиотеки реализовывают их по разному. В redux я использовал redux-json-api, но его пришлось выкинуть так как количество нереализованных, но нужных фич очень большой. Простите, но сейчас 2017 год и не JSONAPI, который был еще 6 лет назад набирает популярность, а нормальные решения для API. Попробуйте например Graphql. Вы просто не захотите больше никогда видеть JSONAPI после него.
Вкратце плюсы Grapql например: валидация из коробки, чистый код, легкое взаимодействие с redux, нормальное описание сущностей, вебморда чтоб тестить все запросы.
Там в одном из комментариев также писали, что используют Swagger. Тот же самый ответ. Зачем использовать Swagger в 2017? Используйте решения у которых все запросы отображаются по умолчанию в вебморде как только вы их создаете, а не их необходимо описывать. Неужели вам недостаточно что вы пишите код и вы еще хотите описывать каким то DSL какие данные кормить запросам?
Я бы переписал на реакт с редуксом так как на проекте важна индексация, а реакт позволяет легко рендерить все на бекенде. Да и опыт написания проекта на редуксе уже есть
У нас на проект сейчас бекбон с марионетом. Проекту 3 года. Пока переписать на что-то более новое не дают. Я поставил вебпак с бабелем и import отлично можно использовать. Для того, чтобы избежать рефакторинга всех вьюх с записью в конструкторе мы просто используем module.exports = Marionette.ItemView.extend({}). Классы это единственное, что мы не используем из ес6 и полет нормальный.
Для тех, кому проще и понятнее смотреть видео чем читать текст, я снимаю тур героев на русском. На данный момент снял 4 урока. Сегодня досниму пятый. Вот ссылка на первый урок.
https://monsterlessons.com/project/series/funkcionalnyj-javascript-i-ramda
1. Описываем state
const state = {availableOptions: []}2. тупой компонент который внутри имеет debounce и отдает term наружу в onChange event.
3. fetchData просто async экшен который заполняет стейт
Это дает разделение логики фетча от компоненты и состояния. По факту у нас тупая компонента, фетч можно делать при помощи чего угодно (thunk, saga).
Насколько я вижу, на сегодняшний день люди предпочитают строить реакт с SSR который рендерится нодой, а данные выгребать с API из rails/phoenix/etc. (имхо так проще разбить API и клиент в 2 отдельных проекта)
Почему вы делаете именно так? Проще в поддержке?
Обычно оба заносим все траты с телефонов, оно синхронизирует все. Раз в неделю заношу траты из банка, который делались онлайн и жена перепроверяет сходится ли остаток наличных. Если заносить реже, то обычно есть недостачи и непонятно куда делись.
Из того, что мне нравится в этом сервисе:
1. Цена))
2. Удобное планирование бюджета на каждый месяц. Там можно добавлять категории, чтобы видеть когда превысил расходы по категории
3. Графики доходов, расходов за год.
4. Каждую неделю на почту высылают бекап с всеми данными. Я один раз накосячил, удалив категорию и помогло все восстановить.
Вкратце плюсы Grapql например: валидация из коробки, чистый код, легкое взаимодействие с redux, нормальное описание сущностей, вебморда чтоб тестить все запросы.
Там в одном из комментариев также писали, что используют Swagger. Тот же самый ответ. Зачем использовать Swagger в 2017? Используйте решения у которых все запросы отображаются по умолчанию в вебморде как только вы их создаете, а не их необходимо описывать. Неужели вам недостаточно что вы пишите код и вы еще хотите описывать каким то DSL какие данные кормить запросам?