Pull to refresh
4
0
Send message
странно то, что Вы присваиваете значение в пайлоад, беря значение из того-же пайлоада
ну копировать код или задачи из жиры я не будут, опишу в вольном стиле приблизительно, что для меня сложные эффекты:
есть блок полей связанных, например личная информация о пользователях, с бэка приходят возможные наборы, взятые из баз партнеров. Эти блоки могут не содержать часть полей, необходимых нам, так же некоторые данные этих полей могут оказаться «плохими».
Задача: узнать у пользователя какие данные его, если нет его данных предоставить все поля для заполнения. Если узнали какой блок данных пользователя, показать пользователю только те поля, которых у нас нет, а так же поля, данные которых «плохие». Так же могут меняться типы поле и подписи к ним, в зависимости от количества пришедших блоков данных.
Только в redux это усложнено и размыто по куче ненужных сущностей.

Я как раз люблю слабую связанность кода, и разбитие на слои, мне больше нравится, чем иметь только контроллер и сервисы
первый пост и больше думал о том, как донести мысль, не сильно задумываясь о картинках, но уже поправил примеры
Мое мнение, более простых альтернатив я не пробовал. А по поводу излишества кода, пост как раз об этом.
в целом, мне интересно попробовать, я лишь высказал вещи, которые бросились в глаза ;)
все, я понял что вы имели виду, спасибо за ваше потраченное время ;)
Вы наверное путаете валидацию на фронте, с серверной, она будет асинхронна, и влаг валидности поля будет установлен после ответа сервера, а значение в поле установить сразу надо
это все понятно, но все же, 4 против 90, ладно там 30/90 ну 20/90, а так, Вы говорите с 2016, так мало кто перешел? vue с 2015 первая версия, и на том же сайте соотношение react/vue 283/83
прикольно конечно, это же в рендере, а как тут добавить серверную валидацию по мимо обновления значения?
Учитывая, что в JS при добавлении в хеш и удалении из хеша пересоздаётся внутренний класс — выгоднее делать это классически через фильтрацию, к примеру. А сортировать как-то иначе хеш вообще нереально)

Вопрос не в производительности, а в читаемости. для обновления значения в сторе используя массив, код будет выглядеть примерно так:
  [fieldsActions.changeFieldValue] = (state, payload) => {
    const index = state.indexOf(payload.fieldName);
    const nextState = [...state];
    nextState.splice(index, 1, {
      ...(state[payload.fieldName] || initialFieldData),
      enteredValue: payload.value,
    });
    return nextState;
  };

используя хэш так:
[fieldsActions.changeFieldValue] = (state, payload) => ({
    ...state,
    [payload.fieldName]: {
      ...(state[payload.fieldName] || initialFieldData),
      enteredValue: payload.value,
    },
  });

на просто примере разница кажется не сильно большой, но в реальном проекте, читаемость сильно отличается
Массивы перебирать вам не придётся если вы сохраните ссылку на элемент вместо имени поля.

не совсем понял Вашу мысль, я инициализировал список полей как массив, потом пользователь вводит данные в одно из полей и мне надо в торе изменить значение value. Как это сделать, не перебирая массив в поисках нужного поля?
Я б делал это через массив типизированных инстансов. С массивом в JS работать значительно удобнее, чем с хешем.

если это сделать через массив, очень много придется перебирать эти массивы для поиска, изменения и удаления. Как это выглядит в коде, мне абсолютно не понравилось, а с хэшами, немного приятнее, но тоже не обошлось без неудобств.
Если вам так нравится слабая связность — не одна только саги её вам могут обеспечить. Простейший EventEmiter пишется за пару минут...

немного сомнительно, я использую только часть возможностей саг, однако, даже эту небольшую часть реализовать руками, займет время, мне проще добавить сахара к имеющемуся, что и вправду быстро.
Альтернатива-то какая?

я без понятия, в сторону mobx только начал смотреть, может Вы знаете решения
Непонятно, что за события.

я имел ввиду, ввод данных пользователем, и я понимаю, что из одно экшена мы можем изменять весь стор, но это приведет в сильно большим экшенам(action()). Но это вначале были мои мысли, сейчас я разобрался как этого избежать.
Это вообще непонятно. Как работать неизвестно с чем? Вы к каким полям обращаться потом будете? Можно практический пример? Я за свою практику никогда не видел такой странной задачи.

куски кода менее понятны, я просто опишу задачу. Нужен инструмент для создания форм, есть набор полей, которые будут почти в каждой форме, однако, он может отличаться, в зависимости от формы, причем формы могут содержать уникальные поля, присущие только ей.
Для решения этого, я собираю имена полей и регистрирую их сторе при старте и работаю с ними по единому интерфейсу для полей, но на этапе разработке их имен я не знаю.
А где, по вашему, обновление стора должно лежать?

обновление стора правильно лежит, меня смутило, что там не только обновление стора, но и вся логика лежит, в случае с redux-saga, редьюсеры отвечают только за обновление стора, а бизнес логика лежит в сагах
Если же огромных саг у вас не наблюдается — почему экшены в MobX должны магическим образом стать таковыми?

саги не большие, это достигается тем, что на 1 экшен реагирует несколько различных саг, отвечающих за свой кусок логики. И как я написал выше, в случае с mobx, как я понял, будут экшены реагирующие на изменение части стора и изменять свою соответственно
Не понимаю о чём вы пишете.

если я правильно понял
Пишите в разных, никто не запрещает же

Вы имели ввиду, вынести логику в сервисы, и вызывать их из экшенов
@action foo() {
    store.bar.x++;
    store.baz.y = someService.someProcessing(store.bar); //какая-то бизнес логика
}

и это, мне не очень нравится, я об этом говорил выше
Разместить этот метод можно в любом классе, который вы считаете подходящим для этой цели.

получается будут огромные экшены, меняющие разные, не связанные части стора, это не страшно, если кода не много, но на проекте котором я работаю, будут сложности. Хотя, как я понял, можно просто добавлять доп. экшены, которые будут срабатывать на изменения полей.
Пишите в разных, никто не запрещает же

опять же, придется напрямую вызывать эту логику из экшенов, и вслучае добавление новой, надо опять, залазить в экшен и добавлять вызов, в случае с сагой, обновление стора зависит только от экшенов
посмотрел вакансии фронтов, и на том сайте было 90 вакансий с упоминанием  redux и только 4 с mobx. Интересно, почему…
1

Information

Rating
Does not participate
Registered
Activity