Contextual Products

[digitalcoyote]

I'd like to see Products be able to produce contextual information in a similar way to Persons. Seems like this could be disruptive though as the appropriate location (I believe) would be Faker.Commerce.Product. It seems to me that the Product Method would more appropriately be named ProductName (as this is what it actually returns).

This would be extremely helpful for my use case, but if I'm going to do it for me, I'd like to code it in such a way it could be pulled back in.

Ideally a product would have (with new datasets as necessary):

• Name
• Short Description (Constructed from Product Name and Adjective/Material)
• Long Description (Generated using Name, Adjectives, Material(s), etc with some template text)
• SKU
• Color
• Category
• Seller/Retailer (Company)
• Manufacturer (Company)
• Price
• Department
• Material

Potentially:

• Reviews (Rants)
• Materials (List of Materials)
• Adjective (private to be used for description)

I'm not excited about breaking people using Product to generate product names though so any suggestion would be greatly appreciated.

EDIT: To be clearer, I'm looking for a suggestion of where this would be best added and not suggesting actually replacing Product with ProductName (never used faker.js but I assume that would break the semantic API compatibility with faker.js)

[bchavez]

Hi @digitalcoyote,

Thank you for creating an issue. I appreciate very much being able to discuss the proposal before a PR is submitted.

I'm still on the fence about creating a dedicated contextual Product like we do for Person. I added Person because I thought it was general enough to be useful. Person was also loosely based on faker.js' contextualCard. This is where some of Bogus' API differ from faker.js. In Bogus we have Person and in faker.js they have contextualCard.

The reasons I feel some reservations about Product vis-à-vis Person:

• IMHO, the contextual interrelation between properties of a Product is less strong than the interplay of properties of a Person. Consider a Person's first name, last name, username, and email address and their interrelatedness in generating a contextually relevant (albeit fake) person's identity. It's not clear to me yet that there's a strong correlation (like there is with Person) between a Product's name, description, color, category, and SKU if we are sourcing this data from our datasets. I think there would have to be an equally (or stronger) correlation of interdependent properties of a Product to justify making a Product a first-class thing.
• The format of the SKU can have a lot of variation in different systems. I have a feeling there's probably a strong requirement for systems being built to make sure SKUs match a particular business rule.
• With a Product we could be generating electronics, bikes, soda, and toys for a system that only cares about selling clothes. Whereas a Person's properties can be used as a source for guests, patrons, customers, employees, and managers.
• Scaling this out to other contextual objects, performance-wise and API-wise with the Faker facade will become problematic. (More on this later).

My overall arching view of Bogus is to keep its API somewhat focused and terse on the general use case. I do sometimes fear polluting the API in the name of being everything for everyone. Hashids is the latest example of my mistake that I'll eventually deprecate in v16.

Regardless how I feel about Product I would probably place Product in Bogus.Extensions namespace. I've been using that namespace as a home for things that generally go above and beyond faker.js. Product would be a perfect fit there I think; although I'd still hold the same reservations about accepting a PR and maintaining it like I do with Hashids.

---

With that being said, I do see possibly a better/alternative way of looking at a Product setup. Another way to look at Product this is through the lens of "Conventions" or "Rule Bundles".

Imagine for a second we had a namespace called Bogus.Bundles or Bogus.Conventions and this:

using Bogus.Conventions;

var productFaker = new Fake<MyStoreProduct>()
                       .ApplyConvention(new ProductConvention())
                       //or .ApplyConvention<ProductConvention>()
                       .RuleFor( p => p.SKU, f => f.Replace("MYSTORE-###-???" );

var products = productFaker.Generate(150);

Where ProductConvention would be given the chance to contextually apply relevant rules for properties related to a product: Name, Description, SKU, Color, Category, Price, etc... And still allow user to "override" the SKU with their own business rule.

IMHO, this approach scales Bogus' usefulness and utility without necessarily polluting and complicating the public API set. It's a win-win all around I think. We could endlessly scale these conventions to a whole library of conventions for different object types. Long term, this is where I see Bogus going and I'd be happy to maintain something like that.

See #8 for more discussion on the topic.

I hope my mind dump on the topic somewhat makes sense. 👍

Thanks,
Brian

💭 🔍 "I want to know... what you're thinking..."

[digitalcoyote]

Makes sense, I look forward to that approach. In the mean time, I'll handle this case within the project I'm testing.