Valera Dobroman,
1) Архитектурный бэдпрактис. Код оказывается прибит гвоздями к нестандартному окружению (имеет абсолютно неявные зависимости).
2) Потенциальный конфликт имен - если завтра в глобальную область добавят поле с таким же названием, например, появится HTMLDocument.prototype. hello, которое отличается от твоего, будут веселье.
Сергей Кузнецов, остальные резолвить вручную, смотреть что и как. А некоторые - это отдельные специальные файлы, про которые точно известно, что там надо тупо взять вариант из branch_b.
Спасибо.
У нас при мерже некоторые файлы надо именно что "в одну сторону", то есть не глядя взять из branch_b. А обычно, да, открывается файл и вручную.
два варианта:
1) до получения ответа с сервера нет смысла в коде, который использует значение из контекста. Тогда ты всё это просто не рендеришь.
2) код может работать и без этого значения. Тогда действительно, можно сделать как посоветовал WbICHA, так как проверка объекта приобретает смысл.
Но типизацию в любом случае надо сделать. Иначе будет тоскливо.
WbICHA, код засоряется. А случай не продовский - забыть добавить провайдер для контекста можно только на этапе разработки, и это будет выявлено на первом дебажном запуске.
Елена, лучше не использовать any
а норм или не норм - зависит от ситуации. Если у тебя там произвольный набор ключей, то норм. А если объект с конкретными полями, то хрень.
WbICHA, через генерик придирается к {} - там не хватает ключей. А с undefined дурацкий вариант, придется проверять результат useContext.
Было бы идеально React.createContext< MyContextType >(), с выкидыванием эксепшена при забытом провайдере, но я так и не понял, почему от такого варианта отказались (на гитхабе есть пара обсуждений).
Gary_Ihar, складывать что-то в контекст - распространенная практика. Вовсе необязательно это должно быть какое-то изменяемое значение. Многие известные библиотеки хранят в контексте постоянные объекты. Например, тот же редукс (точнее, пакет "react-redux") хранит свой стор, а react-router - экземпляр History. Точно так же и мобиксовые сторы вполне могут лежать в контексте.
Для чего это нужно? Да для того же, для чего и DI в целом: отложить резолв зависимостей на потом, уменьшив зацепленность между кусками кода. Архитектурная тема, в общем.
Что значит дерево на основе списка? У бинарного дерева и двусвязного списка элементы по сути одинаковы - содержат значение и две ссылки. Из таких элементов можно составить дерево, но будет ли это "на основе списка"?
Вот на основе массива - запросто: для i-го элемента есть два чилда - [2i+1] и [2i+2].