Add fake data generator functions via gofakeit

[ashtonian]

Its an integration of all the gofakeit functions so that you can use fake or randomly generated data in the template, useful for tests and other things.

Not sure this is ready yet, haven't hardly played with it. What do you think? is it worth it? What would it take to get this ready? I would also like to avoid verbosely re-document/re-test the code as well but not sure how to do that, especially because its a random generator. I saw some conversation about a plugin layer via another PR, I'm wondering if maybe that would be a better integration point for something like this?

[hairyhenderson]

Hi @Ashtonian! Thanks for the contribution! 🎉 This is almost ready as-is, but I have a bunch of commentary that may be useful to act on in future. I hope to be able to get this merged soon!

What do you think? is it worth it?

This is a really cool idea! Yes, worth it!

What would it take to get this ready?

Nothing major, I don't think. At the very least, some basic unit and integration tests to spot-check a few of the functions. Don't worry too much about coverage - the goal should just be to make sure things aren't totally broken.

I would also like to avoid verbosely re-document/re-test the code as well but not sure how to do that, especially because its a random generator.

Yeah, I get it. There's some precedent with the sockaddr namespace, though you certainly don't need it to be re-documented to the same extent. And, I can certainly document it post-facto.

A few general notes about how I prefer gomplate functions to be implemented:

1. I generally try (but sometimes fail) to have all template functions take interface{} as an input type, and do type conversions where necessary. As an example, see https://github.com/hairyhenderson/gomplate/blob/af961ebe30041acb4e7f94ddd5f7c92372f97111/funcs/math.go#L96..L111
   • Note that the funcs package is very inconsistent - I haven't changed all of the functions to take interface{} as input type...
2. Where defaults can be inferred, I prefer allowing a relaxed polymorphic style - see https://github.com/hairyhenderson/gomplate/blob/af961ebe30041acb4e7f94ddd5f7c92372f97111/funcs/crypto.go#L118..L133 as an example
   • tl;dr: I take ...interface{} as a single input type, and do type conversion and argument inference based on the number of arguments provided
   • this only works when certain args can be considered "optional"
   • I think e.g. gofakeit.Paragraph is a good candidate for this - forcing 4 args is burdensome when I really just want a random paragraph, but the flexibility is also useful.
3. Pipelining (i.e. {{ "result of some action" | some.Function }}) is powerful and it's good to make sure that functions with multiple arguments specify them in a sane order. That being said, I don't see any functions in gofakeit where that would matter.

(as I'm writing this, I'm realizing I really need to write a contribution/style guide)

I've been long wanting to implement a random namespace, and to be honest I thought I had (maybe I started but got distracted?). This feels very much like exactly what I was looking for (though with way more than I was bargaining for 😂).

Do you think random would be a better namespace name than fake? I'm on the fence, and fake certainly does embody what this is, but I wonder if random would help with discovery. For example, random.Number seems more obvious than fake.Number, but maybe that's just my own bias.

[hairyhenderson]

@Ashtonian ping! Any thoughts?

[ashtonian]

hey @hairyhenderson - sorry for the delay, thanks for the feedback!

do you think pending refactors and update this still the best approach? If so I'll get it done.

[hairyhenderson]

Hi @Ashtonian - over the past year there's now a random namespace that some of this would probably overlap with. Are there specific functions in gofakeit that you're looking for?

[ashtonian]

I think there is value in all the other higher level functions fakes can provide. Contact, Address, Company, for example can allow a user to very quickly generate models or semi realistic forms. Good for testing, load testing and demos.

It looks like string and number would be in conflict, I can pull them out? What do you think?

[hairyhenderson]

@Ashtonian I'm thinking it's probably best to just keep the namespace as fake, and just omit the redundant functions. In fact, maybe to start it would be best to only include the functions that return strings, and that don't take any arguments.

[github-actions[bot]]

This pull request is stale because it has been open for 60 days with no activity. Remove stale label or comment or this will be automatically closed in a few days.