Sergiu Mitu

Хороший вопрос, но думаю, ответ все же нет, хотя хотелось бы услышать мнение экспертов из Яндекса. Может соблюсти какие-то условия, например, оставить ту же страницу и 301 редирект на нее, или тот же контент (если вдруг менялся дизайн) и 301 редирект на него, но так по сути, думаю нет. Ведь там привязка скорее всего скриптовая, а они работать должны на той странице, на которой были запущены и давать результаты только для нее, если страница поменяется, то и, соответственно, контент тоже должен поменяться в том числе и расшаривания и дискусии.

const jsx = э-э-э, чё, это у вас тут фигурная скобка?

ошибка появилась из ниоткуда

Нет, она появилась из вашего невежества и лени. Вы бы почитали про jsx хоть что-нибудь, прежде чем начать код писать, чтобы вот так не позориться. Меняйте скобки на круглые.

1. Закомментированный код на гитхабе - не хорошо. https://github.com/marinarodkin/aviasales-app/blob...
   
2. Минимум логики в render функции компонента. Все сложные конструкции переносите в методы, а лучше в отдельные компоненты (тогда сможете легче контролировать перерисовку компонентов через shouldComponentUpdate , чтобы они не перерисовывались, если данные не поменялись). Вы можете прямо как методы писать стрелочные функции:
   

   class Flight extends Component {
       getWeekDay = (date) => {
           //..
       }
       // ....
   }

   
   
3. Вы в половине случаев используете точку с запятой, а в половине нет. Используйте чаще.
   
4. Атрибут for нельзя использовать в jsx (как и class, как вы знаете). Вместо for пишите htmlFor
   
5. Смотрите консоль инструментов разработчика, там есть ошибки.
   
6. Освойте shouldComponentUpdate, он позволяет контролировать перерисовку компонента при изменении состояния или пропсов. У вас при изменении кол-во пересадок, перерисовывается весь список билетов, даже те, которые уже были в этом списке. Многие скажут, что еще рано такое учить, но я не согласен. Если не учиться контролировать перерисовку еще в начале обучения, то можно написать очень много тормознутого софта.
   
7. У вас данные ticket.json подгружаются хардкодно из github, это не хорошо, т.к. этот файлик с данными есть в папке public, и если потенциальный работодатель захочет поменять там что-то, он не увидит изменений (т.к. грузится с гитхаба).
   
8. У вас если в данных в параметре departure_date стоит 11.10.2018 (т.к. сегодня), то отобразится это как "11 окт 2018, вс", т.е. день недели неправильный. А он неправильный потому, что это не октябрь, а ноябрь. Ошибка в методе getDateFormat
   

   const newDate  = new Date (year, month, day, );
   const monthName = ["дек", "янв", "фев", "мар", "апр", "мая", "июня", "июля", "авг", "сент", "окт", "ноя", "дек"];
   const newMonth = monthName[newDate.getMonth()];

   
   конструктор Date вторым аргументом ожидает номер месяца, нумерация которого начинается с нуля. т.е. 0 - январь, 1 - февраль, 11 - декабрь. Судя по monthName вы подозвевали, что есть что-то неладное, но ошибись с реализацией. monthName должен иметь обычный вид, начинаться с января и заканчиваться декабрем, т.к. нулевой элемент массива как раз подходит по логике с нулевым месяцем. В getDateFormat, а также в getWeekDay, вычтите из month - 1
   const newDate = new Date(year, month - 1, day)
   
9. У вас в тех же getDateFormat и getWeekDay в конструкторе Date вы в конце аргументов пишите запятую, так не нужно делать. Это не вредно и не полезно, просто дурной тон. Там в любом случае будет undefined, хоть с запятой хоть без нее.
   
10. Картинки тоже грузятся с marinarodkin.github.io, измените.
    
11. 
    

    const getStopsNumber = (stop) =>{
          switch (stop) {
            case 3:
              return "3 пересадки"
            case 2:
              return "2 пересадки"
            case 1:
              return "1 пересадка"
            case 0:
              return "без пересадок"
            default:
              return // это не нужно делать, писать return. Если вы удалите эту (и строку выше), то результат будет такой же - undefined
          }
        }

    
    
12. Если бы в SideBar пропс stopsData был не объектом, а строкой или числом, то компонент SideBar можно было бы безболезненно превратить в PureComponent. Ну это так, к слову об оптимизации.
    
13. Я бы в stopsClick передавал не объект события e, из которого вы потом берете id элемента через e.target.id (что не есть гуд), а сделал бы стрелочную функцию (или bind), в которую бы передавал id. Вот так
    

    <input onClick={() => this.props.stopsClick("allStops")} />
    <input onClick={() => this.props.stopsClick("noStops")} />

    
    Если это читают опытные ReactJS разработчики, рассудите пожалуйста. Согласен, что на каждый компонент будет создана своя копия функции, но по крайней мере, не нужно взаимодействовать с DOM напрямую.
    
14. Это не красиво
    

    if( this.state.stops.allStops === false && this.state.stops.noStops === true && this.state.stops.oneStop === true && this.state.stops.twoStop === true && this.state.stops.threeStop === true  ){
             newStops = {...this.state.stops, allStops: true}
        }

    
    мне кажется, на дальнейшую логику это никак не играет роли, лишь создает глюк, когда выбираешь все чекбоксы кроме "все", и если кликнуть после этого на один из них, он не отожмется, а лишь включится чекбокс "все".
    
15. Попробуйте везде сократить повторяющиеся конструкции. Например начните с stopsClick Не говорю, что у вас сразу получится, это приходит с опытом. Но просто попытайтесь подумать, как это можно сократить.
    

Может я многое высосал из пальца, но это будет вам полезно. Учитесь, развивайтесь. Удачи вам в этом :-)

Есть ли смысл

Ну да, главное это оформить в виде красивого кейса с непонятными графиками.

Обязательно. Вы же показываете свой уровень, своими работами. Обязательно, даже удачные наброски, прототипы и т.д.
Я вот наоборот практиковал не выкладывать в банк работ как сданные и рабочие проекты, которые были сданы мной с кучей дуростей по прихоти заказчиков. Всем наверное приходилось за деньги делать что то против себя, и за что в последствии как минимум не испытывали гордости.

Если хотите, что бы ваш код можно было просматривать, то выкладывайте build, src и package.json, но не надо заливать node_modules, это бессмысленно. Кому нужно, сам установит все зависимости.

Если вам просто нужны githubPages, и код показывать не намерены, то понадобится только содержимое папки build.

выкладывать надо исходный код в общем случае.
Собранные файлы (build), зависимости (node_modules) не надо.
Так же не следует выкладывать папки типа .idea, .vscode и файлы с конфигами где хранятся ключи доступа к API и пароли к БД, если такие имеются.