Блог

Я пытаюсь создать что-то похожее на то, что показано на рисунке ниже.

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

 defaultState = {
    mode : "2up", //Defines layout and how many widgets to init
    models : [{year: 1980, selected: "SE"}, 
              {year: 2010, selected: "NO"}] //Widget models
}

var AppRouter = Backbone.Router.extend({                            
routes: {
    '': 'hashChangeHandler',
    'v1?:params': 'hashChangeHandlerV1'
},

hashChangeHandlerV1: function(params) {
    //here do something to override defaultState with params on init
    //set models and layout etc.
}
});

//Handle history entries separately??
collection.bind("change", updateHistory)

function updateHistory () {
    //each model toJSON(), then jQuery.param.querystring etc.  
    appRouter.navigate('v1'   state, false);
}
  

2) Может ли приведенное выше быть допустимым способом управления версиями?(Наличие определенного обработчика для маршрута v1 и другого для v2, если параметры состояния / API изменяются?) Если бы вы могли привести пример решения состояния / истории, которое будет работать для этого расширенного приложения для визуализации, я был бы очень рад 🙂

3) Я бы хотел запретить устанавливать запись истории при перетаскивании timeslider и в некоторых других событиях. Могу ли я удалить прослушиватель событий collection.change (который отслеживает все созданные экземпляры WidgetModels) при перетаскивании ползунка или что бы вы предложили?

Управление данными
Перед созданием экземпляров представлений (и при изменении атрибута выбора их модели) Я хотел бы убедиться, что данные (300-400 КБ числовой статистики. данные) загружены.
4) Каков типичный способ решения этой проблемы в Backbone?(Т.е. задержка событий model.trigger до тех пор, пока атрибуты не станут стабильными.)

4. дождитесь загрузки ваших моделей и только после этого создавайте экземпляры представлений.

В частности, у вас должен быть кто-то (возможно, представление приложения), который прослушивает событие загрузки ваших данных и создает представление.

Если ваши данные загружены в модель, то при success обратном fetch вызове вы можете вызвать событие, чтобы сообщить остальной части приложения, что оно было загружено.

Если ваши данные загружены в коллекцию, вы можете прослушать reset событие коллекции.