Спасибо за руководство к действию, но к сожалению сейчас нет времени писать статью. Отдельное вам спасибо что вы это время нашли! Если есть какие-то конкретные вопросы то я постараюсь ответить.
Это вы конечно хитро придумали! Смысл не в том как мы все обустроили, а как какую-то вашу проблему можно решить с помощью этой библиотеки. С другой стороны если у вас проблем нет — то может оно вам и не надо)
Возможно по такому небольшому обзору это не очень понятно, но mobx/mobx-react действительно очень полезная вещь, и она набирает популярность. Если вам знакома боль от кучи экшнов/редьюсеров redux-а и большого количества boilerplate кода в компонентах то посмотрите на mobx. Мы его начали использовать в крупном проекте пол года назад и не только уменьшили количество кода в целом, но и сделали его более доступным для понимания новых разработчиков разного уровня. Готов поделиться подробностями, если кому интересно, без смс и регистрации =)
Вы совершаете ту же ошибку что и автор — бегло смотрите доки) Ну или в доках этот момент явно не прописан. Есть модификатор asFlat, который позволяет подписываться только на изменение массива — добавление/удаление элементов, при этом не слушая их «дочерние» изменения.
Про программирование в уме — я прошу прощения если это прозвучало грубо, просто автор привел конкретный пример, можно долго фантазировать «а если бы» но это уже будет другой пример =) Из серии «а если поставить там-то точку с запятой то будет SyntaxError».
В целом да, но это так же как сказать что React привносить магию в концепцию шаблонирования, а например, node.js в концепцию CGI =) Про метод change — если вы начинаете додумывать и программировать в уме то делайте рефакторинг там же и подписывайтесь на конкретный todo, а не на его название описание и название, тогда будет одно событие. У автора же цель показать как это работает, а не додумать за вас все возможные добавления методов в API
Да даже если и ждут, классика Flux — пришел ответ с сервера, у нас данные нормализованы и лежат по своим сторам. Мы подождали, пускай и несколько, асинхронных запросов и сразу 10 сторов эмитят событие 'change'. Начинаются каскадные ре-рендеры, которые надо вручную обходить через shouldComponentUpdate (см ниже)
У redux другая болезнь, в реальном, как вы говорите, приложении, у вас либо мало компонентов подписаны на единственный стор и тогда у вас боль с пробрасыванием данных через props или context, либо подписано много компонентов и тогда на каждый чих стора у вас… тадам — ре-рендеры, которые надо вручную обходить через shouldComponentUpdate =)
с shouldComponentUpdate отдельная песня, учитывая что данные обычно нормализуют их потом приходится денормализовывать, а js, гад, часто выдает как результат этого всегда новые массивы и обьекты.
Вот чтобы избавить от этой боли и был создан mobx, и это не имеет ничего общего с ужасом типа Knockout, имхо.
Я уж не знаю что там за реальные приложения где ходят сразу по несколько асинхронных запросов, но дело же не только в них. В сторах хранится state, который содержит не только данные, которые получают асинхронными запросами.
Flux-подход был решением, путем введения unidirectional data flow которым можно полностью управлять и вызывать render через setState когда нужно. Некоторые flux-библиотеки испортили этот подход
Некоторые? Сама концепция React+Flux строится на том что мы на каждое изменение стора (неважно один он у вас или несколько) делаем render, потому что он «бесплатный» и у нас есть Virtual DOM, и только в исключительных случаях используем shouldComponentUpdate. Mobx (и mobx-react) как раз позволяет использовать sideways data loading, когда у вас ре-рендер происходит не на каждый чих стора, а при изменении конкретных данных, которые использует компонент
Вы знали) причем не только компилит, но еще и тесты прогоняет и страницу в браузере обновляет. Каждый сам для себя решает — ходить пешком, ездить на велосипеде или на машине. И да, водить надо-таки учиться.
А по-моему рекламные кампании проваливаются тогда когда небольшие компании пытаются повторять за крупными, параллельно имея огромные проблемы с определением ЦА, тоесть пытаются продавать всем, но не имеют на это ресурсов, а ограничивать себя как-то боятся
Ну проблема-то не в том чтобы скомпилировать, а в том чтобы как-то организовать кучу ивентов, запросов и ответов, чтобы это можно было потом разобратЬ)
Может быть вы подскажете, как понять что пора заменить JQuery-код на, например backbone?
Например, я пишу админку для проекта, там ajax-CRUD, но на одностраничный сервис это явно не тянет.
Стоит и там использовать bb?
Про программирование в уме — я прошу прощения если это прозвучало грубо, просто автор привел конкретный пример, можно долго фантазировать «а если бы» но это уже будет другой пример =) Из серии «а если поставить там-то точку с запятой то будет SyntaxError».
У redux другая болезнь, в реальном, как вы говорите, приложении, у вас либо мало компонентов подписаны на единственный стор и тогда у вас боль с пробрасыванием данных через props или context, либо подписано много компонентов и тогда на каждый чих стора у вас… тадам — ре-рендеры, которые надо вручную обходить через shouldComponentUpdate =)
с shouldComponentUpdate отдельная песня, учитывая что данные обычно нормализуют их потом приходится денормализовывать, а js, гад, часто выдает как результат этого всегда новые массивы и обьекты.
Вот чтобы избавить от этой боли и был создан mobx, и это не имеет ничего общего с ужасом типа Knockout, имхо.
Некоторые? Сама концепция React+Flux строится на том что мы на каждое изменение стора (неважно один он у вас или несколько) делаем render, потому что он «бесплатный» и у нас есть Virtual DOM, и только в исключительных случаях используем shouldComponentUpdate. Mobx (и mobx-react) как раз позволяет использовать sideways data loading, когда у вас ре-рендер происходит не на каждый чих стора, а при изменении конкретных данных, которые использует компонент
Например, я пишу админку для проекта, там ajax-CRUD, но на одностраничный сервис это явно не тянет.
Стоит и там использовать bb?