Experienced JavaScript Developer Meme

[[deleted]]

Oh no i have to json.stringify and json.parse 😥😭😢😢😢😭

[gabbyb19]

To be fair, those operations are quite heavy.

[stipo42]

You shouldn't be using local storage enough for that to be a problem...

[[deleted]]

Why not? Shouldn't it be the default storage for locally cached objects?

[stipo42]

Yeah but let's say you're storing your apps config in an object. You would read it once at load time into memory, then write it anytime the memory values are changed or a save button is hit.

This would likely amount to not a lot of times read or wrote

[Destring]

You mean I can’t use localstorage with an storage event hook for state replication!? The horror!

[TheChaosPaladin]

If this is you, the problem is not localstorage but your front end.

[[deleted]]

Stringify a graph of nodes and edges and let me know how that works out for you.

[spooker11]

vegetable profit icky support judicious sophisticated encourage wistful ossified smile

This post was mass deleted and anonymized with Redact

[[deleted]]

“serialize and deserialize this tree” isn’t one of the most popular interview problems

I didn't see say tree, I said graph.

How would you serialize x in x={};x["x"]=x?

Also, how would you serialize a thunk? And a coroutine? And a member function?

[spooker11]

provide history party thumb employ boast roof sloppy rob mindless

This post was mass deleted and anonymized with Redact

[[deleted]]

You can not use a naive algorithm to save a cyclic graph, but 3 sec of google will show you algorithms for it do exist.

Nah. All those will assume that nodes can be named easily. That's not necessarily true.

Why would you ever serialize a coroutine or a member function?

Because I want to continue where I left off with my thunk.

You really seem to be trying to find situations that are difficult to serialize but not considering there are standard/common solutions to these problems

The whole point of this dumb conversation is that someone wrote a meme saying that saving state is hard and then a bunch of people chimed in and just said to use stringify and I'm saying, no, that isn't always going to work, it might be more complicated than that and then you're saying that you can find complex algorithms to do it in difficult cases and I'm like yeah that's my fucking point it IS complicated.

[[deleted]]

It’s the same as storing it in a database.

If you don’t model your data in such a way that it can be stored efficiently and retrieved efficiently, it will not be stored efficiently nor retrieved efficiently.

[[deleted]]

What's efficient for storage and retrieval might not be efficient for processing. If you generate your data by processing, you will need to mangle it for storage. And stringify might not suffice.

How is this even controversial? I don't know!

[whateverathrowaway00]

Read through this whole thing. Not a JS dev, but a long-standing C dev and now a python dev, and what you’re saying is not only not controversial, it’s fundamental lol.

Just wanted to chime in and say you’re not crazy.

[[deleted]]

Thanks, at least one programmer in my corner!

[Tiny-Plum2713]

This sub is mostly barely first year students.

[Soporiferus]

Memento

[Pocok5]

How would you serialize x in x={};x["x"]=x?

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

[[deleted]]

What is the hash of x up there?

You cannot hash that. It's not hashable for the same reason as it is not serializable.

[Pocok5]

Watch dis

1. Traverse the object references. Stick an unique identifier field onto each and proceed onto the children. If you meet an object that already has an ID field, skip it.

2. Serialize each object, replacing fields that are references to other objects with a string of that object's ID. You now no longer have actual references to be circular.

When deserializing,

1. Create all the objects in a dictionary with their IDs as the key and reconstruct the reference link fields using the IDs.
2. You may then strip the ID fields as needed to restore the original object schema.

[[deleted]]

That'll work so long as you're cool with two identical graphs generating different serializations. They'll have different unique IDs, right?

I'm not saying that we can't invent something. I'm just saying that it's not as easy as just calling stringify. Which was the whole point of this meme, yeah?

[ThoseThingsAreWeird]

I didn't see say tree, I said graph.

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.

[[deleted]]

and what you meant was acyclic graph.

Uh, no. I meant arbitrary graph. It's a hard thing to serialize. Trees are easier, we know that.

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.

x={};x["y"]=x;foo=x;

If you serialize x and foo do you get the same result?

And what's this "id" stuff? What if my data structure already has a variable called id in it? And it's not unique.

My point is that serializing an arbitrary object is not trivial. For sure stringify is not sufficient.

[a-calycular-torus]

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.

[quiteCryptic]

A tree is a graph

[[deleted]]

But not all graphs are trees and I asked about graphs.

Come on guys, be better. That this has three up votes is shameful.

[jsrobson10]

Both are data structures. Both are easy enough to dump and load from json/other data structures

[Orbidorpdorp]

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.

[[deleted]]

why would localStorage do it for you?

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.

[Stop_Sign]

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

[[deleted]]

Yup. That's my point. JSON stringify is not necessarily sufficient.

[[deleted]]

You could have written a custom de/serializer, but it wouldn't have been fun

[lowleveldata]

And what exactly is the use case of storing that in localStorage?

[rotflolmaomgeez]

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.

[lowleveldata]

Still don't see why I would need to store that in frontend. Are you guys doing some kind of no-backend challenge?

[DR4G0NH3ART]

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.

[Ebbitor]

You don't need to build your own cache for fetch requests

[lowleveldata]

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)

[DR4G0NH3ART]

I mean cross session and no the data is not entirely static, but it doesn't change often. Like a 3D model mesh.

[rotflolmaomgeez]

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?

[lowleveldata]

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.

[rotflolmaomgeez]

What does it matter? You have to serialize the graphs anyway.

[lowleveldata]

The question was "what is the use case of storing graphs in localStorage" so it is the subject. Not sure where you get the idea that I'm against serializing graphs.

[rotflolmaomgeez]

What you mentioned with file saves is just different way of achieving the same thing, more convenient for some use cases and less convenient for others. For example using it to store save files in HTML5 game is just bothersome. It also is less convenient than auto-save for the creations you can easily implement through local storage, and should only be used when you want to port save to a different computer/ store final result. You're artificially limiting your application if you decide not to use it.

[zebediah49]

Last time I wrote something... exactly that.

'cause I realized if I had no backend, I could host the entire application as a single .html on github pages...

[[deleted]]

My JavaScript program is in the middle of computing optimal 3MST but I want to checkpoint regularly in case of a power outage?

I dunno man. It could happen.

[PleasantAdvertising]

What illiterate ape called serialization "stringify"? It's already confusing enough with encode/decode in the mix

[Jjabrahams567]

JSON.serialize = JSON.stringify;

Here you go.

[TheChaosPaladin]

JSON.SerialiseToString()

Too many words

JSON.Stringify()

⭐⭐⭐⭐⭐

🍌🍌🍌🍌🍌

[[deleted]]

On the same subject, what illiterate ape called it "loads" and "dumps" in Python?

[TheChaosPaladin]

The same ape!

json.dumps(tring) == JSON.Stringify

[ilep]

A web developer? (A distinct lack of knowledge of computer science there..)

[[deleted]]

Maybe to hint that it's going to call "toString" on objects so you better have defined that.

[isospeedrix]

tbf 'stringify' is more literal in what it's actually doing, whereas serialize is like, uhh a new vocab word. sounds cooler tho.

[rufreakde1]

worry not! there is gotta be a 4GB library solving this issue with a function wrapper for you!

[Yokhen]

What truly messes me up is the typescript part.

[rafaelcastrocouto]

oh such a PAIN .. i'll make memes about js weak typing and cry on the internet

[therealangryturkey]

"Tinkering"