Petition to undeprecate random primitives - Githubissues

faker-js / faker

Generate massive amounts of fake data in the browser and node.js

https://fakerjs.dev

Other

12.98k stars 919 forks source link

Petition to undeprecate random primitives #607

Closed AustinGil closed 2 years ago

AustinGil commented 2 years ago

In an older version, many of the methods on faker.random that return primitive values were deprecated and moved to faker.datatype. I never understood the reason, and I'd argue that restoring them is better developer experience.

When trying to generate a random value (ie Number), it's more intuitive to go to faker.random
Using random is better for intellisense because faker.datatype clashes with faker.database. It's much nicer to just type "faker.r" then tab.
It feels to me like faker.random and faker.datatype serve the same purpose of grabbing fake primitives.

I'm bringing some of my own bias and assumptions here, so I reserve the right to be totally wrong, but I thought I would mention it in the spirit of trying to make this library better.

ST-DDT commented 2 years ago

FFR: This was added in https://github.com/faker-js/faker/commit/7ad22c2e2aae2f5e6215bcdb91cf3fd28e727d92 v5.5.0

The actual issue is lost to time.

Currently the helper, random and datatype modules are kind of ambiguous. So I consider removing datatype to be a viable solution, not sure what the other maintainers think though.

ST-DDT commented 2 years ago

I found the original content in this event history: Marak/faker.js - Github Event History

Unfortunately, it does not contain a specific reason for that change.

ST-DDT commented 2 years ago

We created a discussion on how to improve on this: https://github.com/faker-js/faker/discussions/805

Shinigami92 commented 2 years ago

When we bring stuff from datatype back to random, I think we should use new names like:

datatype.number => random.int (or random.nextInt? This would align with some other languages like Java :thinking:)
datatype.float => random.number

ST-DDT commented 2 years ago

I think moving it to individual modules (strings/numbers) might provide a better developer experience, because first you select what you want and then you have all the variations available for use.

Shinigami92 commented 2 years ago

I think moving it to individual modules (strings/numbers) might provide a better developer experience, because first you select what you want and then you have all the variations available for use.

Where would you put boolean, hex, datetime and uuid? I think functions like array and json can be removed because I don't know which use-case they fulfill :shrug:

ST-DDT commented 2 years ago

Datetime delete
uuid -> string
hex -> string
boolean can remain in random or helpers
array and json/object/record should be modified and may be moved to helpers: array( numOrRange, elemSource()), ...

pkuczynski commented 2 years ago

I can see the discussion going on here and in #805 - this is a bit confusing. Maybe we should close this issue and focus on the discussion only, which should then be spit into smaller issues?