в mobx просто другие обёртки над алгоритмом реактивности. Если сам алгоритм у kirBurkhanov написан хорошо, то не понимаю, что мешает считать такую реактивность настоящей. Дописать удобные обёртки (в тч. Proxy) делов на пару выходных.
В процессе полёта мысли можно начать складывать слонов с табуретками и далеко не сразу это заметить получая неверный результат, выглядящий вполне корректно. Потери времени в результате могут быть значительно больше. Ну и плюс отсутствие автодополнения. Чистый js может выигрывать только когда совсем уж мелкую утилитную функцию на пару строк нужно быстренько сбацать.
«явное лучше, чем неявное», подразумевая, что конкретное лучше, чем абстрактное
лично я никогда не видел в этом призыв отказаться от абстрагирования. Мне кажется здесь в первую очередь про неявное поведение, но я не питонист, так что могу ошибаться.
А как PHP отличает конкатенацию от чтения свойства в таких случаях 'string'.someVar? Это конкатенация с переменной someVar или чтение свойства someVar? Знак $ в начале переменных в этом как-то замешан?
Вы всерьез полагаете, что подписка на изменение модели — это всё, что делает стейт-менеджер?
Хранит и сообщает о изменениях — это необходимый минимум, чтобы называться стейт-менеджером, всё остальное опционально. Или я что-то забыл? Если нет, то предлагаемое решение вполне тянет на звание стейт-менеджера.
В данном случае компонент не получает ссылку на инстанс модели, а получает значение из модели, то есть ничего о существовании модели он по прежнему не знает. Здесь всё нормально и анти-паттерном это не является.
UPD: даже если компонент получает инстанс модели через параметр, но в самом компоненте этот инстанс описан интерфейсом, то есть нет импорта из модели, то это по прежнему просто передача значения и тоже всё нормально.
ну если достаточно такого уровня понимания, то да, всё просто и понятно — в аксессорах что-то там происходит и норм). Думаю многим хочется понимать чуть больше: как происходит выявление и поддержание в актуальном состоянии зависимостей вычисляемых ячеек, как происходит распространение изменений по цепочке вычисляемых ячеек и тд… Понимать это хочется на случай возможной отладки в каком то сложном кейсе и вот с этим пониманием как раз и появляются проблемы, поскольку алгоритм не так уж и примитивен и пару вдумчивых вечеров придётся ему уделить.
mobx 5 версия это proxy
с proxy как раз меньше всего проблем должно возникать, так как он просто обёртка над алгоритмом ничего о нём не знающем. Это просто способ уменьшить количество @observable в коде.
А аргумент «потратить пару вечеров, значительно облегчив себе дальнейшую жизнь» я думаю более чем оправдан, т.к. это не просто облегчение дальнейшей жизни, это сильное облегчение дальнейшей жизни.
да я то как раз не против и даже за, я просто пытаюсь найти объяснение, почему столь удобный подход получил столь малое распространение.
Для большинства главный минус MobX в том, что он слишком магический, нужно дольше разбираться, включать мозг. Большинству просто лень потратить пару вечеров, значительно облегчив себе дальнейшую жизнь. Да и зачем? Возросшая в полтора раза эффективность команды далеко не всегда очевидна руководству и вовсе не гарантирует симметричное увеличение ЗП.
впервые сложился «джентельментский набор» всех последующих библиотек того времени: доступ к DOM через функцию $(...)
насколько я помню $ (в PrototypeJS это $$, а $ там аналог современного querySelector (без All), которого ещё не было в браузерах и писались собственные движки) появился в PrototypeJS уже после появления jQuery, где он был изначально.
именно из-за этой строчки мы навсегда перестали пользоваться циклом for...in для перебора элементов массива
не из-за, а благодаря.
Вообще PrototypeJS хоть и сейчас никому не известная библиотека, но я считаю он дал фронтенду куда больше чем jQuery, он показал как надо более правильно писать код — с классами, неймспейсами, минимумом глобальных переменных и тп. Моментов вроде "не перебирать массив через for-in" там было вагон и тележка. Это был большой шаг вперёд, тот код, что писался до этого, от него сегодня кровь из глаз идти начинает. А jQuery в первую очередь показал как можно работать с коллекциями элементов через обёртку как с единым элементом, это и сегодня в некоторых местах может быть полезно, хотя с приходом биндингов во многом потеряло свою необходимость. Следующим большим шагом был, наверно, BackboneJS. Жаль, что про него в статье ни слова.
В чём разница между ES6-классами и конструкторами функций?
Что такое конструктор функции? Может функция-конструктор класса? Ладно, наверно, ошибка перевода, но ответ ещё интересней, зачем-то наследование приплели, как будто нельзя наследоваться новым синтаксисом от класса созданного по старинке или наоборот — наследоваться по старинке от класса созданного новым синтаксисом. Правильный ответ: класс — это функция-конструктор плюс прототип класса, а функция-конструктор — это только функция конструктор.
и в чём альтернативность? Вы действительно верите, что большинство разработчиков хоть иногда задумываются, что каждый день совершенно бесплатно пользуются огромным количеством чужой работы? Я вот уверен в обратном. Большинство ленятся даже завести ишъю, если найденная проблема не касается их лично. Утверждение, что таким образом можно хоть как-то выразить благодарность за существующий опенсорс вызывает удивление. Вот вы — ярчайший представитель. Я уже дважды предложил вам потратить каких-то пару минут и внести свой вклад, но вам лень.
не осознали разницу между issue и интересным фактиком
прекрасно осознаю разницу. Созданный ишъю — признак ответственного и благодарного разработчика, а ваш фактик — признак либо человека пытающегося самоутвердиться, либо балабола. Так кто вы? Этим вопросом я в третий раз предлагаю вам пройти на гитхаб и стать ответственным и благодарным разработчиком, а не выбирать между двумя не самыми приятными вариантами.
С чего вы взяли, что присутствует какая-то истерика? Я уже объяснил, что нужно было сделать с этим интересным фактиком. Ишъю уже заведён или вы просто местный балабол?
Давайте попробую иначе объяснить. Вот представьте, что вы пишете свою библиотеку, сделали хорошую документацию, вам она (дока) не нужна, вы и так весь АПИ отлично помните, но людям будет удобно. И вот вы выкладываете её в опенсорс, пишете статью и тут же получаете пафосный комментарий о баге. Приятно будет? Нельзя было тихонько завести ишъю? Я понимаю, что большинство исключительно использует наработки других, даже не пытаясь что-то давать взамен, но вы хоть на секунду ставьте себя на место авторов, испытывайте хоть немного благодарности (ведь вы каждый день совершенно бесплатно пользуетесь кучей таких наработок), а не тупое желание самоутвердиться типа "смотрите какой баг я сразу нашёл". Фу таким быть.
Для багов есть раздел issues на гитхабе. Какой смысл писать о нём в комментариях? Вы считаете, что нашли глобальный недостаток библиотеки, который ставит на ней крест?
В целом согласен. На данный момент правильным вариантом будет принятие обоих вариантов обеими сторонами. Любой утверждающий о правоте одного из вариантов в принципе не прав. Точку в этом вопросе могут поставить лишь разработчики языка.
вот с этим как раз больше всего проблем возникнет. Наиболее интересная на эту тему статья на на хабре: Изучаем и реализуем алгоритм работы правильного observer паттерна для react компонентов. Она, конечно, сильно облегчит вам работу, но может не стоит изобретать колесо? Посмотрите на cellx и на mobx. Оба решения отлично подходят для встраивания в фреймворки.
Так что на счёт самого алгоритма? Есть ли computed? Есть ли транзакции? Если этого нет, то MaZaAa прав, пока всё плохо.
в mobx просто другие обёртки над алгоритмом реактивности. Если сам алгоритм у kirBurkhanov написан хорошо, то не понимаю, что мешает считать такую реактивность настоящей. Дописать удобные обёртки (в тч. Proxy) делов на пару выходных.
В процессе полёта мысли можно начать складывать слонов с табуретками и далеко не сразу это заметить получая неверный результат, выглядящий вполне корректно. Потери времени в результате могут быть значительно больше. Ну и плюс отсутствие автодополнения. Чистый js может выигрывать только когда совсем уж мелкую утилитную функцию на пару строк нужно быстренько сбацать.
практически не сталкивался с такими, когда сталкивался, думал, что просто чуть опыта не хватает. А тут оказывается целая секта есть).
Бред же! Всегда с уважением относился к питон-сообществу, неужели не нашлось кого-то, кто поставил бы под сомнение этот пункт?
"Да что ты чёрт побери такое несёшь?" ©
лично я никогда не видел в этом призыв отказаться от абстрагирования. Мне кажется здесь в первую очередь про неявное поведение, но я не питонист, так что могу ошибаться.
А как PHP отличает конкатенацию от чтения свойства в таких случаях
'string'.someVar? Это конкатенация с переменной someVar или чтение свойства someVar? Знак $ в начале переменных в этом как-то замешан?не должен.
Хранит и сообщает о изменениях — это необходимый минимум, чтобы называться стейт-менеджером, всё остальное опционально. Или я что-то забыл? Если нет, то предлагаемое решение вполне тянет на звание стейт-менеджера.
В данном случае компонент не получает ссылку на инстанс модели, а получает значение из модели, то есть ничего о существовании модели он по прежнему не знает. Здесь всё нормально и анти-паттерном это не является.
UPD: даже если компонент получает инстанс модели через параметр, но в самом компоненте этот инстанс описан интерфейсом, то есть нет импорта из модели, то это по прежнему просто передача значения и тоже всё нормально.
ну если достаточно такого уровня понимания, то да, всё просто и понятно — в аксессорах что-то там происходит и норм). Думаю многим хочется понимать чуть больше: как происходит выявление и поддержание в актуальном состоянии зависимостей вычисляемых ячеек, как происходит распространение изменений по цепочке вычисляемых ячеек и тд… Понимать это хочется на случай возможной отладки в каком то сложном кейсе и вот с этим пониманием как раз и появляются проблемы, поскольку алгоритм не так уж и примитивен и пару вдумчивых вечеров придётся ему уделить.
с proxy как раз меньше всего проблем должно возникать, так как он просто обёртка над алгоритмом ничего о нём не знающем. Это просто способ уменьшить количество
@observableв коде.да я то как раз не против и даже за, я просто пытаюсь найти объяснение, почему столь удобный подход получил столь малое распространение.
Для большинства главный минус MobX в том, что он слишком магический, нужно дольше разбираться, включать мозг. Большинству просто лень потратить пару вечеров, значительно облегчив себе дальнейшую жизнь. Да и зачем? Возросшая в полтора раза эффективность команды далеко не всегда очевидна руководству и вовсе не гарантирует симметричное увеличение ЗП.
насколько я помню $ (в PrototypeJS это $$, а $ там аналог современного querySelector (без All), которого ещё не было в браузерах и писались собственные движки) появился в PrototypeJS уже после появления jQuery, где он был изначально.
не из-за, а благодаря.
Вообще PrototypeJS хоть и сейчас никому не известная библиотека, но я считаю он дал фронтенду куда больше чем jQuery, он показал как надо более правильно писать код — с классами, неймспейсами, минимумом глобальных переменных и тп. Моментов вроде "не перебирать массив через for-in" там было вагон и тележка. Это был большой шаг вперёд, тот код, что писался до этого, от него сегодня кровь из глаз идти начинает. А jQuery в первую очередь показал как можно работать с коллекциями элементов через обёртку как с единым элементом, это и сегодня в некоторых местах может быть полезно, хотя с приходом биндингов во многом потеряло свою необходимость. Следующим большим шагом был, наверно, BackboneJS. Жаль, что про него в статье ни слова.
Странный вопрос со странным ответом:
Что такое конструктор функции? Может функция-конструктор класса? Ладно, наверно, ошибка перевода, но ответ ещё интересней, зачем-то наследование приплели, как будто нельзя наследоваться новым синтаксисом от класса созданного по старинке или наоборот — наследоваться по старинке от класса созданного новым синтаксисом. Правильный ответ: класс — это функция-конструктор плюс прототип класса, а функция-конструктор — это только функция конструктор.
и в чём альтернативность? Вы действительно верите, что большинство разработчиков хоть иногда задумываются, что каждый день совершенно бесплатно пользуются огромным количеством чужой работы? Я вот уверен в обратном. Большинство ленятся даже завести ишъю, если найденная проблема не касается их лично. Утверждение, что таким образом можно хоть как-то выразить благодарность за существующий опенсорс вызывает удивление. Вот вы — ярчайший представитель. Я уже дважды предложил вам потратить каких-то пару минут и внести свой вклад, но вам лень.
прекрасно осознаю разницу. Созданный ишъю — признак ответственного и благодарного разработчика, а ваш фактик — признак либо человека пытающегося самоутвердиться, либо балабола. Так кто вы? Этим вопросом я в третий раз предлагаю вам пройти на гитхаб и стать ответственным и благодарным разработчиком, а не выбирать между двумя не самыми приятными вариантами.
С чего вы взяли, что присутствует какая-то истерика? Я уже объяснил, что нужно было сделать с этим интересным фактиком. Ишъю уже заведён или вы просто местный балабол?
Невозможность переноса в другой документ делает лопату лопатой? Над этим что ли я должен подумать? Вы уж либо расшифруйте, либо не несите бред.
Давайте попробую иначе объяснить. Вот представьте, что вы пишете свою библиотеку, сделали хорошую документацию, вам она (дока) не нужна, вы и так весь АПИ отлично помните, но людям будет удобно. И вот вы выкладываете её в опенсорс, пишете статью и тут же получаете пафосный комментарий о баге. Приятно будет? Нельзя было тихонько завести ишъю? Я понимаю, что большинство исключительно использует наработки других, даже не пытаясь что-то давать взамен, но вы хоть на секунду ставьте себя на место авторов, испытывайте хоть немного благодарности (ведь вы каждый день совершенно бесплатно пользуетесь кучей таких наработок), а не тупое желание самоутвердиться типа "смотрите какой баг я сразу нашёл". Фу таким быть.
Для багов есть раздел issues на гитхабе. Какой смысл писать о нём в комментариях? Вы считаете, что нашли глобальный недостаток библиотеки, который ставит на ней крест?
В целом согласен. На данный момент правильным вариантом будет принятие обоих вариантов обеими сторонами. Любой утверждающий о правоте одного из вариантов в принципе не прав. Точку в этом вопросе могут поставить лишь разработчики языка.