Через несколько недель изучения фронтенд-разработки на Javascript я понял, как сильно я люблю данные. Наконец-то я смог увидеть поток данных, от того места, где они инициализируются в базе данных, до места, где они отображаются на экране. Это напомнило мне ход истории.

При выборе типа рассказчика, которого вы хотите использовать в своей истории — от первого лица, от третьего лица и т. д. — вы должны действительно понимать ход своей истории. Вы должны знать, что знают ваши персонажи в каждый данный момент, что знает ваш рассказчик и что знает ваш читатель. Только так вы сможете выбрать правильного типа рассказчика и лучший способ рассказать свою историю.

Я провел четыре дня, работая над своим проектом для хакатона: View Your Times — картой визуализации данных, которая показывает пользователю, где происходят главные новости New York Time.

Мой партнер и я решили использовать сочетание API «главных новостей» New York Times, потому что он возвращал массив статей в главных новостях во всех разделах в данный момент. Мы решили использовать HighCharts API, потому что он хорошо документирован и имеет встроенную функциональность, которую мы искали — отображение стран разными цветами и возможность обработки кликов по отдельным странам. Мы решили использовать React-Redux для хранения всех данных наших статей в нашем магазине Redux и предоставления соответствующих данных статей нашим различным компонентам React. Мы предоставили все данные статьи основному компоненту карты, но вернули соответствующие статьи только в том случае, если вы находились на странице отдельной страны.

Мы начали с работы с API New York Times. Мы настроили аксиальный запрос, по которому все статьи попали в топ новостей на тот момент. Выяснив, что включает в себя ответ JSON, мы можем проанализировать данные и извлечь из них то, что нам нужно. Мы решили использовать HighCharts для визуализации данных, потому что это позволило нам настроить способ отображения стран на карте в зависимости от набора данных, переданного на карту.

Главной задачей для нас было создать наше приложение таким образом, чтобы данные в нашем бэкэнде, поступающие из NYTimes API, могли легко синхронизироваться с картой HighCharts, которую мы визуализируем в нашем интерфейсе.

Примерно через месяц работы с React и другими внешними библиотеками я понял, что пишу свой внутренний и внешний интерфейс так, как будто я пишу сюжетную линию истории.

Нам нужно было преобразовать запрос JSON в массив, который могла бы отобразить наша карта. История данных началась с запроса axios, который мы сделали в нашем бэкэнде, и мы медленно перемещали его через наш магазин Redux, а затем в наш компонент React. Мы должны были помнить, что наши данные никаким образом не изменялись в ходе этого процесса — мы должны были знать, что наше приложение знает на всех этапах игры.

Самый большой пример этого был при создании нашего компонента React. Нам нужно было придумать способ убедиться, что мы получаем данные из New York Times, прежде чем мы начнем фильтрацию, и мы должны были закончить фильтрацию перед визуализацией карты. Сюжетная линия этих данных была очевидна, и единственным оставшимся вопросом было то, как мы будем реализовывать этот поток.

Мы смогли использовать цепочку обещаний для управления потоком данных. Мы также использовали собственный хук React ComponentDidMount, чтобы убедиться, что мы запускаем нашу функцию buildMap только после рендеринга соответствующего div.

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

Это третья часть моей серии Чему творческое письмо научило меня программировать, вторую часть можно посмотреть здесь.