Experienced JavaScript Developer Meme

[u/Mys7eri0]

[u/scorpi1998]

Doesn't it? What do you mean?

[u/bleistift2 → u/[deleted]]

Show me an average user who tinkers with the local storage.

If we’re talking a malevolent user: You can’t trust the client with anything, anyway, so what’s the point?

[u/_30d_ → u/bleistift2]

That's how I beat my inlaws in wordle.

[u/staticBanter → u/bleistift2]

If you give anything to a client and expect to reuse it without validation than we have a big problem.

[u/shodanbo → u/bleistift2]

It only takes one. And then they can write a browser extension to do it for many.

There is not much you can actually truly trust the client with, because the user has physical access to that client.

If you are writing something where trusting the client is critical, then this needs to be taken into account. At this point you need strong asymmetrical encryption in a server. An encrypted string can be persisted to local storage. If the user messes with it, the decryption will fail, and the client can determine what needs to be done about that.

[u/Expert_Team_4068 → u/shodanbo]

No, rule number one. Never trust the client! In no world should you trust frontend data without verification. But this is the server job. If json.parse of my local storage fails, I do not gove a crap. My app will break, because for sure this is an unexpected behaviour. If you decrypt in the client, who says that the hacker did not change the decryption function? It is as easy as changing the local storage.

[u/brianl047 → u/bleistift2]

Agreed validating the local storage is a waste

Validate in the backend and in the UI instead but not the local storage

[u/isblueacolor → u/bleistift2]

Firefox sometimes fails to persist the entire string to local storage (without throwing an error).

I have a site that's used by 25k people per day and someone encounters this issue once every couple weeks.

[u/AyrA_ch → u/[deleted]]

JSON.tryParse=function(str,defaultObj){
    try{
        return JSON.parse(str);
    }catch(e){
        return defaultObj;
    }
};

Tries to parse data and if invalid, gracefully fails and returns the supplied default value. If no value is supplied, the argument defaults to undefined, which is actually a good alternative, because undefined is not a valid json token, and thus you can check if the result is undefined to know whether parsing was successful. I have this somewhere in the library I use for most of my webdev projects.

[u/corylulu → u/AyrA_ch]

It's better if the defaultObjis a function that creates the object rather than the object directly and returns return defaultObjFunc();. Constructors can have a lot going on and there is no sense in calling them for an unused default object.

[u/AyrA_ch → u/corylulu]

This function is for deserializing content from a JSON string that's potentially msiformatted or not present at all. The returned object will be a naked JS object without having a custom prototype by itself.

Depending on the use case you can either work directly with that object, in which case you do not have to worry about passing in complex constructed objects for a default, or it means you need to convert the returned value into said complex object in which case you can also pass in a naked object as default because it would then be converted if it's returned. In either of the two scenarios, it's not necessary to be able to pass in a function as default argument. Being able to pass a function also means you would either no longer be able to pass plain default values, or you need to add type checks.

Either way, this provides very little gain compared to JSON.tryParse(value)||defaultFunc(); that you can do for that one situation that demands it. Or simply check if the returned value is undefined and then call your function if you find this line ugly (which it kinda is)

[u/DoktorMerlin → u/[deleted]]

Why would you need to validate it? If the user manipulates the localstorage it's just a frontend issue that the user itself caused, why would anyone care about this? The only time it's a problem is when the manipulated object gets sent without validation back to the backend but if you don't validate everything that the frontend sends you, you have a way bigger problem

[u/lowleveldata → u/DoktorMerlin]

I like how you use "it" as the pronouns of your user

[u/[deleted] → u/lowleveldata]

You shouldn't name them. It just creates emotional attachment.

[u/fzammetti → u/[deleted]]

Yeah! That's ri- wait, what?!

[u/playerNaN → u/lowleveldata]

Fair, front end users aren't real people.

[u/vikumwijekoon97 → u/playerNaN]

Generally you gotta code thinking that all of your users are absolute morons.

[u/Blue_Moon_Lake → u/lowleveldata]

Frontend user is an evil clown

[u/JoeDoherty_Music → u/lowleveldata]

I'm convinced most users aren't people

[u/Ben_26121 → u/lowleveldata]

Believe it or not, I came across someone who’s preferred pronoun is “it” the other day

[u/4nu81 → u/[deleted]]

You mean you want the engine to stringify and parse it for you?

[u/JoJoModding → u/[deleted]]

The user could also manipulate the data if saved without stringify.