feat(Calendar): add new public component Calendar

[Lelchik]

fixes IF-466

Ребята из двух различных команд используют Picker из DatePicker как самостоятельный компонент, в связи с чем было принято решение вынести Picker в отдельный компонент и назвать его Calendar

Чек-лист из задачи:

• [x] Вынести Picker в отдельный компонент и переименовать его в Calendar
• [x] Написать документацию с примерами
• [x] Покрыть Calendar интеграционными (react-testing-library) и скриншотными тестами
• [x] Удалить из DatePickerа ненужные тесты/истории, если такие будут (имеются ввиду тесты, которые теперь можно будет произвести исключительно в Calendar не затрагивая DatePicker)
• [x] (необязательно) Переписать интеграционные тесты в DatePicker на react-testing-library
• [ ] (необязательно) При необходимости деструктурировать компонент Calendar

[Lelchik]

Вынесла компонент календаря в публичные. Не стала Picker делать полностью публичным, так как там есть небольшая верстка (тень), которая не нужна (?) в календаре. Вопросы:

• кажется лишним пропс onSelect. Он вызывается только при клике на кнопку "сегодня". Скорее всего его можно заменить на onPick.
• локализация осталась такая же как и у Datepicker. Стоит ли для календаря копировать ее?

[JackUait]

Вова (@dzekh), сейчас компоненты Calendar vs DatePicker выглядят так:

Calendar	DatePicker

У DatePicker есть тень, а у Calendar тени нет. Мне кажется правильным, что у Calendar как у не-выпадашки нет тени (если я хоть что-то понимаю в дизайне), но в связи с этим возникает проблема: эту тень нужно на что-то заменить. Есть ли возможность отрисовать в дизайне или хотя бы отписать текстом на что мы меняем тень и меняем ли её вообще?

[dzekh]

проблема: эту тень нужно на что-то заменить

На мой вкус тут проблема только с кнопкой «Сегодня» и тем, что отделяющая линия выглядит странно и шире всех остальных линий, а текст выровнен по центру. Всё остальное оформление и обрамление кажется можно оставить на откуп продуктов. Можно было бы заменить тень на однопиксельную обводку, но чаще всего она будет лишней, потому что там скорее всего будут свои контейнеры обрамляющие календарь и контролы рядом.

Я бы предложил линию кнопки «Сегодня» убрать в этой версии (тем более она по умолчанию выключена и включается отдельным пропом), но хорошо бы добавить такую-же линию чтоб она обозначала границу календаря снизу. Она обрезала бы цифры дат. После этого календарь уже будет выглядеть норм, для того чтобы встраивать его куда угодно.

Хорошо еще тут подумать про пару вещей:

1. фон — идеально, чтоб он был прозрачный,
2. было бы круто если бы этот календарь можно было бы растягивать и сжимать по высоте. Пропом или просто внешним контейнером. Чтобы можно было спрятать торчащий снизу месяц или наоборот дать больше вариантов.

[JackUait]

кажется лишним пропс onSelect. Он вызывается только при клике на кнопку "сегодня". Скорее всего его можно заменить на onPick.

локализация осталась такая же как и у Datepicker. Стоит ли для календаря копировать ее?

Это вопросы к Егору (@zhzz), я на это ответить не смогу)

[zhzz]

В задаче говорилось про вынос конкретно Picker, но я сомневаюсь что именно его стоит делать публичным, т.к. на самом деле у него немного специфичная задача и апи. Picker нужен конкретно для выпадашки DatePicker'a, с кнопкой "Сегодня" и обработчиком клика по ней. Но задача стоит более широкая - дать переиспользовать сам Calendar в любых, необязательно связанных с выпадашками, целях. Это может быть просто "инлайн-календарь". Или все-таки выпадашка, но без кнопки "Сегодня" (или с кнопкой, но другой). В таких случаях апи Picker'a будет излишним.

Хотелось бы поподробнее изучить пользовательские сценарии, чтобы точно представлять их потребности. Но в обсуждении в чате никто ими не поделился. Поиском я сам нашел только по одному использованию Picker и Calendar.

Я думаю, более целесообразным будет опубликовать Calendar и ничего лишнего. А Picker, как он сейчас есть, пусть останется лежать в DatePicker и будет так же доступен.

Однако, над апи публичного Calendar тоже еще стоит подумать и подогнать его под остальные публичные контролы, для консистентности. Например, тип value поменять на string, как у DatePicker и DateInput. Вместо onSelect сделать onValueChange.

Вопрос с локалью интересный. Правильнее было бы сделать ему свою локаль и переопределять ее внутри DatePicker, как мы делаем с темой Button внутри Select.

Учитывая, что Calendar и Picker все-таки используют, мы можем сделать сперва полностью неломающие правки, добавив публичную обертку над Calendar с новым апи. А все старые компоненты оставить пока там, где они есть. В мажорном релизе отрефакторим.