Реализовать раздел Регистрации и Онбординга

Экран "Вход"

На этом экране пользователь должен иметь возможность зарегистрироваться с помощью соцсетей (Omniauth авторизация). Нужно

взаимодействие с Omniauth provider-ами Gmail и Facebook. Callback после

создания аккаунта на стороне провайдера должен вести пользователя на

Экран "Показатели тела".

Если пользователь решил не использовать Omniauth, он может кликнуть на кнопку «Далее» и перейти на Экран "Создание аккаунта".

Экран "Создание аккаунта"

На этом экране должна содержаться форма создания аккаунта. Данные нужно слать на ендпоинт: POST /users. При неуспешном ответе от

сервера, форма должна рендерить ошибки, не сбрасывая содержимое полей.

При успешном ответе от сервера, пользователь попадает на Экран

"Показатели тела".

Экран "Показатели тела"

Простая форма для персонализации аккаунта. По мере изменения пользователем введенных данных, изменяется значение поля

«Дневная норма ккал». При этом пользователь может изменить это поле

напрямую, изменяя положение слайдера. Если значение ниже или ваше

предельных рекомендуемых, то система должна выдавать соответствующее

предупреждение (соседние экраны «Недобор» и «Перебор»).

Данные формы нужно слать на ендпоинт: PUT /current_user. Если пользователь перешел на эту страницу после экрана регистрации, то

он после успешного ответа от сервера, фронт должен отправить запрос и на

ендпоинт: POST /user_menus/generate с параметрами start_date: {текущая дата}, end_date: {текущая дата + 7 дней}, rewrite:

true. 7 дней стоит зашить в какую-нибудь переменную окружения или

настройку с дефолтным значением 7.

После отправки уже первой формы, пользователь видит Экран "Preloader", на котором отображается прогресс выполнения обоих запросов.

В дальнейшем этот экран может понадобиться и при других запросах.

Если пользователь перешел на эту страницу после экрана регистрации, то после завершения запроса и получения успешного ответа,

он переходит на Экран «Объяснения». После которого - на Экран «Предпочтения».

Если пользователь перешел на эту страницу из настроек, а не при первичной регистрации, то после получения успешного ответа при

отправке формы он попадает на ту страницу, с которой сюда пришел.

Экран "Preloader"

Просто экран на котором отображается прогресс выполнения обоих запросов. В дальнейшем этот экран может понадобиться и при других

запросах.

Экран «Предпочтения»

Экран для редактирования предпочтений пользователя. Они будут влиять на поисковую выдачу и на автоматическую генерацию меню

пользователя. Данные формы должны отправляться на ендпоинт: POST /preferences. Причем, данные для отправки запроса будут собираться на 3 экранах - «Предпочтения 1/2», «Предпочтения 2/2» и «Распорядок дня».

Экран «Предпочтения 1/2»

Данные для поля «Валюта страны» пока должны предлагать на выбор RUB и USD. Но если вам удастся сразу заложить логику для того,

чтобы безболезненно добавлять новые валюты, это будет здорово. Чтобы у

нас 2 валюты, 3, 4 и 5 разных валют смотрелись одинаково прекрасно и

соответственно макету. Если это сложно - не тратьте время, пока делаем

MVP.

Данные поля «Время приготовления», несмотря на название, должны содержать только большее число. Кнопка «До 15 мин» пусть имеет

значение 15, «15-30 мин» - значение 30, «30-60 мин» - 60, «Более 60

минут» - 10_000.

Чтобы получить данные для опций «Способ приготовления», нужно отправить запрос на ендпоинт: Ендпоинта для этого экрана пока нет,

напишите, какие данные вам для него нужны, сделаем.

После выбора всех необходимых опций и ввода данных, пользователь при нажатии кнопки «Далее» переходит на Экран «Предпочтения

2/2».

Экран «Предпочтения 2/2»

Чтобы получить данные для поля с нежелательными ингредиентами, нужно отправить запрос на ендпоинт: Ендпоинта для этого

экрана пока нет, напишите, какие данные вам для него нужны, сделаем.

После выбора всех необходимых опция и ввода данных, пользователь при нажатии кнопки «Далее» переходит на Экран «Предпочтения

2/2».

Экран «Распорядок дня»

Чтобы получить данные для поля с распорядком дня, нужно отправить запрос на ендпоинт: Ендпоинта для этого экрана пока нет,

напишите, какие данные вам для него нужны, сделаем.

Распорядок дня - это сведения о том, сколько приемов пищи, в какое время и с какими типами блюд у пользователя на текущий момент.

Это будет влиять на автоматическое формирование плана питания для

пользователя. Ответ из ендпоинта выше будет содержать некий дефолтный

распорядок дня с каким то предустановленным количеством блюд в нем (в

дальнейшем, возможно, это будет зависеть от дневной нормы калорий,

полученной на предыдущих шагах создания аккаунта).

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

соседнем Экране «Распорядок дня/Редактировать», поля с названием приема

пищи и временем станут активными, иконка карандаша превратится в урну,

при нажатии на которую прием пищи удаляется из распорядка дня. В режиме

редактирования пользователь также может добавлять и удалять блюда из

приема пищи.

Если пользователь хочет добавить к своему распорядку дня еще один прием пищи, он может кликнуть На кнопку «Добавить прием пищи»,

после чего на экране отобразится еще один прием пищи уже в режиме

редактирования. Причем, время должно быть уникальным (просто прибавьте 1

час к предыдущему приему пищи, например). Если пользователь специально

вводит время, которое уже занято, мы должны его изменить автоматически, и

вывести ему уведомление, что в это время у него уже есть прием пищи.

По сути, весь этот экран - это поле food_intakes_schedule в форме предпочтений. Значение поля food_intakes_schedule должно иметь

примерно такой формат:

food_intakes_schedule:

{"1000"=>["drink", "main", "soup"], "1700"=>["soup", "drink", "salad"], "2100"=>["main",

"drink", "salad"], "2200"=>["salad", "soup", "drink"]}

Ключи в хэше - это время в формате «ччмм».

При нажатии на кнопку «Далее» данные со всех трех экранов отправляются одним запросом на ендпоинт: POST /preferences.