cedmax / youmightnotneed Goto Github PK

This will harm less knowledgable users who copy this example:

const toPath = path => path.match(/([^[.\]])+/g)
> toPath('a["b]c"]')
['a', '"b', 'c"']

Correct behavior:

_.toPath('a["b]c"]')
(2) ['a', 'b]c']

a few missing implementations can be found here

mdn docs

Support is pretty good too, should we replace it?

Since content is long, it will be helpful to have back to top button so that user can go back to top to search another function.

Ciao!

La tua repository è stata selezionata dalla nostra redazione per il format "FOSS Explorer" di Schrodinger Hat, una rubrica del nostro talk show riguardo il software development e il mondo open source italiano, e verrà mostrata nella puntata di Martedì 9 Giugno in diretta sul canale Twitch e YouTube alle ore 13.00.

Il tuo lavoro ci è piaciuto molto e speriamo che questo possa aiutare a fornire visibilità al tuo lavoro ;)
Se per te va bene, la includeremo nella nostra top5 bisettimanale!

A presto!

Generally I think some lodash functions are necessary in pre-typescript code. But I was using import find as 'lodash/find' in a typescript project. While looking to prune my build size, I discovered that including lodash/find instead of using array.find actually cost me 5kb. Fair to say, 4.9kb of that was mostly magical stuff I wasn't using, but was very surprising.

I think including the estimated maximum savings, both disk and gzip'd variants with measured version number, would be useful information.

Hello, I made a rule set of what you should think of when you are building cross Browser/Node.js applications, maybe you can come up with tips and help out?

https://github.com/cross-js/cross-js

It would really help if there were a table of contents to be able to quickly get to, for example, Collections. Is this something you would like for me to open a PR with, or is this not implemented for a reason? Thanks, this is a great project.

Hey!

Thanks for your neat collection of plain JS functions. I have found something interesting while experimenting with a suggested replacement for lodash'es remove:

https://youmightnotneed.com/lodash/#remove

const remove = (array, iteratee) => 
  array.filter((item, i) => iteratee(item) && array.splice(i, 1))

This code mutates array as after each successful iteratee which may negatively impact the final result if iteratee depends on array. Consider this example:

var arr = [1, 2, 3, 4, 5];
remove(arr, val => arr.length > 0)

the expected result for remove to return is [1, 2, 3, 4, 5] as arr.length > 0 is truthy for all elements of arr. In reality it returns [1, 3, 5] and arr equals to [2, 4].

_.remove returns [1, 2, 3, 4, 5] as expected.

Hi there,

Thanks for this repo, it's been useful to check myself before pulling in a fat library for utility functions.

I notice the get/has/set vanilla methods appear to only support single character properties:

const testObj = { a: 1, b: { c: 2 }, foo: 3, d: { bar: 4 }, e: [undefined x 9, 'baz', 'buzz']  };

get(testObj, 'a'); // 1; CORRECT
get(testObj, 'b.c'); // 2; CORRECT
get(testObj, 'e[9]'); // 'baz'; CORRECT
get(testObj, 'foo'); // undefined; INCORRECT
get(testObj, 'd.bar'); // undefined; INCORRECT
get(testObj, 'e[10]'); // undefined; INCORRECT

I believe the fix is to add a greedy 1+ quantifier to the regex (shown here in get but used in all three methods), i.e: path.match(/([^[.\]]+)/g)

This corrects the above cases, although it still doesn't cater for edge cases such as 'path.to["a key with a . [ or ] within it"]', though I'm unsure whether a single regex would be able to cater for such cases.

Happy to submit a PR myself when I get the time.

Result is set on line 5, not touched, and then returned. Lines 4 & 9 should be removed.

https://github.com/cedmax/youmightnotneed/blame/production/src/content/lodash/array/remove/vanilla.js#L5-L9

Getting tiered of ppl including the hole moment.js lib just to use it in a few places or only using a fraction of what moment.js provides.

Yesterday i saw this on a nodejs backend

package.json

development: {
    moment: "1.something.x"
  }

And the only thing he did in the hole project was just this line of code:

moment(timestamp).format('YYYY-MM-DD')

Things could have been replaced with just any of this:

new Date(timestamp).toLocaleDateString()
new Date(timestamp).toLocaleDateString('sv-SE') // Will format yyyy-mm-dd
new Date(timestamp).toLocaleDateString('x-X') // unknown language will fallback to iso standard format (yyyy-mm-dd)

They need to learn that there is also Intl.DateTimeFormat

Was looking into adding an object values example for lodash but found simple format test for moment is currently failing.

var date = new Date(Date.UTC(2012, 11, 20, 3, 0, 0));
new Intl.DateTimeFormat('it-IT', {
  year: 'numeric',
  month: '2-digit',
  day: '2-digit',
}).format(date)

returns "20/12/2012" rather than 2012-12-20

this code fix this
`const get = (obj, path, defaultValue) => {
if (!path) return undefined;

const pathArray = Array.isArray(path) ? path : path.match(/([^[.]])+/g);
let result = pathArray.reduce((acc, key) => acc && acc[key], obj);
if (typeof result === 'undefined') {
return defaultValue;
}
return result;
};
`

What do you think of adding a "you might not need RegExp" page? I occasionally see people using RegExp's when a simple startsWith, endsWith or includes would work perfectly well, would be more readable, and potentially be faster.

The Lodash version of pick accepts a path, thus this is perfectly doable in Lodash:

import { pick } from 'lodash'

const object = {
  a: 1,
  b: 2,
  c: { d: 3 },
}

pick(object, ['a', 'c.d'])
// => {a: 1, c: {d: 3}}

But there's no equivalent in ES6.

Recommend adding youmightnotneedthatwpplugin.com

It looks like this project is a good example of things that can have property-based testing (that can be implemented with the help of, for example, fast-check).

Basically, this type of tests will allow us to write assertions that will look something like

For any X that is string and any Y that is natural number, X.repeat(Y) === _.repeat(X, Y)