Closed Trufi closed 8 years ago
:+1:
А оно точно надо? А то как-то странно это выглядит.
Ну сейчас весь механизм финалайзера не работает в случае, если были сделаны переходы по истории.
:+1:
:+1:
Пока у меня есть сомнения что правильно помещать что-то в объект стейта. Нужно подумать.
Как минимум два метода StateApi.prototype.assign
и StateApi.prototype.defaults
теперь могут потенциально привести к ошибкам
В эти два метода можно добавить проверку на добавление обязательных полей в стейте.
Пока я вижу 3 варианта решения и оба не простые
implicitChanges
также передавались в истории через historyAPI
.state
сделать не простым литералом, а кастомным объектом у которого есть дополнительное хранилище в виде implicitChanges
. Надо добавить метод, который будет преобразовывать этот объект в такой литерал как сейчас для сохранения и передачи по истории, ну и в обратную сторону. И проверить как это всё используется везде.
3*
. Подумать как вообще без этого обойтись.А вы не думаете, что признак того, кем именно скрыт дашборд (юзером или датавьювером, грубо говоря) - это тоже просто обычная переменная в стейте, на которую дашборду и следует ориентироваться? И можно будет выгасить все эти странные имплиситы, которые, помнится, чисто для одного дашборда и впиливались.
@heilage-nsk именно про это и 3 пункт. У меня тоже желание это выпилить полностью ибо выглядит ужасно.
Все несколько сложнее (не просто ключик дашборда), чем вам кажется, вот список имплиситов: https://github.com/2gis/online4/blob/master/components/appState/state/finalizer/places.js#L53
Окей, не один ключик дашборда, а несколько х) Некоторые кстати на грым ориентируются и выпилятся скоро. Остальные вполне могут ориентироваться на некоторые дополнительные флаги стейта.
Проблема: при переходе по истории передается только
state
, аimplicitChanges
никак не меняются, хотя по сути являются также состоянием приложения.Минус пулл-реквеста в том, что теперь
implicitChanges
также будут попадать в диффы.