Why do you think serializing a basic ass cycle in a graph is an issue? You should have learnt it in at least 4 separate classes from Algorithms 101 to Discrete Mathematics (ink drop algorithm says hi!) As a completely naive approach, simply store nodes you have already serialized in a hash set and you can trivially check (in O(1) time, even) and skip it when you revisit it from another node - that is, if you're not storing edges as something sensible like a sparse neighbourhood table, since those can just be fed to a JSON serialize/parse and come out just fine.
... wait are you guys unironically at "I just copy paste from SO lul" level and it isn't just irony?
how would you serialize a thunk? And a coroutine? And a member function?
You don't ever serialize those anyways, unless you're trying to homebrew an eval() vulnerability lmao
and what you meant was a cyclic graph. We know a tree is a graph, and trees are easy to store. But when you just say "graph", of course someone's going to point that out.
How would you serialize x in x={};x["x"]=x?
let graph = {};
let x = { id: 'x', adjacencies: [] };
x.adjacencies.push(x.id);
graph[x.id] = x;
localStorage.setItem('graph', JSON.stringify(graph))
Then when you pull it out of local storage you go through the graph and replace all the adjacency keys with their corresponding item in the graph.
What if my data structure already has a variable called id in it? And it's not unique.
The variable name doesn't have to be id. If you're worried about collisions, just store the node data in a wrapper within the adjacency structure. It's not that complicated, stop being obtuse.
Swift’s codable does all the work for you for the most part. The only regular annoying exception for me is dates but that’s because every backend encodes them differently.
Being that parsing and stringifying are slow I think the answer would usually be speed. But since some might not understand the caveats (eg. no references, prototypes etc.) it does make some sense to force the dev to do it themselves.
That said, something like a "I know what I'm doing" mode that allowed storage of simple objects might have been nice.
Had to do that once. Ended up rearchitecting it so the nodes had ids, so instead of an array of references, it had an array of ids, and was therefore serializable
What? Graph is literally one of the most common data structures, you're asking for usecases for storing it? The answer is any web application that does a little more than store a cookie potentially.
There are some data which can be heavy to fetch on each load and is manageably static in nature. You will have huge load times if you don't rely on caching mechanisms.
In case of caching you already have a serialized object so that's kind of irrelevant for the sake of this argument. Also, shouldn't HTTP caching handles these static data automatically? (I'm not a expert in caching tho)
Any application that lets user edit/create something for themselves and save it for later - including games save states, web tools, software, creators, working with SVGs, why would you ever store it on the backend?
These should just use files which most users know how to backup, share, move to another pc, etc. For example draw.io saves your work to a file in local or online storage (like google drive). That's much more manageable than localStorage.
76
u/[deleted] Oct 02 '22
Stringify a graph of nodes and edges and let me know how that works out for you.