ну копировать код или задачи из жиры я не будут, опишу в вольном стиле приблизительно, что для меня сложные эффекты:
есть блок полей связанных, например личная информация о пользователях, с бэка приходят возможные наборы, взятые из баз партнеров. Эти блоки могут не содержать часть полей, необходимых нам, так же некоторые данные этих полей могут оказаться «плохими».
Задача: узнать у пользователя какие данные его, если нет его данных предоставить все поля для заполнения. Если узнали какой блок данных пользователя, показать пользователю только те поля, которых у нас нет, а так же поля, данные которых «плохие». Так же могут меняться типы поле и подписи к ним, в зависимости от количества пришедших блоков данных.
Вы наверное путаете валидацию на фронте, с серверной, она будет асинхронна, и влаг валидности поля будет установлен после ответа сервера, а значение в поле установить сразу надо
это все понятно, но все же, 4 против 90, ладно там 30/90 ну 20/90, а так, Вы говорите с 2016, так мало кто перешел? vue с 2015 первая версия, и на том же сайте соотношение react/vue 283/83
Учитывая, что в JS при добавлении в хеш и удалении из хеша пересоздаётся внутренний класс — выгоднее делать это классически через фильтрацию, к примеру. А сортировать как-то иначе хеш вообще нереально)
Вопрос не в производительности, а в читаемости. для обновления значения в сторе используя массив, код будет выглядеть примерно так:
Массивы перебирать вам не придётся если вы сохраните ссылку на элемент вместо имени поля.
не совсем понял Вашу мысль, я инициализировал список полей как массив, потом пользователь вводит данные в одно из полей и мне надо в торе изменить значение value. Как это сделать, не перебирая массив в поисках нужного поля?
Я б делал это через массив типизированных инстансов. С массивом в JS работать значительно удобнее, чем с хешем.
если это сделать через массив, очень много придется перебирать эти массивы для поиска, изменения и удаления. Как это выглядит в коде, мне абсолютно не понравилось, а с хэшами, немного приятнее, но тоже не обошлось без неудобств.
Если вам так нравится слабая связность — не одна только саги её вам могут обеспечить. Простейший EventEmiter пишется за пару минут...
немного сомнительно, я использую только часть возможностей саг, однако, даже эту небольшую часть реализовать руками, займет время, мне проще добавить сахара к имеющемуся, что и вправду быстро.
Альтернатива-то какая?
я без понятия, в сторону mobx только начал смотреть, может Вы знаете решения
я имел ввиду, ввод данных пользователем, и я понимаю, что из одно экшена мы можем изменять весь стор, но это приведет в сильно большим экшенам(action()). Но это вначале были мои мысли, сейчас я разобрался как этого избежать.
Это вообще непонятно. Как работать неизвестно с чем? Вы к каким полям обращаться потом будете? Можно практический пример? Я за свою практику никогда не видел такой странной задачи.
куски кода менее понятны, я просто опишу задачу. Нужен инструмент для создания форм, есть набор полей, которые будут почти в каждой форме, однако, он может отличаться, в зависимости от формы, причем формы могут содержать уникальные поля, присущие только ей.
Для решения этого, я собираю имена полей и регистрирую их сторе при старте и работаю с ними по единому интерфейсу для полей, но на этапе разработке их имен я не знаю.
А где, по вашему, обновление стора должно лежать?
обновление стора правильно лежит, меня смутило, что там не только обновление стора, но и вся логика лежит, в случае с redux-saga, редьюсеры отвечают только за обновление стора, а бизнес логика лежит в сагах
Если же огромных саг у вас не наблюдается — почему экшены в MobX должны магическим образом стать таковыми?
саги не большие, это достигается тем, что на 1 экшен реагирует несколько различных саг, отвечающих за свой кусок логики. И как я написал выше, в случае с mobx, как я понял, будут экшены реагирующие на изменение части стора и изменять свою соответственно
Не понимаю о чём вы пишете.
если я правильно понял
Пишите в разных, никто не запрещает же
Вы имели ввиду, вынести логику в сервисы, и вызывать их из экшенов
Разместить этот метод можно в любом классе, который вы считаете подходящим для этой цели.
получается будут огромные экшены, меняющие разные, не связанные части стора, это не страшно, если кода не много, но на проекте котором я работаю, будут сложности. Хотя, как я понял, можно просто добавлять доп. экшены, которые будут срабатывать на изменения полей.
Пишите в разных, никто не запрещает же
опять же, придется напрямую вызывать эту логику из экшенов, и вслучае добавление новой, надо опять, залазить в экшен и добавлять вызов, в случае с сагой, обновление стора зависит только от экшенов
есть блок полей связанных, например личная информация о пользователях, с бэка приходят возможные наборы, взятые из баз партнеров. Эти блоки могут не содержать часть полей, необходимых нам, так же некоторые данные этих полей могут оказаться «плохими».
Задача: узнать у пользователя какие данные его, если нет его данных предоставить все поля для заполнения. Если узнали какой блок данных пользователя, показать пользователю только те поля, которых у нас нет, а так же поля, данные которых «плохие». Так же могут меняться типы поле и подписи к ним, в зависимости от количества пришедших блоков данных.
Я как раз люблю слабую связанность кода, и разбитие на слои, мне больше нравится, чем иметь только контроллер и сервисы
Вопрос не в производительности, а в читаемости. для обновления значения в сторе используя массив, код будет выглядеть примерно так:
используя хэш так:
на просто примере разница кажется не сильно большой, но в реальном проекте, читаемость сильно отличается
не совсем понял Вашу мысль, я инициализировал список полей как массив, потом пользователь вводит данные в одно из полей и мне надо в торе изменить значение value. Как это сделать, не перебирая массив в поисках нужного поля?
если это сделать через массив, очень много придется перебирать эти массивы для поиска, изменения и удаления. Как это выглядит в коде, мне абсолютно не понравилось, а с хэшами, немного приятнее, но тоже не обошлось без неудобств.
немного сомнительно, я использую только часть возможностей саг, однако, даже эту небольшую часть реализовать руками, займет время, мне проще добавить сахара к имеющемуся, что и вправду быстро.
я без понятия, в сторону mobx только начал смотреть, может Вы знаете решения
я имел ввиду, ввод данных пользователем, и я понимаю, что из одно экшена мы можем изменять весь стор, но это приведет в сильно большим экшенам(action()). Но это вначале были мои мысли, сейчас я разобрался как этого избежать.
куски кода менее понятны, я просто опишу задачу. Нужен инструмент для создания форм, есть набор полей, которые будут почти в каждой форме, однако, он может отличаться, в зависимости от формы, причем формы могут содержать уникальные поля, присущие только ей.
Для решения этого, я собираю имена полей и регистрирую их сторе при старте и работаю с ними по единому интерфейсу для полей, но на этапе разработке их имен я не знаю.
обновление стора правильно лежит, меня смутило, что там не только обновление стора, но и вся логика лежит, в случае с redux-saga, редьюсеры отвечают только за обновление стора, а бизнес логика лежит в сагах
саги не большие, это достигается тем, что на 1 экшен реагирует несколько различных саг, отвечающих за свой кусок логики. И как я написал выше, в случае с mobx, как я понял, будут экшены реагирующие на изменение части стора и изменять свою соответственно
если я правильно понял
Вы имели ввиду, вынести логику в сервисы, и вызывать их из экшенов
и это, мне не очень нравится, я об этом говорил выше
получается будут огромные экшены, меняющие разные, не связанные части стора, это не страшно, если кода не много, но на проекте котором я работаю, будут сложности. Хотя, как я понял, можно просто добавлять доп. экшены, которые будут срабатывать на изменения полей.
опять же, придется напрямую вызывать эту логику из экшенов, и вслучае добавление новой, надо опять, залазить в экшен и добавлять вызов, в случае с сагой, обновление стора зависит только от экшенов