3 ms·
Synchronous persistence APIs should be considered dangerous. Often they solve the immediate problem, but when you eventually need to move to an async storage so
by mixonic 12y ago
Synchronous persistence APIs should be considered dangerous. Often they solve the immediate problem, but when you eventually need to move to an async storage solution (and in JavaScript any significantly complex task eventually becomes async) you are left with code that presumes sync behavior. This makes it difficult to refactor.
Providing an API with callbacks or better yet promises forces you to write future-safe code.
- vivab0rg 12y agoThis. I recently moved to localForage[1] and have been mostly satisfied so far. Thanks Mozilla! [1]: http://mozilla.github.io/localForage/ http://mozilla.github.io/localForage/
- cobalt2760 12y agoIt might be a little bit "overkill" when you just want to perform storage only on client device no? (Basil aim is not to override backend storage like REST APIs)
- nawitus 12y agoThat's a good point. The same issue seems to exist with almost every JavaScript function interface. Whether or not a function is synchronous or asynchronous seems to be an implementation detail (at least in theory), but that fact must be exposed in the function interface. I think the main issue is actually with language design. Callbacks and promises are not decent ways to handle asynchronity in my opinion. Perhaps it could be abstracted away in the language itself in a way that the function interface would be identical for both "sync" and async functions..
- ef4 12y agoI came here to say the exact same thing. Even if you're using synchronous storage, wrap it in an asynchronous API and save yourself a world of hurt later.