В одном из решений здесь есть пример того, как точно не надо делать (хотя технически это возможно, и даже решение принято как правильное). Технически, эти методы делают то, чего от них и ожидалось: увеличивают и уменьшают значение состояния. Но в данном случае проблема в том, что используются операторы ++ и --. Соль обоих операторов в том, что они не просто возвращают новое значение (если они использованы перед переменной), но еще и меняют саму переменную. То есть еще до того, как реально отработался метод setState(), значение переменной this.state.count уже было изменено. И в чем же здесь проблема? А в том, что у вас в этот момент потерялась возможность среагировать на это изменение внутри своего компонента и сравнить его со старым (или новым) состоянием. В реакте в классовых компонентах есть некоторые методы специально для таких случаев, например shouldComponentUpdate, который дает возможность вам решить стоит ли ререндерить компонент в ответ на полученные изменения, и componentDidUpdate, который выполняется сразу после обновления компонента (при поступлении новых свойств или изменении состояния). Логика обоих методов в том, чтобы иметь возможность сравнить старое и новое состояние и в зависимости от изменений решить стоит ли еще что-то предпринять. Вот давайте добавим эти методы в правильно написанном классе: Кликнем increment и посмотрим вывод в консоль: Как мы видим, в этих методах действительно присутствуют разные значения в старом и новом состоянии. То есть здесь мы легко можем написать логику типа А теперь сделаем вызов на неправильном компоненте и посмотрим результат: Здесь мы имеем одинаковые значения и в старом и в новом состояниях, потеряв всякую возможность сравнить были ли значения изменены. В общем, старайтесь избегать таких подводных камней. Это может привести к тому, что состояние изменится, а ререндеринг в DOM не выполнится, потому что старое состояние будет равно новому.
Не очень понял, почему, но мне вообще оказалось не нужно распарсивать JSON. Это потому что в GraphQL-схеме у тебя задан тип JSON. GraphQL-сервер сам на лету обрабатывает JSON-поля. Точнее чистый GraphQL таким не занимается, но apollo-server да. >> здесь все равно поставил :any, так как не нашел иного типа для объекта data С any тут все понятно: у тебя для моля задано JSON. Сам же наверняка понимаешь, что по сути там может прийти любая валидная JSON-строка, так что при парсинге никак нельзя быть уверенным, какая конечная структура получится. Тем не менее, прелесть any в том, что ты легко этому можешь задать свой тип заместо any. Пример: Как видишь, здесь я для data уже описал более четкую структуру, прописав, что это объект, который содержит свойство src, тип которому - строка (правда обязательно ли содержит или нет, это тебе уже виднее, а то может там должен быть тип src?: string | null). А вот text я не описал, потому вот ошибки появились, надо прописать. Но это в случае, если у тебя там структура заранее известна и она такая и есть. Ежели ты предполагашь, что там в итоге просто будет объект с произвольными полями, то можешь так описать: Тогда будет доступно любое свойство, а его значение будет расценено как строка.
Николай, привет! Посмотри, пожалуйста, исправленный вариант: https://github.com/linklib/miniwar/commit/963bea3dbc40ea5e49f813cd441ffffd29e8d342 Не очень понял, почему, но мне вообще оказалось не нужно распарсивать JSON. И вопрос: здесь все равно поставил :any, так как не нашел иного типа для объекта data: https://github.com/linklib/miniwar/blob/963bea3dbc40ea5e49f813cd441ffffd29e8d342/src/pages/Posts/Post/View/index.tsx#L8 Явно что-то на базовом понтийном уровне не выстроено в башке, вот хочу разобраться...
В целом, да. Но это если говорить про вопрос передачи поста во вьюху. Но вот с парсингом контента и дальнейшим его выводом у тебя все очень плохо. 1. JSON.parse() - это очень капризный метод. Если что-то не так, он разваливается с критической ошибкой. То есть у тебя приложение рискует частенько разваливаться. Сам попробуй в консоли, к пример, выполнить такое: Получишь ошибку. Если у тебя такое приведет к ошибке в реакт-компоненте, то у тебя вся страница развалился. Методы объекта JSON надо оборачивать в try/catch. 2. У тебя content имеет тип any, хотя ты даже сам в случае отсутствия объекта post передаешь по умолчанию в content пустую строку. При этом далее выполняешь content.blocks.map(....). Попробуй-ка выполнить content.blocks.map() на пустой строке. Резуме: технически твой код может работать (если залетели правильные данные), но он очень ненадежен и обязательно даст сбои, если данные залетят невалидные. У тебя даже эслинт подсказывает "Здесь у тебя any, задай нормальный тип". Это бардак. Такой бардак допускать нельзя. Прорабатывай типы более четко.
А точно, забыл про эту консоль. Спасибо
Николай, если будет время, посмотри, пожалуйста, правильно распутался или не очень: https://github.com/linklib/miniwar/commit/c5d27e078801c8198171cda80e2d40e5fecc8b92
А, и да. При получении поста из массива есть засада. То есть в тайпскрипт есть бага при получении элементов из массива. Пример: Как ты видишь, array здесь - пустой массив. Хотя не важно пустой он или полный. Важно другое - в нем нет элемента с индексом 999 (в данном случае вообще ни одного). При этом typescript здесь константе a задаст тип string, а не string | undefined. То есть typescript не понимает, что элемент может и отсутствовать. К чему я это? Если ты таким образом прокинешь post дальше как есть, TS будет думать, что у тебя этот объект всегда есть, хотя на самом деле его может и не быть.