Как создатель Rulet.TV - могу как нибудь рассказать как такое сделать в соло. Приходите, буду рад вас видеть на Рулет ТВ!
К сожалению, версия которую вы описали в реальной жизни не будет работоспособна, и есть десяток причин. Как разберусь с миграцией на ScyllaDB, озязательно сделаю лекции по многим темам.
Изначально идея создания еще одной рулетки - провальная, именно поэтому нужно решить так же ряд концептуальный вопросов, а самый главный - курс развития. Вот поэтой причине, я изначально занимался тем чтобы помочь нашим блогерам победить запрет на свободу слова в ометв. Но после ряда предупреждений и попыток свзаться с ними, пришлось сделать аольтернативу, которая как раз и должна решить основную проблему - Видео Рулетка, как и любая другая социальная сеть, Должна Приносить Радость и Развлекать.
Пока это все что я могу сказать, но как выше упомянул, я буду давать лекции и писать статьи как разгружусь по разработке.
Так и можно было ответить с вашей стороны. А не грубо в той форме который вы написали. Я не думаю что много кто либо напишет прототип так быстро с представленным качеством, от чего было и неприятно вдвойне, когда мы заранее все обговорили.
Связи с общественностью (СО или PR) — это искусство и наука достижения гармонии посредством взаимопонимания, основанного на правде и полной информированности.
1. «Посмотрите на mock-up и посмотрите сколько у вас компонентов, тулзов итд.»
И что тут не так? Зато все читаемо на ура
2. «Кстати, вы могли сэкономить время на CSS или верстке. Смысла вылизывать все — не имеет никакого смысла.»
Вот именно!
3. «Вот именно! Все можно сделать без этих зависимостей»
Тогда появятся новые файлы с новыми функциями, которые придется покрыть тестами.
Вы явно противоречите самому себе. Извините, но вы явно видите мир не так, как и я, и это нормально. И диктовать всем, что ты работаешь не так, ты не сениор и тд, когда никто даже не может нормально ответить кто такой сениор, как то не корректно. Может это вы смените род деятельности, чтобы понять что вы не правы?
«Жаль, что вы не видите ошибок»
Проблема что вы тоже тут не видите ошибок, а сами заявляете что они есть.
«В команду ищут не только по знаниям, но по общим взглядам, подходам к разработке, симпатии, умении общаться. Тогда такому влиться в команду будет очень легко.» — работать с таким ревьювером я не пожелаю никому. Но вы переводите косяк на меня, спасибо.
Основная проблема такого подхода в том что мы не можем отправить запрос на получение всех данных параллельно, мы должны последовательно отправлять запрос за запросом и тратим время на отправку и прием, что выливается в довольно таки большую задержку.
Я бы предпочел получать последние 5 билетов по определенным фильтрам. Да, переключение фильтров будет дольше, но зато я буду уверен что информация актуальна и мне не придется обновлять всю страницу вручную.
Да и в конце концов можно открыть три страницы с разными фильтрами и на каждой подписаться на новые билеты, удовлетворяющие условиям фильтра.
1. «А вот лишнего когда очень много»
Прошу показать где.
2. «Использование кучи сторонних либ, хотя можно обойтись и без них»
Какие сторонние? Их всего 3 (mobx, rxjs, react-ioc).
3. «Использование стартер китов вместо ручной конфигурации»
Я сгенерировал проект через next init. Этого не достаточно?
4. «Использование Typescript»
Я написал почему я не использовал Typescript — прошу перечитать. Но даже если переименовать файлы в ts и tsx, и добавить типов то это ничего ровным счетом не изменит.
5. «Тесты должны быть. Никаких потом, зачем и нет времени. Нет тестов — нет задания.»
В задании нет, мне сообщили что не надо. Надо тесты — пусть оплачивают время на разработку.
6. «Описание проекта. Описание как запустить проект — это не описание. В описании должны быть — основные цели, структура проекта, компоненты, сервисы итд.»
Это не дипломная и не работа на заказчика, не придумывайте. Это просто бесплатное тестовое задание. Писание документации это абсолютное иного рода деятельность, которая так же должна быть оговорена и оплачена.
7. «Поэтому стоит успокоится и провести анализ ошибок»
Какие ошибки из этого можно подчеркнуть? Можете привести «реальный пример»? Я ничего кроме чсв ревьювера не вижу. Задание сделано идеально за оговоренный промежуток времени, при этом работает быстрее и лучше приложения от самих Aviasales за счет использования Web Worker, после чего мне заявляют что нет смысла их использовать и в отзыве мне дают рейт Juniora и заявляют что я не знаю React. А само ревью написано абсолютно субъективным стилем. Обидно как то…
Задание сделано за день, как и было оговорено с HR. Я не собирался делать ничего, что заняло бы больше времени. Прошу это учесть.
Про getInitialProps попробуйте стянуть мой проект и удалить эту функцию то поймёте о чем я.
Использование document и app глючили и не собирались в момент инициализации после добавления react-ioc. Но под конец разработки я не проверял.
Со стилями предпочитаю работать из под коробки. Добавление ещё одного типа добавит жалоб что слишком сложный проект.
Если они хотят, то в функционале реакт не было бы бы context.
Если ложить обычные svg в папку static то они будут при загрузке пропадать до момента полной загрузки. Увы, это не панацея.
Мокать это хорошо, но мокать таким образом как вы показали так же не нравится многим клиентам и разработчикам, те тоже спорное решение. Лучше через dependency injection.
Я полностью за контроль состояния приложения через сервисы. Redux уж слишком заставляет много писать кода. Не говоря уже о других проблемах при написании бизнес логики между моделями, об этом как нибудь я напишу статью.
Я не использую PropTypes тут только потому что планировал переименовать все эти файлы в tsx и добавить типов. Но по времени не уложился.
Кто где сколько работал не является показателем знаний и реальных способностей. Извиняюсь, если грубо, но я бы с вами пообщался по Скайпу. Может что нить сделаем вместе, если у вас есть свободное время?
И заходя наперёд, да я понимаю что работать по TDD может быть выгодно, но начитавшись книжек для бэка и десктопных приложений и тд, это слабо применимо к фронтенду, когда нужно что то сверстать и выкинуть, так как настройка среды для тестирования фронт проектов обычно занимает достаточно много времени. Если не согласны, взгляните сколько способов и сколько сред для тестирования всего лишь ангуляр приложений. Я практикую это для основных проектов, но опять же, тестовые проекты должны хотяб оплачиваться так же. И чаще всего тесты начинаются уже после утверждённого десятого, а то и двадцатого прототипа.
Вы нашли пример костыля, если вы работали с NextJS, то если не предоставить фреймворку функцию getInitialProps, то ssr вообще не распарсит query. Приходится всегда вставлять такую ерунду. Можете найти тикет в репозитории фрейма, там их много.
Второе замечание по сути ничего не даёт, опять же все упирается в баг ssr. К сожалению фрейм не без недостатков.
Typescript так же работает из под коробки только с чистым проектом, а как добавляешь изображения, стили, и тд и тд (я имею ввиду плагины), то проект не компилируется. Лучше ради тестового проекта сидеть на JS.
Не забывайте, что я сделал этот проект за день, учитывая, что я делал основную работу и вечером сидел с ребёнком. Мне, как и большинству таких как я очень дорого время, а написал статью я скорее для таких же как я, чтобы мы такие компании с завышенными чсв сотрудниками обходили стороной.
А попадись такой «ревьювер» начинающему программисту, руки отобьёт и заставит его уйти в другую область. Слава богу, что мне когда то попались отличные ребята.
Не путайте, есть компоненты shared, а есть внутренние. Те компоненты, что shared не будут иметь внешних зависимостей. А если вы хотите использовать фильтры, то используйте его shared версию, если ее нет, значит он не подрузамевался быть общим.
Передавать как property тут не подходит. Появляется колбаса из пропертей, для этого и есть react-ioc. Но пропертя не решит проблему сменившегося контекста вызова на компонент, вместо сервиса. Так как сделать иначе?
Как создатель Rulet.TV - могу как нибудь рассказать как такое сделать в соло. Приходите, буду рад вас видеть на Рулет ТВ!
К сожалению, версия которую вы описали в реальной жизни не будет работоспособна, и есть десяток причин. Как разберусь с миграцией на ScyllaDB, озязательно сделаю лекции по многим темам.
Изначально идея создания еще одной рулетки - провальная, именно поэтому нужно решить так же ряд концептуальный вопросов, а самый главный - курс развития. Вот поэтой причине, я изначально занимался тем чтобы помочь нашим блогерам победить запрет на свободу слова в ометв. Но после ряда предупреждений и попыток свзаться с ними, пришлось сделать аольтернативу, которая как раз и должна решить основную проблему - Видео Рулетка, как и любая другая социальная сеть, Должна Приносить Радость и Развлекать.
Пока это все что я могу сказать, но как выше упомянул, я буду давать лекции и писать статьи как разгружусь по разработке.
И что тут не так? Зато все читаемо на ура
2. «Кстати, вы могли сэкономить время на CSS или верстке. Смысла вылизывать все — не имеет никакого смысла.»
Вот именно!
3. «Вот именно! Все можно сделать без этих зависимостей»
Тогда появятся новые файлы с новыми функциями, которые придется покрыть тестами.
Вы явно противоречите самому себе. Извините, но вы явно видите мир не так, как и я, и это нормально. И диктовать всем, что ты работаешь не так, ты не сениор и тд, когда никто даже не может нормально ответить кто такой сениор, как то не корректно. Может это вы смените род деятельности, чтобы понять что вы не правы?
«Жаль, что вы не видите ошибок»
Проблема что вы тоже тут не видите ошибок, а сами заявляете что они есть.
«В команду ищут не только по знаниям, но по общим взглядам, подходам к разработке, симпатии, умении общаться. Тогда такому влиться в команду будет очень легко.» — работать с таким ревьювером я не пожелаю никому. Но вы переводите косяк на меня, спасибо.
Я бы предпочел получать последние 5 билетов по определенным фильтрам. Да, переключение фильтров будет дольше, но зато я буду уверен что информация актуальна и мне не придется обновлять всю страницу вручную.
Да и в конце концов можно открыть три страницы с разными фильтрами и на каждой подписаться на новые билеты, удовлетворяющие условиям фильтра.
Прошу показать где.
2. «Использование кучи сторонних либ, хотя можно обойтись и без них»
Какие сторонние? Их всего 3 (mobx, rxjs, react-ioc).
3. «Использование стартер китов вместо ручной конфигурации»
Я сгенерировал проект через next init. Этого не достаточно?
4. «Использование Typescript»
Я написал почему я не использовал Typescript — прошу перечитать. Но даже если переименовать файлы в ts и tsx, и добавить типов то это ничего ровным счетом не изменит.
5. «Тесты должны быть. Никаких потом, зачем и нет времени. Нет тестов — нет задания.»
В задании нет, мне сообщили что не надо. Надо тесты — пусть оплачивают время на разработку.
6. «Описание проекта. Описание как запустить проект — это не описание. В описании должны быть — основные цели, структура проекта, компоненты, сервисы итд.»
Это не дипломная и не работа на заказчика, не придумывайте. Это просто бесплатное тестовое задание. Писание документации это абсолютное иного рода деятельность, которая так же должна быть оговорена и оплачена.
7. «Поэтому стоит успокоится и провести анализ ошибок»
Какие ошибки из этого можно подчеркнуть? Можете привести «реальный пример»? Я ничего кроме чсв ревьювера не вижу. Задание сделано идеально за оговоренный промежуток времени, при этом работает быстрее и лучше приложения от самих Aviasales за счет использования Web Worker, после чего мне заявляют что нет смысла их использовать и в отзыве мне дают рейт Juniora и заявляют что я не знаю React. А само ревью написано абсолютно субъективным стилем. Обидно как то…
Задание сделано за день, как и было оговорено с HR. Я не собирался делать ничего, что заняло бы больше времени. Прошу это учесть.
Абсолютно с вами не согласен.
Про getInitialProps попробуйте стянуть мой проект и удалить эту функцию то поймёте о чем я.
Использование document и app глючили и не собирались в момент инициализации после добавления react-ioc. Но под конец разработки я не проверял.
Со стилями предпочитаю работать из под коробки. Добавление ещё одного типа добавит жалоб что слишком сложный проект.
Если они хотят, то в функционале реакт не было бы бы context.
Если ложить обычные svg в папку static то они будут при загрузке пропадать до момента полной загрузки. Увы, это не панацея.
Мокать это хорошо, но мокать таким образом как вы показали так же не нравится многим клиентам и разработчикам, те тоже спорное решение. Лучше через dependency injection.
Я полностью за контроль состояния приложения через сервисы. Redux уж слишком заставляет много писать кода. Не говоря уже о других проблемах при написании бизнес логики между моделями, об этом как нибудь я напишу статью.
Я не использую PropTypes тут только потому что планировал переименовать все эти файлы в tsx и добавить типов. Но по времени не уложился.
Кто где сколько работал не является показателем знаний и реальных способностей. Извиняюсь, если грубо, но я бы с вами пообщался по Скайпу. Может что нить сделаем вместе, если у вас есть свободное время?
Второе замечание по сути ничего не даёт, опять же все упирается в баг ssr. К сожалению фрейм не без недостатков.
Typescript так же работает из под коробки только с чистым проектом, а как добавляешь изображения, стили, и тд и тд (я имею ввиду плагины), то проект не компилируется. Лучше ради тестового проекта сидеть на JS.
Не забывайте, что я сделал этот проект за день, учитывая, что я делал основную работу и вечером сидел с ребёнком. Мне, как и большинству таких как я очень дорого время, а написал статью я скорее для таких же как я, чтобы мы такие компании с завышенными чсв сотрудниками обходили стороной.
А попадись такой «ревьювер» начинающему программисту, руки отобьёт и заставит его уйти в другую область. Слава богу, что мне когда то попались отличные ребята.
Не путайте, есть компоненты shared, а есть внутренние. Те компоненты, что shared не будут иметь внешних зависимостей. А если вы хотите использовать фильтры, то используйте его shared версию, если ее нет, значит он не подрузамевался быть общим.
Передавать как property тут не подходит. Появляется колбаса из пропертей, для этого и есть react-ioc. Но пропертя не решит проблему сменившегося контекста вызова на компонент, вместо сервиса. Так как сделать иначе?
В требованиях к заданию, этого нет. Да и HR сказал что не надо.
А как надо? Через bind? Через bind тестируемость будет проблематична.