Remix.run Logo
jraph 3 hours ago

Please don't mess with native prototypes though.

Sammi 3 hours ago | parent [-]

Agree if you've a library developer. If you're an app or website developer then it's your project. Everyone else should steer clear of adding to native prototypes, just so they are clean for the end user.

jraph 3 hours ago | parent [-]

If you are an app or website developer, at least you won't break other's systems.

But you might still break stuff in your own projects. Imagine you extend a native prototype with a method, and later the native prototype starts having a method with the same name.

Newer libraries start using that new standard method.

You upgrade the libraries your website depends on, or add a dependency, and this new code happens to depend on that native prototype. Only you replaced it with your custom method, and that method likely doesn't have the exact same behavior. You broke that new code and fixing this might not be trivial because uses of your custom method are sprinkled everywhere in your code.

It only works if you ever works on projects that have zero dependencies, or dependencies you never update.

Or you could spare yourself the troubles and define a method that takes the node in parameter.

It's also a question of forming good habits: you could be working on your projects now, forming a habit of extending prototypes, but will you remember not to do this the day you write a library?

By the way, how can you be sure you won't move some of your app code to a library because you like your utility functions and would like to reuse them in another project of yours? And why not open source that shared code, so you can just install it with NPM? Bam, that stuff is a library now.

hyperhello 2 hours ago | parent [-]

Rules beget rules.