Comments (12)
Note that the closure-based api is necessary because the scoped thread cleanup must happen for memory safety. When memory safety is not being enforced, then normal Drop
implementations can be used, eg std::fs::File
closes the file on drop, and doesn't use a closure-based API because if the file fails to close it doesn't break memory safety.
from gloo.
Just FYI, the local storage APIs are heavily discouraged, because they are synchronous, which means they fully block page loading. This causes significant performance issues.
Instead, the recommendation is to use IndexedDB, or the new experimental kv-storage API (not stabilized, and Chrome only for now).
from gloo.
I think it makes sense to have what we've dubbed "mid-level" APIs for local storage, even if IndexedDB is preferred.
I'm not sure if we should be encouraging bad APIs. Especially APIs with really bad performance (Rust is supposed to be fast!), especially when there's a better alternative.
Instead, I think we should just make the IndexedDB API really good and convenient, so nobody feels the need for local storage.
Using web_sys
directly is always an option if people really need local storage.
Also, what would a "mid-level" API for local storage even look like? Here's how it looks like using raw web_sys
:
let store = window().unwrap().local_storage().unwrap().unwrap();
store.set_item("foo", "bar").unwrap();
Aside from all the .unwrap()
s, there isn't too much to improve upon, since local storage is such a simple API. So what did you have in mind for how to add it into Gloo?
I don't think we should build libraries for anything that is still experimental / not cross-browser supported and part of the open Web yet (like the kv-storage API).
Agreed, I just brought it up because it will (eventually) be replacing local storage, and it also showcases why local storage is bad.
from gloo.
Instead, I think we should just make the IndexedDB API really good and convenient, so nobody feels the need for local storage.
Indeed! This is a great vision!
Aside from all the
.unwrap()
s, there isn't too much to improve upon, since local storage is such a simple API. So what did you have in mind for how to add it into Gloo?
Hm, yeah I guess there isn't really anything for a mid-level API to improve upon. A higher-level API could allow transparent serialization and deserialization to and from storage.
Overall, I agree that effort is better probably spent on Indexed DB (although if @c410-f3r is only interested in tackling local/session storage, I think it is worth accepting PRs for it and not rejecting them).
from gloo.
Rust doesn't have linear types so we can't enforce a .final() call statically, but I think any design should at least be able to implement the same runtime checks.
It's possible to emulate linear types using closures:
db.transaction(|tx| {
tx.push(...);
// At the end of the closure the tx is committed
})
Since tx
is a reference (not an owned value), it's statically guaranteed that it won't outlive the closure.
(If needed, we can provide an escape hatch that allows for the usage of a transaction outside of a closure, but that should have a lot of warnings in the docs).
from gloo.
@yoshuawuyts Rust used to have a thread::scoped
API which used RAII to allow for using references between threads.
However, this API caused undefined behavior because it was not guaranteed that the thread guard would be dropped.
So it was removed and instead a new API was created to access references across threads.
This new API is safe because it uses a closure to statically restrict the lifetime of the variables. So it's another example of using closures to emulate linear types.
I've found that many issues involving lifetimes in Rust are solved with closures.
from gloo.
I will work on it
from gloo.
I think it makes sense to have what we've dubbed "mid-level" APIs for local storage, even if IndexedDB is preferred. At minimum, it will make writing spec-compliant TodoMVC for various frameworks easier 😆
I don't think we should build libraries for anything that is still experimental / not cross-browser supported and part of the open Web yet (like the kv-storage API).
But yeah, would also love to get the ball rolling on Indexed DB too!
from gloo.
The nanoidb crate might be a good reference for an IndexedDB design.
In particular one gotcha to watch out for when working with IndexedDB is that transactions / batched changes are automatically persisted to the database at the end of the current event loop tick. If not careful this means that you could be trying to persist data to the database after the current transaction has completed, creating some awkward situations.
The way we designed around that was by requiring a .flush()
call to be called at the end of the tick, or else we'd throw a runtime error on the next tick (src). Rust doesn't have linear types so we can't enforce a .final()
call statically, but I think any design should at least be able to implement the same runtime checks.
from gloo.
@Pauan ohhhh, TIL! -- this is very cool; thanks for sharing!
from gloo.
Thanks for this informative conversation that will certainly improve the API design.
from gloo.
Fixed in #125
from gloo.
Related Issues (20)
- gloo-worker: incorrect worker path loading when root url is different HOT 1
- [Draft RFC] Make `gloo_net` more idiomatic
- Patch required to fix confusing docs that still show `from_serde` and `into_serde` examples the wrong way around
- `gloo_net`'s `RequestBuilder` is not public
- Use OnceCell for gloo-history HOT 2
- gloo-histroy Support custom query decoder / encoder HOT 9
- Retries for EventSource HOT 1
- async wasm tests don't seem to actually do anything HOT 2
- [history] BrowserHistory: Loaded wrong state HOT 2
- gloo-net: Allow RequestBuilder.query to accept a struct that implements serde::Serialize as an argument HOT 1
- How to close a WebSocket after calling `.split()` ?
- Cloning gloo-worker bridges does not assign new HandlerIds
- Not working with recent yew-0.21.0 HOT 1
- Blob & ObjecUrl generate invalid dowload link HOT 3
- Allow calling `terminate` on workers
- [history] Inconsitent type between gloo_history and gloo_utils HOT 10
- Remove event in another event HOT 2
- Complete gloo-worker webassembly example running in a browser HOT 2
- Feature request: MissedTickBehavior for gloo_timers::future::IntervalStream
- Documentation - broken method reference
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from gloo.