Вы правы, но это буквальное понимание, реальное я не могу имитировать средствами js, тут больше подойдут картинки из объяснения механики работы объединения.
По поводу изменений второго примера, больше походит на попытку "обмануть систему", типизация в TS имеет некую "синтетику", в которой правила игры Вы описываете на этапе типизации исходных данных, т.е. если вы не описали, что полученный данные могу иметь null, то TS и не будет об этом знать, это Ваш контракт с собственной типизацией проекта. Реальность же будет выглядеть так, что если вы подготавливаете исходные данные, то и гарантировать их соответствие придется самостоятельно, например, просить TS явно их валидировать.
Весь пример из статьи можно полностью написать на inteface и так же полностью на type. Правильно я понимаю, что Вы не предлагаете разбираться чем же все-таки они отличаются, а предлагаете соглашение для дополнительного смыслового разделения? Тогда вопрос такой - что Вам мешает использовать type для описания поведения объектов и их методов и продолжать все так же разделять исходный код на:
... определенные атрибуты объектов.
... поведение объектов, их методы.
Интерфейсы позволяют разделять реализацию от так называемого слоя бизнеса.
Получается, что type тоже это позволяет?
Ощущение, что статья больше не про применение interface (особенно удобного в ООП) и type, а про разделение сборки свойств объектов.
На самом деле тут нет ничего странного, результат пересечения типов B | A = { x: number, y?: number }, именно поэтому y - может иметь значение null от этого и необходимо отталкиваться в порядке проверок внутри функции ПРИМЕР
А можно не рисковать и использовать Custom Element оставаясь "реакт-разработчиком" https://legacy.reactjs.org/docs/web-components.html. А при необходимости, можно прокинуть нужные связки с внешним реакт, например router, для ссылок, которые должны оставаться в рамках SPA, а не перезагружать всю страницу.
1) Не на каждом проекте нужен стейт менеджер, не на каждом проекте применяется именно MobX; 2) useEffect имеет свое прямое назначение, его, в принципе, не стоит применять для того, чего он не предназначен, т.к. он является инструментом работы с жизненным циклом функционального компонента React; 3) Если вернуться к теме материала, то пытаться исправить проблему из-за необдуманного использования значений по умолчанию в деструктуризации путем прикручивания стейт менеджера к проекту и только из-за этого начать задумываться зачем нужен useEffect, вместо того, чтобы задуматься над правильным использованием дефолтных значений, звучит странно.
Согласен. Могут быть даже более "забавные" события, например, когда такая переменная залетает в массив зависимостей useCallback какой-нибудь невзрачной функции, которая прокидывается на несколько уровней вложенности, уже где-то там эта функция залетает в зависимости useEffect, где изменяет стейт на уровне, где применяется эта "злополучная" деструктуризация с установкой значения по умолчанию и потенциально может войти в бесконечный цикл выполнения, но случай, когда эта переменная прилетает пустая и применяется значение по умолчанию сам по себе довольно редкий кейс, то еще надо словить его, прежде чем хотя бы начать поиск источника проблемы. А если это проект, где не проводят тестирование на получение минимального объема данных сущности, то можно и не знать, что где-то на проде есть 1-2 страницы товара, например, где страница пользователя зависает без шансов на спасение. Я, честно говоря, конкретно с таким не сталкивался на практике, просто дофантазировал один из примеров, но, теоретически, это вполне реально)
Смысл как раз в том, что это и есть одно и тоже, но на проектах часто не воспринимают добавление значения по умолчанию в момент деструктуризации, как создание новой переменной с присваиванием ссылки на новый пустой массив или объект. Цель была - обратить на это внимание тех, кто об этом ранее не задумывался.
В данном случае, я намеренно не стал описывать "правильный" вариант, т.к. вариантов избежать подобной проблемы много, главное знать о ней. Самый простой - не использовать значение по умолчанию для ссылочных данных (т.е. иметь необходимые проверки, чтобы не допускать ошибок работы с undefined), можно подготавливать данные заранее на уровне работы с API различными способами, хранить значения по умолчанию в константах, тогда при проверках - это будет одна и та же ссылка, назначать такие значения по умолчанию в низкоуровневых компонентах, которые мемоизированы и не передают их ниже, мемоизировать сами эти значения. Зависит от походов на проекте.
Вы правы, но это буквальное понимание, реальное я не могу имитировать средствами js, тут больше подойдут картинки из объяснения механики работы объединения.
По поводу изменений второго примера, больше походит на попытку "обмануть систему", типизация в TS имеет некую "синтетику", в которой правила игры Вы описываете на этапе типизации исходных данных, т.е. если вы не описали, что полученный данные могу иметь null, то TS и не будет об этом знать, это Ваш контракт с собственной типизацией проекта. Реальность же будет выглядеть так, что если вы подготавливаете исходные данные, то и гарантировать их соответствие придется самостоятельно, например, просить TS явно их валидировать.
Возможно, в примере не хватает некоторой логики, которая заставляет Вас применять адаптеры, т.к. мне они не понадобились, вот Ваш пример на типах
Во избежание критики, поправлюсь не пересечения, а объединения типов, описался. Чтобы получить ожидаемый результат, приведу еще один пример
Весь пример из статьи можно полностью написать на inteface и так же полностью на type. Правильно я понимаю, что Вы не предлагаете разбираться чем же все-таки они отличаются, а предлагаете соглашение для дополнительного смыслового разделения? Тогда вопрос такой - что Вам мешает использовать type для описания поведения объектов и их методов и продолжать все так же разделять исходный код на:
Получается, что type тоже это позволяет?
Ощущение, что статья больше не про применение interface (особенно удобного в ООП) и type, а про разделение сборки свойств объектов.
На самом деле тут нет ничего странного, результат пересечения типов
B | A = { x: number, y?: number }, именно поэтомуy- может иметь значение null от этого и необходимо отталкиваться в порядке проверок внутри функции ПРИМЕРА можно не рисковать и использовать Custom Element оставаясь "реакт-разработчиком" https://legacy.reactjs.org/docs/web-components.html. А при необходимости, можно прокинуть нужные связки с внешним реакт, например router, для ссылок, которые должны оставаться в рамках SPA, а не перезагружать всю страницу.
1) Не на каждом проекте нужен стейт менеджер, не на каждом проекте применяется именно MobX;
2) useEffect имеет свое прямое назначение, его, в принципе, не стоит применять для того, чего он не предназначен, т.к. он является инструментом работы с жизненным циклом функционального компонента React;
3) Если вернуться к теме материала, то пытаться исправить проблему из-за необдуманного использования значений по умолчанию в деструктуризации путем прикручивания стейт менеджера к проекту и только из-за этого начать задумываться зачем нужен useEffect, вместо того, чтобы задуматься над правильным использованием дефолтных значений, звучит странно.
Согласен. Могут быть даже более "забавные" события, например, когда такая переменная залетает в массив зависимостей useCallback какой-нибудь невзрачной функции, которая прокидывается на несколько уровней вложенности, уже где-то там эта функция залетает в зависимости useEffect, где изменяет стейт на уровне, где применяется эта "злополучная" деструктуризация с установкой значения по умолчанию и потенциально может войти в бесконечный цикл выполнения, но случай, когда эта переменная прилетает пустая и применяется значение по умолчанию сам по себе довольно редкий кейс, то еще надо словить его, прежде чем хотя бы начать поиск источника проблемы. А если это проект, где не проводят тестирование на получение минимального объема данных сущности, то можно и не знать, что где-то на проде есть 1-2 страницы товара, например, где страница пользователя зависает без шансов на спасение. Я, честно говоря, конкретно с таким не сталкивался на практике, просто дофантазировал один из примеров, но, теоретически, это вполне реально)
Смысл как раз в том, что это и есть одно и тоже, но на проектах часто не воспринимают добавление значения по умолчанию в момент деструктуризации, как создание новой переменной с присваиванием ссылки на новый пустой массив или объект. Цель была - обратить на это внимание тех, кто об этом ранее не задумывался.
В данном случае, я намеренно не стал описывать "правильный" вариант, т.к. вариантов избежать подобной проблемы много, главное знать о ней. Самый простой - не использовать значение по умолчанию для ссылочных данных (т.е. иметь необходимые проверки, чтобы не допускать ошибок работы с undefined), можно подготавливать данные заранее на уровне работы с API различными способами, хранить значения по умолчанию в константах, тогда при проверках - это будет одна и та же ссылка, назначать такие значения по умолчанию в низкоуровневых компонентах, которые мемоизированы и не передают их ниже, мемоизировать сами эти значения. Зависит от походов на проекте.