I'm making a to-do list application with HTML, CSS, and JavaScript, and I think the best way for me to store the data would be a local database. I know how to use localStorage and sessionStorage, and I also know how to use an online MySQL database. However, this application must be able to run offline and should store its data offline.
Is there a way I could do this with just HTML and JavaScript?
Responding to comments:
"You said you know how to use localStorage... so what seems to be the problem?"
#Lior All I know about localStorage is that you can store a single result, as a variable whereas I wish to store a row with different columns containing diffenent data about the object. However, can localStorage hold an object and if so is it referenced with the usual object notation?
Any implementation will probably depend on what browser(s) your users prefer to use.
#paul I think chrome will be most popular.
Okay, I would like to clarify that what I was asking was indeed How can I do this with JavaScript and HTML rather than Is there a way I could do this with just HTML and JavaScript?. Basically, I wanted a type of SQL database that would save its contents on the user's machine instead of online.
What solved my problem was using WebDB or WEBSQL (I think it was called something like that that).
I'm about 3 years late in answering this, but considering that there was no actual discussion on the available options at the time, and that the database that OP ended up choosing is now deprecated, I figured i'd throw in my two cents on the matter.
First, one needs to consider whether one actually needs a client-side database. More specifically...
Do you need explicit or implicit relationships between your data items?
How about the ability to query over said items?
Or more than 5 MB in space?
If you answered "no" to all of the above, go with localStorage and save yourself from the headaches that are the WebSQL and IndexedDB APIs. Well, maybe just the latter headache, since the former has, as previously mentioned , been deprecated.
Otherwise, IndexedDB is the only option as far as native client-side databases go, given it is the only one that remains on the W3C standards track.
Check out BakedGoods if you want to utilize any of these facilities, and more, without having to write low-level storage operation code. With it, placing data in the first encountered native database which is supported on a client, for example, is as simple as:
bakedGoods.set({
data: [{key: "key1", value: "val1"}, {key: "key2", value: "val2"}],
storageTypes: ["indexedDB", "webSQL"],
//Will be polyfilled with defaults for equivalent database structures
optionsObj: {conductDisjointly: false},
complete: function(byStorageTypeStoredKeysObj, byStorageTypeErrorObj){}
});
Oh, and for the sake of complete transparency, BakedGoods is maintained by this guy right here :) .
Related
I have settings of users, which I would like to save in the Database.
The question is now, whether or not I should make for each setting a new row, OR save them in a JSON.
What is the best way to go with, strategic- and habitwise?
Depends on several things:
How many settings do you have?
Do you expect them to rapidly change - both creating new settings and deleting old settings?
Do you need to search for users with specific settings?
Basically, JSON is more flexible and is good if you have lots of settings or if your list of settings is rapidly changing.
Fields are conservative but working with them is way faster than unpacking JSON.
Most often for user settings I would use one field per setting. The reason is that it allows easily getting a list of users with specific setting set (same age, same sex, same city etc.), also ordering them and so on.
But you can use both these options at the same time.
For example, put username, password, firstname and basic options as fields. Then you can quickly get the answers to the questions like "Is this username unique?" "is the password valid" etc.
At the same time you may create a field "additional_options" that will be json-encoded field for some not-so-often-used data, like "about me" and answers to secret questions.
JSON is a way to encode objects, or just serialize data in an easy fashion.
If you plan on saving the data and reading it not very often then JSON sounds like a good clean way, easy to upgrade later when you have more settings. If you plan on writing and reading this data a lot then you will have a big overhead of serializing and de-serializing the data and I would not recommend this.
The question is tagged as javascript, so I assume you are consuming them from js. In this case and assuming they are a small number of key-value pairs, and that you probably read them all together (ie you are not querying them individually or comparing their values for different users or things like that), then storing as json is the better option in my opinion.
I've got a web app which gets a couple dozen items at boot. All these items are JSON and are smaller then 1kb.
Now there are a number of storage options as seen in the Question.
I was thinking of just storing these objects inside a variable in the browser JS. I don't really see why I would want to use any of these browser storages?
So what would be reasons to use any of the browser-based storage instead of a variable inside JS.
Could be that from a certain data size it is preferable to use browser storage, e.g. from 100kb onwards it's better to not use a JS variable.
var myModel = {}
NOTE
Every time the user enters the app he will get fresh content from the server. The content is too realtime for caching.
`
localStorage , globalStorage and sessionStorage:
These features are ready in browsers that have implemented the "Web Storage", they all refer to a kind of HashMap, a map between string keys and string values. but the life is different. once the active page is closed sessionStorage would be cleaned but the localStorage is permanent.(MDN DOM Storage guide)
There is a point about globalStorage, which is its being obsolete since Gecko 1.9.1 (Firefox 3.5) and unsupported since Gecko 13 (Firefox 13), since then we should use localStorage. the difference between these 2 was just the HTML5 scope support(scheme + hostname + non-standard port).
These could be useful for you to:
-Share your objects between your different pages, in your site.
-Offline programming.
-Caching large object
-Or whenever you need to a local persistent storage.
IndexedDB:
IndexedDB is useful for applications that store a large amount of data (for example, a catalog of DVDs in a lending library) and applications that don't need persistent internet connectivity to work (for example, mail clients, to-do lists, and notepads)
based on this quote from MDN you can easily find your answer out, regarding using IndexedDB, if you don't know whether IndexedDB is useful for you or not, just answer these questions:
Do you store a large amount of data on client? if yes, so consider using it.
Does your app need to be offline enabled? if yes, so consider using IndexedDB.
Does your app need to a persistent internet connectivity? If yes, it stays still an option, based on the other factors.
So other than working offline as far as you don't need it, I guess, because as you said:
The content is too realtime for caching.
These have some features like sharing objects, and managing large amount of data, which you should be the one to decide.
localStorage and sessionStorage are solving a caching problem; think of them as cookies. You've said you don't want caching, so you can ignore them.
JavaScript objects behave basically like O(1) lookup tables (see How is a JavaScript hash map implemented?, and make sure you read both the top two answers, as both have something useful to say), and there is no maximum memory limit that I am aware of, or a point where another solution becomes a better choice
The only reason I can think of that you should bother with the extra step of inserting the data in an IndexedDB is if you need O(1) lookups on a field that is not the object key you are using.
I need to write a script to manage conflicting versions of a document in local storage. I'm currently thinking about two alternatives and have trouble deciding which one will be more scalable.
My documents will be stored as JSON and will have an id and a revision to identify the version.
Currently I'm creating a path in localstorage like so:
PATH/TO/DOCUMENT/id
At this path the document is stored as JSON
{"id":"abc","version":"1-a","content":"foo"}
I'm using POST,PUT(update),GET and REMOVE. POST/PUT require id and version while GET/REMOVE only require id.
To allow for conflicting versions to exist in local storage I'm not sure whether to
a) store at existing path and add version as 2nd JSON string like so:
PATH/TO/DOCUMENT/id {"id":"abc","version":"1-a","content":"foo"},
{"id":"abc","version":"2-b","content":"foodforthought"}
b) store at path.id and keep a "single files"
PATH/TO/DOCUMENT/id.1-a {"id":"abc","version":"1-a","content":"foo"}
PATH/TO/DOCUMENT/id.2-b {"id":"abc","version":"2-b","content":"foodforthought"}
Question:
Which one makes more sense in terms of scalability and a lot of different versions to exist?
Which one makes more sense in terms of scalability and a lot of different versions to exist?
Option B. Here you can read / write single document versions without loading the whole JSON string (and then object, when it comes to manipulation) into the memory. Especially when it comes to many and huge documents, this will save you some time.
However, if you have lots of versions of one huge document that do not differ much from each other, it might be better in terms of performance and memory-usage to store them with incremental or differential versioning, which would make more sense in one single "JSON file".
Choose Option A: If each JSON entry is small, having only the id, not the whole document. This is easy to manage and cleanup.
Choose Option B: If each JSON entry is large. I agree with #Bergi
If I understand correctly it is a question about best architecture.
Since you may have "a lot of different versions", you need a quick lookup for localStorage therefore the option b is better. Because in option a, whenever you want to find a specifiv version of the document, you have to go through all items that their id is abc and then iterate through them (worst case: linear search) trying to find the version you are looking for.
However, using . (dot) as the separator isn't probably the best idea. The separator should be a character that is not used in the version number and file name. I would suggest something like /. So the keys will be like:
PATH/TO/DOCUMENT/id/1-a {"id":"abc","version":"1-a","content":"foo"}
PATH/TO/DOCUMENT/id/2-b {"id":"abc","version":"2-b","content":"foodforthought"}
I have a list of all articles in NY Times from its beginning and want have an instant access to all of them without connecting to external database, so my solution is holding it in one variable. But isn't that a bad practice in terms of efficiency?
I doubt that the memory usage is any problem - modern browser games for example probably use an order of magnitude more memory.
I would worry more about the data structure and the operations you intend to run on it.
What kind of application are you writing?
It would properbly be a better idea to create a local database and store the articles there and then create a sync task that pulls only the articles that are of a later date than the previous sync task and save them to the local db.
It all depends on what kind of application you are writing of course
I think you need to look into using HTML5 Local Storage to store this variable or it's contents. This way you're keeping things client-side as you wish whilst also storing the data properly.
LocalStorage doesn't work here. I am looking for more of a theory type answer and not as much code. I already know how to set and delete cookies, that is now what this question is about; here is the question:
When I submit an order, I want to place
Meal
Ingredients
Name
Phone
inside cookies to be later outputted on a div to the right of the page. This I think I can do quite easily. I might put each value into an object of orders...
But that isn't the real question, how can I have multiple orders that are unique? I want to have many different orders and have the user delete the order they desire. I was thinking of separating each order with a | character and than playing some string games. But I don't know how I would delete one.
My other idea was have a order id and auto-increment it. Any help? website: philipimperato.com/mobileOrder
P.S. Only Javascript and I know how to setCookie and deleteCookie :D
Cookies don't seem the place do to this anymore. Cookies are limited and are sent with each HTTP request, including all of your images and static files unless they are on a different domain. I recommend using localStorage instead. Since this is intended for smartphones like the iPhone and Android you are ok to use localStorage. Webkit browsers have supported it for a long time. If you use localStorage you can use any kind of key value storage mechanism you like. I recommend the redis way of field:id:property for keys.
var order_id = 10203;
var key = 'order:' + order_id + ':drink';
localStorage[key] = 'Pepsi';
By using the order_id in your key field you can easily manage unique orders.
You could serialize an order object array in json and parse it back as you load
(This could present security issues, and maybe you should use a framework to parse json back to life. Many frameworks do some lint on json before evaluating it, some even parse it all by themselves)