Is it possible to NOT add extensions to Array.prototype? about jinqu HOT 7 CLOSED

It's not possible for now, but I'm considering it. These days polluting prototypes is considered bad practice (not like old days), it might be better if it's optional.

There is another problem I'm working on, polyfills for IE support. It would be best to have these two not automatically imported but only executed if user wants it to.

I will publish a major version soon, thanks for the feedback.

from jinqu.

Hi Umut & Dogoku,

Some thinking out loud...

Presumably the reason it's considered bad practice is the possible name collision with another function with different semantics.

This could be either:

1. The core Javascript libraries themselves
2. 3rd party libraries

Problems with '1' would only occur with applications that weren't maintained for a very long time, as presumably jinqu would be updated well before potential collisions would occur. Problems with '2' would occur after installing a new 3rd party package. There could be both runtime issues (which one wins) and compile time issues (where potentially neither can win?). It would seem runtime issues might actually be easier to solve (after all you can dynamically alter the prototype). Compile time issues might require splitting jinqu into two packages (where there's another package that contains the type definitions for the array prototype extensions). Presumably there would be a "jinqu-array" package that would depend on "jinqu", that would do this.

Another angle: it's perhaps another reason to keep the semantics in line with what you'd expect from the existing array methods. Which would mean not returning a queryable, but rather directly returning an array. But OTOH, even then, there might be design choices that would vary. For example, in my own libraries, I tend to always return undefined for an element not found; others will return -1. In addition, sometimes lazy evaluation is really what you want.

Another thought: maybe the "jinqu-array" package would extend the array prototype and return array type, while the core "jinqu" package would not extend the array prototype and return queryables. Maybe that might be the best of both worlds?

from jinqu.

Thanks for the reply 👍

The main reason to avoid prototype pollution for myself is to avoid name collisions with future changes to the core JS libraries. For example Arrays got flatMap this year in most browsers. If this library overwrites the native implementation and it's implementation is not to spec, then that's a concern, especially if another piece of code is depending on that exact implementation to be there.

Right now, to avoid pollution I'd image I have to do something like:

// replace global array with an extension
const Array = window.Array;
class JinquArray extends Array;
window.Array = JinquArray;
//let jinqu do its thing
require('jinqu')
// restore original array
window.Array = Array;
// export the extended Array class
module.exports = JinquArray;

As far as polyfills are concerned, babel + core-js already solve this problem in a consistent manner. Some projects might already have the Symbol+Iterator polyfill loaded just because they use for..of with babel and it happens transparently. Some might not even support IE, so why incur the weight?

My opinion would be to just mention that you need x,y,z polyfill and suggest people to use core-js.

P.s: https://bundlephobia.com/[email protected]

from jinqu.

Interesting link - didn't realize jinqu had so many dependencies. In many projects I've got, all I actually need is some array prototype extensions. Wondering whether that scenario needs to be optimised.

from jinqu.

Maybe we could strip jinqu down, with these three optional extension packages:

• Class proto fixer (class-transformer), adding ofType prototype fixing
• IE Polyfills
• Array prototype extensions

With these extra packages, jinqu will only depend on jokenizer (we can remove all jokenizer dependencies same way).

Maybe some of them could be published with jinqu, but not auto imported. For example, if you need array proto extensions, you need this line:

import 'jinqu/array-proto-extensions'

But I'm not sure how TypeScript would work when package contains Array proto extension global declaration, if I remember correctly it adds these methods to Array proto even if you don't import it. If this is the case, we have to publish it with a new package.

As @dogoku said, we can avoid publishing a polyfill package if we decide documenting needed polyfills would be sufficient.

from jinqu.

Hi,

I separated Array Prototype extensions from jinqu into a new package (jinqu-array-extensions).
Now Jinqu has only one Array Prototype extension: asQueryable - to create a query for given array.

As I suspected, TypeScript finds and registers global interface extensions, so I had to remove extensions from jinqu package. Also updated the readme.

from jinqu.

Awesome. Thanks Umut.

from jinqu.