С топиком, видимо, неудачный пример я привел, потому что в таске вьюха - это функциональный компонент, а в топике классовые. Подробней о различиях между ними читай здесь: https://ru.reactjs.org/docs/components-and-props.html
Если коротко, то у классовых компонентов несколько методов есть и в итоге конечная отрисовка выполняется в методе Component::render, а функциональные - это конечные функции, у которых нет условно дополнительных методов и они как будто и есть функция render, то есть они сами по себе через return возвращают то, что должно быть отрисовано на странице, а вся логика выполняется в них самих (и различных хуках, которые так же выполняются в них). Сразу обозначу, что сейчас я все пишу на функциональных, и вам советую. А где встретятся class-based - это просто legacy, то есть наследие, которое лень было переписывать :)
Итак, тебе следует разобраться с жизненным циклом наших страниц.
1. Основа всего - GraphQL API. Так как данные мы забираем по API, то если мы не можем получить эти данные, то и вывести ничего не можем.
Для того, чтобы выполнить GraphQL-запрос на API-сервер, нам надо этот самый запрос прописать (то есть query task {...} и т.п.). В классическом случае эти запросы прописывались непосредственно в аполло-запросах. Пример: https://www.apollographql.com/docs/react/data/queries/
Но это не круто. Представь, что один и тот же запрос выполняться будет в нескольких компонентах. Надо запросы уметь складывать куда-то так, чтобы можно было из разных мест дергать один и тот же. Но тут возникает и другая проблема: надо потом иметь возможность узнавать какие компоненты мы зааффектили, если изменили этот запрос, так как изменения могут быть критическими и надо бежать поправлять все компоненты, которые используют эти запросы. А еще нужна проверка, что эти запросы соответствуют схеме API-сервера, а то вдруг на сервере что-то поменялось и наши запросы сломанные.
Вот для решения этих задач и написан скрипт, который вызывается yarn generate:types
Этот скрипт обращается к API-серверу, тянет его схему и генерирует из него TypeScript типы https://raw.githubusercontent.com/freecode-academy/freecode.academy/master/src/modules/gql/generated/types.ts.
В нем ты можешь найти в том числе и описание модели задачи.
Среди всех полей можно найти как раз нужные нам startDate, endDate, startDatePlaning и endDatePlaning. То есть в принципе, если данные с сервера будут получены, то там и эти поля должны быть. Но на самом деле это зависит от того, какие поля на самом деле прописали в запросах. Так вот, вторая часть указанного скрипта - это пройтись по самому проекту, найти все написанные в нем GraphQL-запросы и сформировать уже для них типы и конечные аполло-запросы.
В нашем случае запрос для страницы задачи написан здесь https://github.com/freecode-academy/freecode.academy/blob/b94b55a4a8fc0a75b2a45eea7a0cf03fc324af25/src/pages/Tasks/Task/gql/task.graphql: (хотя и будет скорее всего в будущем перемещен в https://github.com/freecode-academy/freecode.academy/tree/master/src/gql)
Обрати внимание на конструкцию ...task_. Троеточие - это указывает на то, что здесь надо вставить другой фрагмент, имя которому легион (нет, task_). Шутка про легион не спроста, таких вложений фрагментов может быть сколько угодно, но GraphQL следит за тем, чтобы они были корректны и составлены по правилам, иначе выдаст ошибку.
Там, как ты видишь, есть вложения и других фрагментов. Но главное, там есть вложение ...TaskNoNesting. В этом фрагменте перечислены нужные нам поля, так что все ОК.
2.Вывод полученных данных на странице.
В результате выполнения этого скрипта у нас появляются готовые функции для выполнения API-запросов, которые содержат в себе все прописанные нами поля. Конкретно для таски у нас вот хук-запрос: https://github.com/freecode-academy/freecode.academy/blob/b94b55a4a8fc0a75b2a45eea7a0cf03fc324af25/src/modules/gql/generated/task.ts#L61-L63
То есть теперь, в любом нашем функциональном компоненте мы можем вызывать этот запрос и в ответ получать запрошенные данные. Что мы и делаем вот здесь: https://github.com/freecode-academy/freecode.academy/blob/b94b55a4a8fc0a75b2a45eea7a0cf03fc324af25/src/pages/Tasks/Task/index.tsx#L32-L35
Надо понимать, что данные самого запрошеггого объекта - это не сам объект response, а его свойство data. Помимо data там есть и другие свойства, типа loading (флаг того, что запрос в процессе выполнения, errors и другие). См официальную документацию: https://www.apollographql.com/docs/react/data/queries/#result
И вот полученный нами объект мы передаем во вьюху: https://github.com/freecode-academy/freecode.academy/blob/b94b55a4a8fc0a75b2a45eea7a0cf03fc324af25/src/pages/Tasks/Task/index.tsx#L52
Вот и ты там можешь получить, к примеру, task.startDate и вывести в каком-либо виде. Только следи за ошибками тайпскрипта, потому что эти поля не строчные, а объекты Date. Вот как раз для этого и давал вьюху топика как пример. Смотри как там вывод сделан.
то есть выполняет проверка на наличие значения, и если есть, выводится через форматирование компонентом moment.
Думаю, это должно тебе пролить свет на выполнение задачи.