Тут вопрос спросили, про качество кода. @AnonovVaasya спасибо.
Увы... Не знаю, рассказать то могу, а вот сделать как...
twitter.com/AnonovVaasya/s…
Для себя волнующих моментах в последнее время предпочитаю давно всеми забытый паттерн с Фабриками Конструкторов: это когда функция возвращает конструктор, поставляя ему переданный аргументом прототип.
Если вы спросите стал ли бы я применять такое в коммерческих продуктах, то я бы стал... Это работало 20 лет назад, и ничего другого я не знал. Сейчас оно тоже работает. Будет ли мой коллега рад такому коду? Опросы показывают, что этот код пугает, особенно новичков, результатами.
Смысл в том, что каждому создаваемому экземпляру поставляется в соответствие конструктор, подготовленный специально для него. Воспроизводимость результатов достигается единой ответственностью фабрик: каждая фабрика поставляет конструкторы одного вида. Хотя и это можно изменять...
Другая особенность в том, что если взять Конструктор и выставлить ему прототип, потом положить его в него другой Конструктор и выставляешь ему прототипом
this полученный от первого, то можно получить мануфактуру фабрик.Да, возможно кому-то покажется забавным. У этого подхода тогда было название: "Схема Тройничка". Потому, что два конструктора "замыкаются" через и один исходный экземпляр. Тут второй конструктор будет независимым, и на его основе можно создавать произвольное число экземпляров.
Важно то, что их можно объединить в цепочку. И эта цепочка может по прототипам ветвиться очень далеко. Но есть и минусы, куда же без них.
Каждый раз создавать конструктор
Прототипы гибкие, и экземпляры тоже
В отладчике это выглядит порой даже хуже, чем объект
windowПервый минус легко решается самописной утилитой. Так как её свойства не могут быть универсальны, то её создание могло производиться отдельно под нужды проекта. Второй минус решается переопределением свойств экземпляров и инкапсулированием в рамках поведения.
Потом, конечно же, пришли люди и сказали, что в прототип нужно класть функции, мол, это удобно, и вообще мы отсталые. И, конечно же, всё испортили. Потом ещё появился
Object.create, который окончательно доломал всю эту нестройную систему... Деревья больше не растут.Так прошло 20, и мол, зачем вспоминать времена когда динозавры правили планетой? Но может быть сейчас то как раз самое время, чтобы это можно было вспомнить. У нас есть Object.setPrototypeOf, и, как это ни странно Proxy.
И если положить Proxy в конец цепочки прототипов, то... Можно, конечо, и не делать этого, но тогда будет всё "навиду" и в отладчике будет некрасиво. В общем Proxy может решить п. 3.
В книжках про это не пишут, т.к. этот тип прототипного наследования, он даже не классический, он уже, скорей, археологический. Но именно так можно получить свой собственный "карманный" ReactDom, например, просто положив его в начало цепочки ваших прототипов.
При этом наследование из экземпляра в экземпляр даёт всё те же самые возможности, что и раньше: контроллируется Execution Path, жизненный цикл и, самое главное: Контекст!
Контекст -- он оказывается неразрывано связан с
this, просто потому, что так устроено само это наследование. И мы можем его потерять, но не при создании цепочки, а потом, когда уже всё случилось.