In many organisations including B2C e-commerce, the choice of data structures is not good when writing code that scales customers on the web browser. DOM manipulations and client-side operations are costly! Any big operations you write/perform/query directly on the web browser using javascript are costly.
Say, for instance, the choice of setting up the data structure of a shopping cart containing many items that requires frequent update/addition/removal.
Instead of structuring a shopping cart data items like a list of items as shown below -
{
"headers": [
"name",
"quantity",
"price"
],
"items": [
{
"id": "1232ewr2",
"name": "Inoculation",
"quantity": "1",
"price": "20",
"sku": "432EGFE"
},
{
"id": "e632r32",
"name": "Pulp Fiction",
"quantity": "3",
"price": "5",
"sku": "432ERFE"
},
...
],
"total": 35
}
You can use -
{
"headers": [
"name",
"quantity",
"price"
],
"items": {
"1232ewr2": {
"name": "Inoculation",
"quantity": "1",
"price": "20",
"sku": "432EGFE"
},
"e632r32": {
"name": "Pulp fiction",
"quantity": "3",
"price": "5",
"sku": "432ERFE"
},
...
},
"total": 35
}
If you observe critically and think, there are a few observations that determine the use-cases and improvement on time constraints on the web browser -
Searching an item in the cart takes - O(1) instead of O(N).
Updating the quantity (addition/removal) of an item in the cart takes O(1) instead of O(N).
Removing an item from the cart takes O(1) instead of O(N).
For frequent addition/removal / updation of items - Associative containers like Maps come in handier than linear data structures for instance Arrays / Linked lists.
Like handling large-scale geospatial data, repeated data containing metadata and storing a set of fixed keywords or tags that are referenced frequently.
So, take your time to analyse your problem first and then determine the basic operations that must be supported and finally choose the right data structure to quantify the resource constraints for each operation.
Top comments (0)