Лучшая практика для сохранения состояния между временно отключенными событиями Javascript?

Question

У нас есть приложение ASP MVC, которое использует частичные обновления AJAX. Когда пользовательское действие происходит на одной панели нашего экрана, мы должны обеспечить обновление нашего jsTree (на отдельной панели).

Однако попытка действовать в рамках успеха: часть вызова AJAX не работает - это происходит слишком рано, и jsTree еще не готов принять эти команды. Выполнение тех же команд позже работает просто отлично.

Мы решили эту проблему следующим образом: -После успеха AJAX сохраните нужный метод обратного вызова в новом классе Javascript:

var EPCStateMembers =
{
    _callbackMethod: "",

    StoreCallback: function (callbackMethod)
    {
        EPCStateMembers._callbackMethod = callbackMethod;
    },

    UseCallback: function ()
    {
        if (EPCStateMembers._callbackMethod != "")
            EPCStateMembers._callbackMethod();

        EPCStateMembers._callbackMethod = "";
    }
}

В рамках успеха AJAX мы вызываем EPCStateMembers.StoreCallback()

Затем, когда jsTree готово (указано его собственным событием, reselect.jstree) - мы вызываем EPCStateMembers.UseCallback();

Функционально это решение работает.

Однако, прежде чем мы смиримся с временными хранилищами состояний Javascript в качестве нашего решения goto... Я хотел бы задать вопрос - существует ли лучший шаблон или практика для таких ситуаций?

Answer 1

Я согласен, насколько это должно быть сохранено и выполнено как некоторый тип события onload, которое происходит на объекте дерева.

Но, поскольку это регулярно происходящая операция (изменяющая jstree), а не единичная инициализация, возможно, jstree должна беспокоиться о своем собственном внутреннем состоянии и должна ставить в очередь запросы на мутацию самостоятельно, когда это необходимо.

Я говорю это только потому, что стараюсь избегать объектов, которые имеют сложное внутреннее состояние API. Мне не нравится беспокоиться о том, не прекратится ли methodX или не сгенерирует ли это исключение IllegalStateException, когда разумно спроектировать эту возможность.

Кроме того, вы держите код более сухим. Вы никогда не будете иметь несколько случаев if(!tree.ready()) { queueit() } засорять ваш код, когда это можно было бы сделать в одном месте, инкапсулируя его.