Comments (7)
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:
- The core Javascript libraries themselves
- 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.
Related Issues (11)
- Fix coveralls coverage or switch to codecov HOT 1
- Keep npmjs readme in sync with github readme HOT 2
- Bundle Warnings, Add IE 11 support HOT 27
- toArray return type HOT 11
- StackBlitz + jinqu broken HOT 4
- ofType broken? HOT 35
- PATCH method is missing in AjaxOptions HOT 1
- String interpolation? HOT 3
- Less self-effacing tagline HOT 1
- asQueryable HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from jinqu.