На последней работе хотел все переписать на Редакс (писал на нем несколько лет), но сначала решил посмотреть как оно работает на МобХ. На редакс не стал переписывать и дела с ним иметь больше не хочу. Добавил для мобикса несколько базовых классов для разных целей: данные, страница, диалог, итд, а также общий базовый класс для поддержки иерархии и инициализации. Теперь класс состояния не требует даже конструктора, только логика и состояние и те частично в базовых классах.
Как API не назови, а он все равно останется API. И неважно, будет он между сервером и клиентом, двумя серверами или двумя модулями… Отсутствие желания его документировать, делать его простым и удобным или поддерживать для использования на стороне всё ещё не превращает его из API во что-то другое, а просто делает его «плохим» API. Но он всё равно остается интерфейсом и всё равно программным.
Последний раздел об управлении состоянием конечно показывает вариант использования внутренних возможностей React для управления состоянием, но сильно замусоривает код, в отличие от многих специализированных библиотек (например MobX). Кроме того, если собрать все состояния в одном провайдере, то все зависимые компоненты будут рендерится при изменении любой части состояния. Если разобрать их на отдельные провайдеры, то получится провайдер хелл. Тот же MobX имеет механизм сбора состояний под одним провайдером и предотвращения перерисовки всех компонентов, кроме использующих изменившееся состояние. И этот механизм очень прост. В остальном он пользуется тем же Context API, что и ваш пример. Так что не усложняет использования состояния и упрощает его декларацию.
Видео снять, к сожалению, невозможно, поскольку проблема рандомальная. Я также понимаю, что отыскать такого типа проблему очень сложно и может отнять реально много времени. Сам когда-то сидел двое суток над чем-то подобным. Самый действенный способ, с моей точки зрения, не пытаться воспроизвести, а работать на интуиции, но для этого нужно очень хорошо знать код, в котором может быть проблема. К сожалению ничем более помочь не могу. Описание простое, решение сложное, увы.
Да, это та самая проблема, только от другого юзера, но это не важно. Важно, что она висит 4 года. Потихоньку к ней добавляются другие рандомальные глюки drag-n-drop, когда ты выделяеш текст, начинаеш тщить, и видиш, что выделен совсем другой кусок, иногда даже не под курсором. И т.п.
Не смог найти. Возможно открывал с одного из мертвых ныне рабочих аккаунтов. Но проблема, которую я описал, все еще жива. И любой QA наткнется на нее в первую же неделю, а может день.
Ну создал я ишью. Еще несколько версий назад. Мне ответили, что невоспроизводимо. А глюк продолжает сохраняться из версии в версию и на разных компьютерах. Глюки с выделением и переносом текста мышкой только множатся. И исходный глюк, когда при попытке перенести выделенный текст, вдруг начинает переноситься вкладка файла жив и здоров. Выскакивает рандомально, но не редко. Редактор, конечно, крутой, но количество постоянно выскакивающих проблем начинает сильно раздражать.
Во первых, инструменты и библиотеки компонентов — это принципиально разные вещи, но, почему-то, все обзоры считают необходимым включить первые в список вторых.
Во вторых, все обзоры включают в себя MD и Bootstrap, хотя вокруг существуют и другие, гораздо более полные и, зачастую, более красивые, библиотеки компонентов. Я использую Ant Design в нескольких последних проектах. После того как коллеги увидели и оценили его возможности, ни о каких MD уже никто не вспоминает. Дизайнеры тоже плюнули на вездесущие подчеркнутые боксы и рисуют новые картинки с учетом дизайна. Хотя в первой фирме я в несколько CSS определений переделал вид боксов под MD.
Правда, в последнее время, другие библиотеки начали подтягивать свой набор компонентов, и там появилось многое, что родилось в Ант.
Что-то сломалось с JSDoc typedef документацией. Во-первых на нее теперь не переходит по клику в доке, на нее ссылающемся (хотя он подсвечена как линк и курсор ручкой). Во-вторых, когда стоишь внутри описания, то по Ctrl-Q ничего не всплывает (а раньше всплывало текущее описание)
Если изучить ванильный API, то доучить JQuery не составит труда, зато вам не потребуется потом его включать в любые проекты (в которых он нужен как собаке пятая нога) только для того, чтобы найти элемент. Кроме того я еще в начале вхождения в веб попробовал Полимер и выкинул JQuery на следующий день. А сегодня, я бы посоветовал начать с ванильного API (который дозрел до уровня JQuery) и сразу после него Реакт.
Тогда уж Html в JS. И нет в синтаксисе ничего особенного. Знак меньше — пошел html, фигурная скобка — пошел JS, закрыл скобку — опять html. Вложенность не ограничена. В остальном практически чистые языки. Очень по мелочам всякие className отличаются от оригинала.
Вы сравниваете классы и прототипы — вещи несравниваемые. Класс это сущность парадигмы ООП. Прототип — имплементация. ООП в JS ничем (за исключением нюансов) не отличается от ООП в других языках. JS имплементирует ООП с помощью прототипов, С++ компилятором со статическими сущностями. Обусловлено это тем, что первый — динамический интерпретатор, а второй статический компилятор (или проще: так получилось).
А все эти способности на лету чего-то портить никак не связаны ни с ООП ни с прототипами. Все это динамичность языка.
А вы пытаетесь показать разницу между классами и прототипами в том что прототипы можно менять или клеить на лету.
В этом и есть ошибка подхода.
А еще, наличие обьектов не делает ваш код обьектно-ориентированным.
Так же, как с помощью функций можно организовать и функциональную и процедурную парадигмы, так и с помощью прототипов можно организовать и практически класический ООП и тот кошмар который приведен в статье.
То что можно на лету менять прототип и его содержимое, тем самым меняя поведение конечной сущности, — это заслуга отнюдь не прототипного наследования (хотя косвенно и оно участвует), а динамической основы языка. Такое же поведение можно реализовать и без прототипов, если задаться целью.
Грубо говоря, наличие прототипов и динамичности позволяет как «вить веревки», так и «стрелять себе в ногу». Все зависит от желания пользоваться парадигмами или возможностями.
У меня был прямо противоположный опыт. Начал с CodeMirror, но, к сожалению, не удовлетворил Intellisense. Перешёл на Монако. Очень геморройно было интегрировать. Постоянно вылазили дикие краши внутри движка. В одном случае полез в сорс и нашёл вызов функции с параметрами, которые заведомо приводят к возврату null, при этом вызывающая функция без проверок пытается обратится к полям возвращаемого значения, что и приводило к крашу. Тесты, похоже, там и не валялись. Кроме этого пришлось импортировать скомпилированный движок через HTML и он весил около мега, а когда импортировал его в JS он вдруг наподключал аж 3 мега. Может я его неправильно готовил, но я шёл по документации и примерам.
Наваять много дерьма можно и на Реакт и на Вью и на Ангуларе и даже на чистом JS. Я сейчас по работе переписал Ректовскую часть небольшого проекта с Реакт на Вью, вернее добавил еще одну реализацию UI для лекции по Редакс. Этот самый Редакс у них общий, и находится в отдельном пакедже, как и Реакт с Вью. Так вот, совсем не заметил какой-то принципиальной разницы в размере кода. Да подход отличается и даже привязка Редакса несколько другая. Но разницы в 70% нет даже близко. Возможно 10% и то с учетом стилей, поскольку выбранная (не мной) библиотека на Реакте проигрывает по гибкости. Если бы я выбрал другую, то не уверен, что код на Вью был бы меньше.
На последней работе хотел все переписать на Редакс (писал на нем несколько лет), но сначала решил посмотреть как оно работает на МобХ. На редакс не стал переписывать и дела с ним иметь больше не хочу. Добавил для мобикса несколько базовых классов для разных целей: данные, страница, диалог, итд, а также общий базовый класс для поддержки иерархии и инициализации. Теперь класс состояния не требует даже конструктора, только логика и состояние и те частично в базовых классах.
А я и не утверждал, что оно в приведенном вами коде, оно в приведенном мною коде.
Именно это я и имел виду, когда написал: "(второе делает меньше операций)"
уже бред, поскольку происходит двойное присвоение, хотя оно тоже даст аналогичный результат. Вряд ли это то что будет под капотом.
Во вторых, все обзоры включают в себя MD и Bootstrap, хотя вокруг существуют и другие, гораздо более полные и, зачастую, более красивые, библиотеки компонентов. Я использую Ant Design в нескольких последних проектах. После того как коллеги увидели и оценили его возможности, ни о каких MD уже никто не вспоминает. Дизайнеры тоже плюнули на вездесущие подчеркнутые боксы и рисуют новые картинки с учетом дизайна. Хотя в первой фирме я в несколько CSS определений переделал вид боксов под MD.
Правда, в последнее время, другие библиотеки начали подтягивать свой набор компонентов, и там появилось многое, что родилось в Ант.
то обычный for произведет 1001 итерацию, а forEach, for..in, for..of только одну
А все эти способности на лету чего-то портить никак не связаны ни с ООП ни с прототипами. Все это динамичность языка.
А вы пытаетесь показать разницу между классами и прототипами в том что прототипы можно менять или клеить на лету.
В этом и есть ошибка подхода.
А еще, наличие обьектов не делает ваш код обьектно-ориентированным.
То что можно на лету менять прототип и его содержимое, тем самым меняя поведение конечной сущности, — это заслуга отнюдь не прототипного наследования (хотя косвенно и оно участвует), а динамической основы языка. Такое же поведение можно реализовать и без прототипов, если задаться целью.
Грубо говоря, наличие прототипов и динамичности позволяет как «вить веревки», так и «стрелять себе в ногу». Все зависит от желания пользоваться парадигмами или возможностями.
Наверстай упущеное.
Спасибо. Есть кое-что интересное.