如何管理应用程序和 URL 中的状态？
我正在构建一个 Web 应用程序，该应用程序在内部通过 URL 管理状态，以允许用户使用浏览器按钮以及网站的 UI 来操纵状态。
我正在使用 jQuery-BBQ 来管理 URL 哈希，并且我有一个处理程序on hashchange 会在 URL 更改时相应地更改内容（例如按下浏览器后退/前进按钮）。然而，事情本身发生了相应的变化，我最终改变了哈希值，从而触发了 hashchange 处理程序并导致了循环。
为了解决这些情况，我发现自己检查新状态是否与之前的状态相同，如果是则放弃。但我很快就得到了相当意大利面条化的代码，分别处理每个状态，并在每个状态上运行多个参与者。
是否有一种设计模式可以优雅地处理这种状态管理场景？
I'm building a web application that manages state internally and via the URL, to allow the user to manipulate state with the browser buttons as well as the site's UI.
I'm using jQuery-BBQ to manage the URL hash, and I have a handler on hashchange that changes things accordingly when the URL changes (e.g. browser back/forward button presses). However, the things changed accordingly themselves my end up changing the hash, thus triggering the hashchange handler and resulting in a loop.
To get around these scenarios, I find myself checking if the new state is the same as the previous, and bailing if so. But I'm quickly getting pretty spaghettified code, addressing each state separately with multiple actors operating on each state.
Is there a design pattern that handles this kind of state management scenario gracefully?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我现在无法推荐您实施任何特定的设计模式，但我可以建议您看一下 html5 的 PushSate() 和 popState() 函数。这些函数能够存储状态以及与这些状态相关的数据。 github.com 正在使用这种技术来遍历某个公共存储库的目录。这是一个快速指南：https://developer.mozilla.org/en/DOM/Manipulated_the_browser_history。希望这有帮助。
I cannot recommend you on any specific design pattern to implement right now, but I can suggest that you take a look at html5's pushSate() and popState() functions. These functions are capable of storing states as well as data that are tied to those states. github.com is using this technique to traverse thru the directories of a certain public repository. Here's a quick guide: https://developer.mozilla.org/en/DOM/Manipulating_the_browser_history. Hope this helps.
我最终所做的是严格在程序中只提供一个可以更改状态的位置，并通过该位置路由所有状态更改。
我所说的“一个地方”是指一组可公开访问的功能，其工作包括：
第 2 步可能是最重要的 - 它确保无论状态更改请求是来自应用程序内部还是来自浏览器，除了初始更改之外，都不会重复尝试更改应用程序或浏览器中的状态。
到目前为止一切顺利，这似乎将状态机的复杂性封装在我的代码的一部分中，使事情变得更容易保持正常......不过，我欢迎任何其他答案。我确信这个问题已经被解决过很多次了。
what i ended up doing is being rigorous about providing only one place in my program in which state can be changed, and routing all state changes through that one place.
by 'one place', i mean one group of publicly-accessible functions whose job includes:
step 2 is perhaps most important -- it ensures that whether the state change request is coming from within the application or from the browser, there will not be any repeated attempts to change state in the application or the browser beyond the initial change.
so far so good, this seems to encapsulate the complexity of the state machine in one part of my code, making it much easier to keep things straight...still, i welcome any other answers. i'm positive this is a problem that's been solved many times over.